自敏捷宣言以来,随着敏捷软件开发方法的普及,很多企业踏上了敏捷转型的道路。这里宝宝将跟大家一起说一下敏捷当前最流行的两个框架(Scrum和看板方法)——从它们的起源来分析各自的本质。
Scrum
Scrum的起源
Scrum一词来源于英式橄榄球(rugby)中重新开始比赛的争球的术语(是体育术语,不是缩写简写)。详情参考Wikipedia。
Scrum之父Ken Schwaber和Jeff Sutherland为什么选择这个词呢?这是因为他们受到一篇1986年哈佛商业评论上的论文影响——《The New New Product Development Game》。论文中开篇提到了:
许多公司意识到仅仅依靠高质量和低成本,已经无法从今天的市场中脱颖而出,它们还需要速度和灵活性。……而传统的顺序式或“接力赛”方法(比如按阶段的产品规划)可能和追求速度和灵活性的目标相冲突。相反,一种全局的或“英式橄榄球(rugby)”(团队通过前后配合传球的方式,作为一个整体单元推进)可能更好的适应了这种目标。
另外,在Scrum指南中也非常强调团队(开发团队),它们具备如下特点:
- 自组织的,没有人来命令(或告诉)团队如何把产品列表变成潜在可交付的产品增量。
- 跨职能的,团队作为一个整体,拥有开发产品增量所需的全部技能。
- 全职的,团队成员100%在团队内工作。
- 规模较小的,一般5-9人
虽然Scrum指南中还定义了Scrum框架的其他内容,但通过Scrum的起源(那篇论文)和指南中对于团队的描述,我们不难看出Scrum的本质是以团队为核心。
Scrum的本质
Scrum本质是以团队与产品(产品列表Product Backlog,这里就不展开介绍产品列表了)为核心。注意这里指的团队,和我们平时说的团队之间的差异。Scrum中的团队是自组织的、跨职能的特性团队。这样的团队的好处是:
- 特性(客户需求)在一个团队内完成,去除了移交、等待之类的浪费
- 团队的业务知识快速增长
- 团队稳定,从而有助于团队隐性知识的积累
“搭班子、定战略、带队伍” ——柳传志
柳总的管理心法是在做事之前要先有一批志同道合的人,有班子,然后再考虑定战略。这个管理思路和Scrum是一脉的。Scrum的本质也是先打造自组织跨职能的特性团队,然后再遵守Scrum指南的其他规则。
看板方法
看板方法的起源
看板方法的重要来源是Donald G. Reinersten的《The principles of product development flow》。这本书强烈推荐大家读一下。该书中共介绍了175个产品开发的原则,其中不乏一些反常识性的原则,另外还介绍了一些具有实践性的方法:
- 改善决策的经济性
- 管理队列(对比一下肯德基和麦当劳的取餐模式,很有趣)
- 减小批量大小
- 应用WIP限制
- 去中心化
看板方法的本质
由上述Don的书中核心理论可以看出,(产品开发流动的原则)他强调的是流动以及价值流动,这个是看板方法的本质。看板方法通过一系列原则促进实现价值的快速流动,比如:
- 可视化
- 限制WIP
- 减小批量
- 管理度量队列
- 等等
Scrum和看板方法的对比
上面分析完Scrum的起源、本质和看板方法的起源、本质后,我们不难看出这是两个完全不同的解决问题的方法。
- Scrum侧重于团队和产品,先有自组织跨职能的特性团队,然后围绕着产品列表进行交付。
- 看板方法侧重于工作事项,先让价值流动起来。
那么这两种方法孰优孰劣,这个很难衡量。以下仅代表个人观点:
Scrum的特点:
- 打造真正的团队
- 多数情况下组织结构需要变动(跨职能团队)
- Scrum转型的切入点是组建团队和梳理产品列表
看板方法的特点:
- 价值快速流动
- 多数情况下组织结构不需变动(保留当前的现状)
- 看板方法转型的切入点是梳理工作的价值流
适合场景
Scrum更加适合产品开发,比如一个全新产品或原有系统的增强等。围绕着先组建特性团队、梳理产品,然后每个Sprint产出产品增量。
看板方法更加适合运营型(或运维性)项目。该项目特点是很难提前做出预测。比如我们无法预知明天会出现几个线上故障。
课后思考题
基于以上的Scrum和看板方法本质和特点,你会怎么选择呢?是否可以结合Scrum和看板方法呢?
欢迎回复留言进行探讨。
---广告---
2017年4月16日17日 上海CSM敏捷认证课程 http://yihuode.io/activities/444