Scrum vs Kanban：这两种方法孰优孰劣？

自敏捷运动以来，Scrum 一直在众多敏捷方法论中居于主导地位。尽管如此，很多组织在实践Scrum时也会陆陆续续地遇到一些问题，基于此，组织开始在软件开发工作中使用看板模型。不论是Scrum还是看板，这两种方法论都有自己的优缺点。

一、Scrum和看板之间的区别

• 两者都是 经验模型，都包含了精益和敏捷开发的原则；
• 两者都鼓励 早期和频繁的交付、 自组织的团队、 持续改进，以及基于业务价值的需求优先级排序。

• 角色：Scrum Master、产品负责人及开发团队
• 工件：Product Backlog、Sprint Backlog和产品增量
• 限定时间的事件：Sprint，包括：Sprint计划会议、每日站立会议、Sprint评审会议和回顾会议等。

Scrum指南为每一组件、每一步骤都给出了非常具体的指导方针，并且在期望团队遵守方面相当严格，Scrum Master的主要职责是“ 确保Scrum的深入理解和实施”。

另一方面，看板不是指令性的。它只有三条规则： 可视化工作； 限制在制品(WIP）； 测量并改进流程。

二、Scrum带来的挑战

Scrum指南强调， Sprint必须限定在一个月或更短的时间内(通常为两周)，并且每一Sprint应该为每个增量带来潜在的可发布产品。一些团队认为，有时间限制的Sprint会降低团队的工作速度，带来不必要的开销。

此外，由于Scrum团队需要在每个短Sprint结束时交付符合生产质量的、可运行的软件。所以团队被迫在很短的时间内设计、编码和测试他们的代码，并向整个团队、管理层及利益相关者进行演示。这种要求实际上可能会给团队带来更多的焦虑，并非减少焦虑。

在使用Scrum的过程中，团队主要致力于交付他们所承诺的故事点，并将其添加到Sprint Backlog中。然而，在Sprint中，也会存在一些团队无法解决的问题，他们的工作可能会被优先级更高的Bug修复或其他意外打断，导致Sprint Backlog中的故事不能顺利完成。在这种情况下，他们可能会决定偷工减料，以完成“交付”和“评审”这一结果。

三、看板带来的挑战

看板并没有提供一个完备的框架。它不是一种真正的方法论，而是一种技巧。如果在一开始转型敏捷的时候，不先使用一种纪律约束力更强的方法，那么，团队就无法建立起牢固的框架。从这个角度出发，敏捷专家经常建议刚开始转型的敏捷团队从更规范的方法论开始学起，比如：Scrum。

还有的人认为 看板太线性了。最初，看板是在丰田的生产线上使用的，因此许多人认为看板更适合具有可重复过程的情况，而不是像软件开发这样的复杂系统。因此，看板通常被推荐用于维护工作，而不是进行新功能的开发。 

在《看板问题》一书中，Rob Williams指出他的团队很喜欢精益方法，但他们仍然会遇到麻烦：“看板最大的问题是，它是为一个东西只经过一次流水线的世界而设计的(比如汽车制造商)。在软件领域，这几乎是不可能的。”

四、结合Scrum和看板

Corey Ladas是第一个描述Scrum/看板混合方法的人，创造了术语“ Scrumban”。拉达斯在2009年出版了《Scrumban:精益软件开发的看板系统论文集》(Scrumban: Essays on Kanban Systems for Lean Software Development)。在一篇文章中，他描述了这种方法，并建议先从Scrum开始，然后进行优化，直到达到不再需要Scrum强制要求的仪式的程度为止。

但是，删除带有时间限制的事件并不是Scrumban的唯一解释。

在《the Scrumban [R]Evolution: Getting the most out of Agile, Scrum, and Lean Kanban》一书中，Ajay Reddy这样开篇：“尽管Scrumban多年来已经发展成为一个框架，但它并没有明确的指南或定义。正如本书开头所强调的那样，一些“权威”人士对Scrumban的实际含义存在分歧。”Reddy的模型并没有将Scrum和看板混合起来，而是描述为“团队将Scrum作为他们所选择的工作方式，并使用看板方法作为观察、理解和持续改进他们工作方式的透镜。”

五、找到起点，然后出发

敏捷专家对Scrumban的定义持不同意见，这并不奇怪。如果需要根据自己的目的调整敏捷方法时，怎么才能有一个明确的方法呢？要记住最重要的一点，团队需要结构和纪律，这是一个起点。

一般来讲，新组建的团队通常会从更明确的方法论的结构和规则中受益。也会有部分人想要Scrum提供的结构和持续学习的状态，又想要看板提供的连续流，这样的人或者团队可能会从Scrum与看板方法论的混合中受益，也许可以从定义好的Scrumban方法开始。