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

Posted 2021-04-25 360linker

虽然本文主旨是要对比上述的四种方法，不过要是较真地来分析他们的不同，实际感觉上就好比要比较苹果和橘子的不同有哪些。因为他们其中有的就是从另一种方法衍生而来或者是另一种方法的补充罢了。

一、Scrum 方法

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

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

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

敏捷开发的四句宣言

• 个体与交互 胜过 过程与工具

• 可以工作的软件 胜过 面面俱到的文挡

• 客户协作 胜过 合同谈判

• 响应变化 胜过 遵循计划

二、看板方法

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

看板方法和 Scrum 模型的主要区别是，

看板方法是连续不间断的而 Scrum 是不断重复一个流程来达到迭代

看板方法更适合那些需要在开发周期中处理很多不确定的工作的团队（售后支持、紧急情况的处理，突发的重要请求等等）。

三、精益软件开发

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

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

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

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

四、XP 极限编程

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

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

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

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

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

总结 

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

360linker

与你携手同行