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

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

一些团队或是通过结合Scrum和看板的技术，或是使用Scrumban，或是使用自己团队独特的方法，获得了这两个领域的最佳效果。我收集了一些资源，概述了每种方法所面临的挑战，也会展示出几种以不同的方式结合Scrum、看板来减轻这些挑战的方法。

一、Scrum和看板之间的区别

Scrum和看板在许多方面是相似的：

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

实际上，相对而言，Scrum更具规范性，需要一些特定的组件：

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

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

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

由于规则很少，所以看板能够很轻松地应用到Scrum中。大多数Scrum团队已经通过使用任务板来可视化工作流。

二、Scrum带来的挑战

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

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

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

Scrum的支持者认为，短迭代和强制性的回顾将提供持续改进过程和产品所需的反馈。有时间限制的Sprint虽然具有挑战性，但也有助于制定纪律和结构。从理论上讲，出现超出最后期限的失误，将帮助团队学习如何更准确地计划Sprint，而不是为了成果作出过度承诺。Sprint很短，所以， 其中的任何失败都要被视为学习和改进的机会。

三、看板带来的挑战

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

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

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

如果没有强制性的回顾，团队有可能不会花时间去定期反思和改进。但精益原则中，团队确实会定期进行PDCA (plan-do-check-act)，许多实践看板的团队即使没有被强制要求，也会定期主持回顾。

四、结合Scrum和看板

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

Corey Ladas是这样解释的：“当你在适当的地方建立一个更优化的解决方案时，Scrum是一个能够让团队团结在一起的支架。在某种程度上，你可以蜕掉茧，让牵引系统展开翅膀，起飞。”

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

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

事实上，许多组织都有使用看板而不使用有时间限制的Sprint的团队，例如 系统管理员团队；还有一些使用Scrum而不使用有时间限制的Sprint的团队，例如 新功能开发团队。

五、找到起点，然后出发

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

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

尽管敏捷专家们对细节或术语有不同的看法，但大家都认为定期反思和改进是有益的，并且是所有敏捷方法的共同之处。首先要了解Scrum和看板背后的精益和敏捷概念，并定期进行反思和改进。