实现敏捷框架的比较：Scrum 方法 vs 看板方法 vs 精益开发 vs 极限编程

如果您是刚刚踏进敏捷开发的世界中，可能刚开始会被这个方法那个方法搞晕掉。那是因为敏捷开发只是一些简明扼要的概要准则，没有明确说明需要如何一二三步骤地来落地实现。

因此，人们从实践中总结真知，就衍生出了实现敏捷的各种各样的方法。其中，最广为人知的当属 Scrum 方法、看板方法、精益开发以及极限编程。

虽然本文主旨是要对比上述的四种方法，不过要是较真地来分析他们的不同，实际感觉上就好比要比较苹果和橘子的不同有哪些。因为他们其中有的就是从另一种方法衍生而来或者是另一种方法的补充罢了（尤其是当这些方法被应用在开发环节的不同周期中，更难去比较他们之间的不同）

一、Scrum 方法

Scrum 方法可以称作是敏捷在软件开发中的实现框架。前不久，我遇见了自己上一份工作的同事们时会都告诉他们我正在我的新岗位做敏捷开发。这些同事第一反应就会问我，“是吗，那你们是不是每天都会开站会，是不是每天都要有成果物交付呢？”在大多数人眼中，Scrum 方法就是敏捷开发的同义词。

当然首先，Scrum 方法是一个管理上的理论框架。它阐述的是软件开发人员们没有在敲代码时应该都干些啥。Scrum 方法明确地规定了一个模型，根据这个模型，软件开发人员们可以安排他们的开发计划，并持续迭代更新这个计划，以及定时回顾分析之前的开发过程中发生的事情。

在这个框架中包含一个叫 Scrum Master 的角色，担任这个角色的人要专注于把控项目的进度并竭尽可能辅助程序员们开发作业。

实操方法

Scrum 中，每个阶段传递信息用到的产物主要有：

1、User Story（用户故事）。用户故事阐述的是一个小的功能点，团队成员们要在特定的时间段内完成这个功能的开发作业，而这个特定的时间段，被称作为冲刺计划。

用户故事的通常格式是，作为一个….（用户角色），我想要…..（软件应该实现的这种那种的功能），这样我就可以……（如何如何，最终实现一个实际业务中的效果）。

每个用户故事都要有个结束要交付的成果物，这个成果物会被先用来判断这个用户故事是否完整准确表达了客户的实际需求。

2、Task（任务）。任务可以跟用户故事挂钩，当然不做关联也可以。就例如给电脑搭一套新的开发环境，或者去研究机器 cpu 内存的事宜，这些任务就没必要跟用户故事扯上关系。

3、Backlog（清单）。好些个用于未来冲刺计划的用户故事和任务组成的列表就是Backlog。

4、Sprint backlog（冲刺清单）。从Backlog中抽取的几个用于本次冲刺计划的用户故事和任务(或者称作待办事项)集合成的列表。

5、Product increment（迭代成果）。每次冲刺计划后形成的可以交付的成果物。

6、Extensions（文档表格）。像燃尽图，流程图之类的，用于把控团队流程的文档。

角色有哪些

1、Development Team.（开发成员组）这个小组中包含了测试，前端开发，需求分析师，等等所有迭代开发程序需要的人员。Scrum 的成员基本上会控制在3-9人。假如说人员扩充超过了9人限制，就需要将团队一分为二。

2、Scrum Master（敏捷专家），SM 们需要主持召开每日的站会，以及开发前的计划会议、开发中的梳理流程会议、开发后的回顾总结会议，还有个重任是要帮助团队成员们解决所有关系到沟通的事宜。SM 不是开发小组的成员，所以多个敏捷小组可以同时共享一名Scrum Master。

3、Product Owner（产品经理），站在客户的立场，用客户的眼光（这样的视角可以更贴近现实情况地编写用户故事）来帮助敏捷团队开发，PO 的工作还包括评定用户故事的优先次序，并在每次冲击计划完成后评估交付的成果物是否符合要求。

价值点：

1、目标性明确（完成每一次的冲刺计划）

2、有勇气（敢于做大家一致认同正确的决定）

3、有专注度（每次的迭代只专注一个事项）

4、开放性（积极面对各种各样的挑战）

5、相互信赖（彼此相信都在用尽自己最大的努力做事情）

二、看板方法

看板方法是由一位丰田公司叫大野耐一的工程师创建的（译者注：现代软件看板之父为 David J. Anderson）。在上世纪40年代末期，丰田的经销商们目睹了大型超市们如何根据卖场的货物供销数据来安排库房中的库存比例。这使得丰田公司开始着力打造这样一种供应链体系，要根据汽车使用寿命周期中的零件损耗来评估存储和供应安排。

看板方法的主旨在抑制供应过剩。看板方法通过借助看板卡片和看板这些可视化的实物，将产品周期中的物资流动关系展示出来。这样的可视化管理最大程度地帮助人们看到整个流程的运转，辅助管理层及时准确地制定供应计划。

看板方法还引入了“pull”这个概念，相比较传统的“push”概念，让工人们在流水线上拿着固定薪水劳作或者强压给员工一系列的待办事项去完成，“pull”体现在能者多劳，多劳多得。

在软件开发中。看板方法意味着在许多代办事项中，一个事项只能同时有一个流程。换而言之，在一个团队看板上的“正在进行中”的这一列中，张贴的看板卡片数目是有上限的。这样做可以增加团队的专注度，同时还减少了大家相互沟通的障碍。

看板方法的另一个精髓就是严格的用户需求导向，并且要不间断地跟客户沟通交流。直到真正意义上为客户带来效益，才算开发周期的完结。

准则

1、专注：减少同时参与处理多项事情。

2、减少浪费。

3、客户需求第一位。（换而言之，要保证用户的投资回报有收益）

实践

1、可视化

2、在流程中把控工作

3、流程管理（主要体现在管理工作流程或者工作流程中的事项）

4、确保标准的清晰明了

5、使用用户反馈机制

6、实验优化迭代

看板方法和 Scrum 模型的主要区别是，看板方法是连续不间断的而 Scrum 是不断重复一个流程来达到迭代。看板方法更适合那些需要在开发周期中处理很多不确定的工作的团队（售后支持、紧急情况的处理，突发的重要请求等等）。

如此一来，不像 Scrum 必须要等待一个迭代结束，看板方法支持事项一出现就开始进行工作，甚至连安排任务的优先级这一步都省却了。

三、精益软件开发

为了更好帮助你了解本段的主旨，最好的方法是先介绍下精益开发的创始人 Mary Poppendieck 的故事。在80年代，Marry 发现自己遇到了一个困境。

她那时在一家生产录像带的大型工厂任职 IT 部门主管，那时这家工厂的行程计划表还是要用当时流行的 MRP 来制作。工厂的生存环境在一个很危险的境地里，因为他们日本的竞争对手生产的是更高质量的录像带，这种录像带播放更流畅而且售价更便宜。

这迫使 Marry 考虑使用他们竞争对手的“准时制生产”策略。于是她拜读了被翻译成很蹩脚英文的一位丰田高管写的一本书，就开始付诸行动。结果，几乎是立竿见影就带来了变化，工厂的周生产计划从60%提高到95%。

这次的巨大成功让她连同这家工厂获益良多，也奠定了她日后跟自己丈夫 Tom Poppendieck 撰写精益软件开发流程的基础。源于精益开发很多地方借鉴了看板方法，你能从两者间发现很多的相似处。

就像看板方法一样，精益讲究减少浪费并追求客户利益最大化。浪费可能会体现在创建错误的角色，项目出现空档期，多任务同时进行，不断切换工作事项，浪费时间做那些永远不被采用或者永远不会再次启用的东西。

精益开发也从看板那里继承了“pull”的概念，就是要相信你的同事们在用尽他们最大的努力去完成工作（跟 Scrum 的相互尊重是一个道理）。

至于不同之处，区别于看板方法，精益开发有一些要求工程师具体行动的行为准则（比如TDD 准则）。同时，精益开发没有那么严格把控交付时间，团队可以在一切就绪的情况下随时交付产品。

还有一些其他跟精益开发紧密相关的概念，比如：最小可交付产品，就是尽可能快的交付你的产品，这个时间点通常是在还没形成任何文档的时候。还比如快速失败概念和尽可能晚地达成捆绑协议（例如主营业务的决定之类的）

四、XP 极限编程

极限编程是由 Kent Beck 发起的一项实验演化来的，那时的 Kent Beck 在 Chrysler 任职。这个实验的初衷是要探索在极端情况下采用极致的编程策略会发生什么。例如，用结对编程来替换以往的代码复查，当然技术环节的代码评审还是不可以省略的。渐渐的，随着越来越多的公司开始采用极限编程，一些固化死板的规矩也开始被忽略省去，例如每天的集成测试等。

如今，极限编程被那些采用其他敏捷框架的团队揉和在各自的框架中去最大限度地发掘团队成员的开发潜力。

这里还需要纠正一个错误的概念，极限编程不仅仅只是结对编程。这只是极限编程很多种实操过程中的一项而已，极限编程还同时为流程管理提供了一套推断体系。

还需要说明的是，理论上所有的极限编程的实操应该同时组合使用，否则一切都是徒劳。也是因为如此，评论家们是这么评论极限编程的，“好比两条剧毒的蛇绕成一个圈在吞食对方的尾巴”或者“就是一座纸牌屋”，只要其中任何一个细节出错，都会影响到全局成败。

极限编程在企业管理者中也受到了批判。比如，极限编译要求时刻与客户沟通，但实际中，客户的经常到访总会让人感受到是一系列的压力。同时，不注重形成需求文档和开发文档有时反倒是没有效率。

价值点：

极限编程和 Scrum 有很多的关联性，如下：

和看板方法，精益开发一样，极限编程也在追求减少浪费，专注于眼下的代码开发而不是考虑明天的计划或者下个月的安排等等。这种机制被称作“YAGNI”方法（你压根就不需要这些玩意）。当然，他们还有个相同之处就是都强调跟客户走到一起共同完成。

实操方法

1、计划游戏

2、测试驱动开发（先写单元测试）

3、结对编程

4、形成一个团队（客户以及软件的真正使用人的意见反馈）

5、持续集成

6、系统层面的重构改进

7、最小交付物

8、编码标准

9、代码统一保管

10、精简设计

11、使用系统化名（用大家相互理解的规则给开发人员、客户、以及其余相关人员命名）

12、讲究循序渐进（不提倡加班）

总结

本文里，笔者试着阐述了四种敏捷框架（ Scrum, Kanban, Lean, and XP）的不同之处。就像文章开篇说到的，实际工作中不可能只用到一种特定的框架，团队们都会掺杂着四种框架的实操手段应用到各自的工流程中。