自敏捷宣言以来，随着敏捷软件开发方法的普及，很多企业踏上了敏捷转型的道路。这里宝宝将跟大家一起说一下敏捷当前最流行的两个框架（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产出产品增量。

看板方法更加适合运营型（或运维性）项目。该项目特点是很难提前做出预测。比如我们无法预知明天会出现几个线上故障。