从管理学看敏捷开发Scrum

Love The Way You Lie 2022-05-22 09:00 248阅读 0赞

2010-12-21 14:13 宗子城

每次我们看敏捷开发Scrum都是从技术角度，今天我们尝试从管理角度来看这个问题。

**Scrum**

Scrum近几年已经成为最有影响的软件开发过程，从Forrester 关于敏捷模式的调查报告我们可以看出一些倪端,而且微软也推出了更Scrum的模板，相信.Net平台下越来越多的团队会采用这一过程。

![1350313090_4816.jpg][]

图1： Forrester 关于敏捷模式的调查报表

Scrum的在软件日趋复杂的环境下,其成功不是偶然的,其指导思想符合我们现代管理学的一般规律。

**管理学**

经过近百年的管理理论的演进，管理一般被认为是一个协调工作活动的过程，以便能够有效率和有效果地同别人一起或通过别人实现组织的目标，其协调工作活动一般分为**计划,组织，人员，领导，控制**五个方面,这五个方面并没有严格的时间断点,而是一个相对独立的问题域,周而复始的贯穿整个管理过程。

计划：计划涉及使命、目标选择、决策完成使命的行动方案。

计划是管理的首要职能。它是在预见未来的基础上对组织活动的目标和实现目标的途径作出筹划和安排，以保证组织活动有条不紊地进行,计划内容包括“5W1H”.制定计划首先要确定目标,在制定目标时候要参照SMART法则.

组织：维护群体的工作方式，旨在建立一个合适的角色体系，创造一个促进员工完成任务的环境。

组织意指一个正式的、刻意设计的角色或职位结构以满足组织目标实现，明确所需要的活动并加以分类，对那些为实现目标所需要的活动进行分组，每个小组安排有监督职权的管理人员来领导，为组织结构中的横向协调和纵向协调制定有关的规定。 在组织设计的时候要注意统一指挥原则 ，控制幅度原则，权责对等原则，柔性经济原则，同时注意强调组织有效性和组织文化。

人员：组织角色的填充,涉及人员的配置和保持人员的稳定。

人力资源管理工作直接影响整个企业的经营状况，现代管理学人为人力资源部门为企业利润中心，在人力资源管理方面，企业总的目标是尽可能拥有高素质的员工，以使企业得以保持竞争优势；而人力资源管理部门则主要侧重与这一总目标有关的更为具体的目标即生产力以及质量和服务，通常人力资源的变革涉及企业在文化、领导方式和人力资源政策与实践惯例等方面作出相应的改变。

领导：对团队人员施加影响，促进其对组织和群体目标做工作。

领导是影响人们心甘情愿和满怀热情地为实现群体的目标而努力的艺术或过程。越是了解那些激励下属的因素以及如何使这些因素发挥作用，并体现于管理的实际行为之中，那么领导就越有效,在领导过程中可以从分发挥采用委员会和小组的优点。

控制：确保事情的发展方向符合计划，评定和纠正人员和组织的绩效手段。

控制是对绩效进行衡量和矫正，确保企业目标以及为实现目标所制定的计划能够顺利完成,控制基本过程为确定标准，衡量绩效,纠正偏差，在控制点上我们可以选择实物标准、成本标准、资本标准、收益标准、计划标准、无形标准、以系统目标为标准、以战略计划作为控制点。

**解析Scrum**

Scrum框架图如下：

![1350313114_4552.jpg][]

图2： Scrum框图

1.产品列表和迭代计划

产品任务列表（Product Backlog Item/PBI） 是可以预知的所有仸务，包括功能性的和非功能性的仸务，PBI属于计划阶段，指出了我们目标，PBI表述的时候建议的原则

Independent 独立性，避免与其他Story的依赖性。

Negotiable 可谈判性，Scrum中的story不是瀑布开始某事中的Contract, Stories不必太过详细，开发人员可以给出适当的建议。

Valueable 有价值性， Story需要体现出对于用户的价值。

Estimable 可估计性，Story应可以估计出Task的开发时间。

Sized Right 合理的尺寸， Stories应该尽量小，并且使得团队尽量在1个sprint(2 weeks)中完成。

Testable 可测试性， User Story应该是可以测试的，最好有界面可以测试和自动化测试。每个任务都应有Junit Test。

这个虽然加入了一些软件技术性描述，但是总体上和我们说Smart原则上是一致的。

迭代计划(Sprint Planning )，综合考虑项目环境,在下一个迭代周期的目标,其中的Sprint Backlog来自PBI，这个就是我们所讨论的计划工作中对目标实现的途径作出安排。

![1350313127_4838.jpg][]

图3：迭代计划

当然这涉及到决策问题,比如迭代的周期？先实现那些PBI？比如迭代周期的选择，这个就是个非程序化决策，需要我们自己的经验判断，PBI的优先性我们可以从PBI的字段描述中进行程序化决策。

2.Scrum中的角色与团队

Scrum定义了许多角色，关于猪和鸡的笑话很形象，对于猪的角色来说又分三种：**产品负责人（Product Ower），Scrum主管（Scrum Master）,开发团队（Scrum Team）**

产品负责人代表了客户的意愿。这保证了Scrum团队在做从业务角度来说正确的事情。产品负责人编写 用户故事，排出优先级，并放入产品订单。

Scrum主管Scrum主管促进 Scrum过程，他的主要工作是去除那些影响团队交付冲刺目标的障碍。Scrum主管并非团队的领导（由于他们是自我组织的），而是负责屏蔽外界对开发团队的干扰。

Scrum主管确保Scrum过程按照初衷使用。Scrum主管是规则的执行者。开发团队负责交付产品的团队。由5至9名具有跨职能技能的人（设计者，开发者等）组成的小团队完成实际的开发工作。

Scrum中这三种角色是精心设计的,符合我们管理理论组织的理论，一个产品只能有一个Product ower符合我们的统一指挥原则，Scrum Master的主要工作是去除那些影响团队交付冲刺目标的障碍，也是为了项目实现创造环境等等。 在实施Scrum的时候，所做的第一件事情就是打乱特定于组件的团队，创建竖井式的团队。它减少了诸如“我们没法完成这个条目，因为我们在等server那帮家伙完成他们的工作“之类的情况发生.

3.Scrum中的会议

敏捷的宣言中包括个体与交互胜过过程和工具,Scrum中对于会议分为：计划会 （Sprint Planning Meeting）, 每日立会 (Daily Standup Meeting),评审会(Review Meeting)，回归会(Retrospective Meeting）。

**计划会 Sprint Planning Meeting**：在每个冲刺之初，由产品负责人讲解需求，并由开发团队进行估算的计划会议。

**每日立会 Daily Standup Meeting**：团队每天进行沟通的内部短会，一般包括完成了什么？是否遇到了障碍？即将要做什么？因一般只有15分钟且站立进行而得名。

**评审会 Review Meeting**：在冲刺结束前给产品负责人演示并接受评价的会议，在这个会议上产品负责人确定完成了哪些工作和剩余哪些工作。

**回顾会 Retrospective Meeting**：在冲刺结束后召开的关于自我持续改进的回忆。

这个和我们管理中控制息息相关,其中计划会指明了控制的方向,每日立会作为前馈控制,评审会可以作为现场控制，回顾会可以作为后馈控制，为我们下一步计划做参考,在会议中各个Sprint Backlog完成情况可以作为员工绩效考核的一个因素。

4.燃尽图

是一个公开展示的图表，显示当前冲刺中未完成的任务数目，或在冲刺订单上未完成的订单项的数目，通常燃尽图可以在每日立会展示，作为我们控制的一个辅助手段。

![1350313142_4617.jpg][]

图3：燃尽图

**Scrum文化建设**

让团队坐在一起，从分共享信息，这些都切合我们管理学领导中激励的概念，满足员工工作个人成就的需要。

原文链接：http://www.cnblogs.com/Roping/archive/2010/12/21/1912525.html

[1350313090_4816.jpg]: https://img-my.csdn.net/uploads/201210/15/1350313090_4816.jpg
[1350313114_4552.jpg]: https://img-my.csdn.net/uploads/201210/15/1350313114_4552.jpg
[1350313127_4838.jpg]: https://img-my.csdn.net/uploads/201210/15/1350313127_4838.jpg
[1350313142_4617.jpg]: https://img-my.csdn.net/uploads/201210/15/1350313142_4617.jpg