敏捷框架大PK：Scrum 方法 vs 看板方法 vs 精益开发 vs 极限编程

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

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

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

• 敏捷框架对比： Scrum 方法 vs 看板方法 vs 精益开发 vs 极限编程，4种敏捷框架有啥核心区别？

敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

什么是敏捷开发？

敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法。

怎么理解呢？首先，我们要理解它不是一门技术，它是一种开发方法，也就是一种软件开发的流程，它会指导我们用规定的环节去一步一步完成项目的开发；而这种开发方式的主要驱动核心是人；它采用的是迭代式开发；

为什么说是以人为核心？

我们大部分人都学过瀑布开发模型，它是以文档为驱动的，为什么呢？因为在瀑布的整个开发过程中，要写大量的文档，把需求文档写出来后，开发人员都是根据文档进行开发的，一切以文档为依据；而敏捷开发它只写有必要的文档，或尽量少写文档，敏捷开发注重的是人与人之间，面对面的交流，所以它强调以人为核心。

什么是迭代？

迭代是指把一个复杂且开发周期很长的开发任务，分解为很多小周期可完成的任务，这样的一个周期就是一次迭代的过程；同时每一次迭代都可以生产或开发出一个可以交付的软件产品。

有哪些敏捷开发方法？

敏捷不是指某一种具体的方法论、过程或框架，而是一组价值观和原则。符合敏捷价值观和原则的开发方法包括：极限编程（XP），Scrum，精益软件开发（Lean Software Development），动态系统开发方法（DSDM），特征驱动开发（Feature Driver Development），水晶开发（Crystal Clear）等等。
所有这些方法都具有以下共同特征：

1. 迭代式开发。即整个开发过程被分为几个迭代周期，每个迭代周期是一个定长或不定长的时间块每个迭代周期持续的时间一般较短，通常为一到六周。

2. 增量交付。产品是在每个迭代周期结束时被逐步交付使用，而不是在整个开发过程结束的时候一次***付使用。每次交付的都是可以被部署到用户应用环境中被用户使用的、能给用户带来即时效益和价值的产品。

3. 开发团队和用户反馈推动产品开发。敏捷开发方法主张用户能够全程参与到整个开发过程中。这使需求变化和用户反馈能被动态管理并及时集成到产品中。同时，团队对于用户的需求也能及时提供反馈意见。

4. 持续集成。新的功能或需求变化总是尽可能频繁地被整合到产品中。一些项目是在每个迭代周期结束的时候集成， 有些项目则每天都在这么做。

5. 开发团队自我管理。拥有一个积极的、自我管理的、具备自由交流风格的开发团队，是每个敏捷项目必不可少的条件。人是敏捷开发的核心。敏捷开发总是以人为中心建立开发的过程和机制，而非把过程和机制强加给人。

一、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（文档表格）。像燃尽图，流程图之类的，用于把控团队流程的文档。
Scrum流程图

角色有哪些

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

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

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

价值点：

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

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

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

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

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

什么是Sprint？

Sprint是短距离赛跑的意思，这里面指的是一次迭代，而一次迭代的周期是1个月时间（即4个星期），也就是我们要把一次迭代的开发内容以最快的速度完成它，这个过程我们称它为Sprint。

如何进行Scrum开发？

1、我们首先需要确定一个Product Backlog（按优先顺序排列的一个产品需求列表），这个是由Product Owner 负责的；

2、Scrum Team根据Product Backlog列表，做工作量的预估和安排；

3、有了Product Backlog列表，我们需要通过 Sprint Planning Meeting（Sprint计划会议） 来从中挑选出一个Story作为本次迭代完成的目标，这个目标的时间周期是1~4个星期，然后把这个Story进行细化，形成一个Sprint Backlog；

4、Sprint Backlog是由Scrum Team去完成的，每个成员根据Sprint Backlog再细化成更小的任务（细到每个任务的工作量在2天内能完成）；

5、在Scrum Team完成计划会议上选出的Sprint Backlog过程中，需要进行 Daily Scrum Meeting（每日站立会议），每次会议控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你今天要完成什么，同时遇到不能解决的问题也可以提出，每个人回答完成后，要走到黑板前更新自己的 Sprint burn down（Sprint燃尽图）；

6、做到每日集成，也就是每天都要有一个可以成功编译、并且可以演示的版本；很多人可能还没有用过自动化的每日集成，其实TFS就有这个功能，它可以支持每次有成员进行签入操作的时候，在服务器上自动获取最新版本，然后在服务器中编译，如果通过则马上再执行单元测试代码，如果也全部通过，则将该版本发布，这时一次正式的签入操作才保存到TFS中，中间有任何失败，都会用邮件通知项目管理人员；

7、当一个Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，这时，我们要进行 Srpint Review Meeting（演示会议），也称为评审会议，产品负责人和客户都要参加（最好本公司老板也参加），每一个Scrum Team的成员都要向他们演示自己完成的软件产品（这个会议非常重要，一定不能取消）；

8、最后就是 Sprint Retrospective Meeting（回顾会议），也称为总结会议，以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮Sprint的产品需求中；

二、看板方法

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

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

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

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

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

准则

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

2、减少浪费。

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

实践

1、可视化

2、在流程中把控工作

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

4、确保标准的清晰明了

5、使用用户反馈机制

6、实验优化迭代

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

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

三、精益软件开发http://www.scrumcn.com/agile/scrum-knowledge-library/agile-development.html#tab-id-8

为了更好帮助你了解本段的主旨，最好的方法是先介绍下精益开发的创始人 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、讲究循序渐进（不提倡加班）

管理常用工具

1、ZenTaoPHP轻量级的PHP项目管理开发框架，一开源的项目管理软件
官网：http://www.zentao.net
下载：http://www.zentao.net/download

2.Jira + Confluence      基于Java 收费模式 包含Bug追踪和Wiki
官网:http://www.atlassian.com/software/jira/
在线演示站点：http://jira.fangwai.net/secure/Dashboard.jspa

3.XPlanner 采用极限编程开发(XP)流程              　
官网：http://www.xplanner.org

4、leangoo领歌，一款基于看板的项目协作软件
https://www.leangoo.com/

总结

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

数据来源：
敏捷官网：https://www.agilealliance.org/
scrum中文网：http://www.scrumcn.com/agile/scrum-knowledge-library/agile-development.html

作者：君临天下夜未央
链接：https://www.jianshu.com/p/16ba0f7cf02b
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。