Kanban vs. Scrum：哪种敏捷适合您？

概要：“Kanban vs. Scrum”是关于实施敏捷开发或项目管理系统的两种不同策略的讨论。Kanban方法是连续的且更灵活，而Scrum是基于短周期的、结构化的工作迭代。

敏捷是一套理想和原则，是我们的指导思想（请参考敏捷宣言官网）。DevOps是一种自动化和集成软件开发和运营团队之间流程的方法。在实施敏捷和DevOps时，Kanban和Scrum提供了不同的方法。

很容易指出Scrum实践和Kanban实践之间的区别，但这只是表面上的。虽然做法不同，但原则大体相同。这两个框架都将帮助您以更少的代价交付更好的产品或服务。 

更多地关注原则而不是实践，不要问“Kanban vs Scrum”。相反，要问“Kanban或Scrum”，甚至是“Kanban和Scrum”。

那么，我们怎么抉择？

敏捷是一种结构化和迭代的项目管理和产品开发方法。它认识到产品开发的波动性，并为自组织团队提供了一种方法，可以在不偏离轨道的情况下应对变化。今天，敏捷几乎不是竞争优势，因为大家都已经在实践敏捷，没有人可以奢侈地在黑匣子中开发一种产品数年甚至数月。这意味着做到满足客户需求比以往任何时候都更重要。

Kanban就是将您的工作可视化，限制WIP，并最大限度地改善效率或流程。Kanban团队专注于减少项目或用户故事从开始到结束所花费的时间。他们通过使用Kanban并不断改进工作流程来做到这一点。 

Scrum团队承诺通过Sprint的设定周期来完成增量工作，这必须是可交付的工作。他们的目标是创建自学习循环以快速收集和整合客户反馈。Scrum团队采用特定的角色，创建特殊的工件，并定期举行仪式以保持进展。Scrum推广得不错，从互联网上可以找到很多最佳实践的定义。

Scrum：结构化的敏捷方法

使用Scrum，您的团队承诺在每个Sprint结束时交付一些有价值的工作增量。Scrum建立在观测的基础上，专注于小的工作增量，这将帮助您抓住客户需求并更好地告知您下一步做什么。以下是它的明细： 

Scrum节奏

Scrum进展迅速，Sprint通常持续一到四个星期，有明确的开始和结束日期。较短的时间框架迫使复杂的任务被拆分成更小的故事，并帮助您的团队快速理解需求。一个关键问题是：您的团队能否快速发布有用的代码？

Sprint中的Sprint计划、Sprint审查和回顾会议和每日站会相辅相成。这些Scrum仪式是轻量级的，并且持续运转。 

Scrum角色

Scrum具有三个明确定义的角色。

• Product Owner搜集客户需求，管理待办事项列表，并帮助开发团队完成工作的优先级设定。
• Scrum master帮助团队坚持Scrum原则。
• 开发团队选择要完成的工作，交付增量，并展示集体责任感。

谁管理Scrum团队？答案是，没有人。Scrum团队是自组织、自管理的，每个人都是平等的，尽管职责不同。该团队以向客户提供价值为目标而团结在一起。

通用指标

Scrum指标是Scrum团队可以用来改善效率和有效性的数据。这些指标可以为决策提供信息，并帮助团队改善计划和执行效率。在Sprint计划阶段，团队可以使用Sprint目标、团队速度、团队能力和工作类型等指标。在站会期间，团队还可以从衡量Sprint目标的进度、审查Sprint燃尽图、了解工作负载分布等中受益。

处理变更

团队完全了解他们在Sprint时间范围内可以完成多少工作，他们承诺在Sprint结束时交付。但是，Scrum团队可以根据客户反馈，调整和改变Sprint以提供最大的客户价值。在Sprint回顾期间，Scrum团队应该讨论如何限制未来的变化，因为变化会使潜在的可交付增量面临风险。如果团队在Sprint中期频繁更改范围，则可能意味着选择的工作没有得到充分理解。这也可能意味着团队存在干扰性的工作。

有关Scrum方法的更多信息，请参阅文章：什么是 Scrum？

Kanban：持续改进，流程灵活

Kanban有助于可视化您的工作、限制在制品 (WIP) 并快速将工作从“待办”转移到“完成”。

Kanban非常适合有大量优先级和大小不同的外部请求的团队。相比于Scrum流程需要对Sprint范围内的内容进行高度控制，Kanban更加顺其自然。让我们看一下相同的五个考虑因素，以帮助您做出决定。  

Kanban节奏

Kanban基于一个连续的工作流结构，使团队保持敏捷并准备好适应不断变化的优先级。工作项（由卡片表示）在Kanban board上组织，它们从工作流的一个阶段（列）流向下一个阶段。常见的工作流程阶段是待办、处理中、评审中、被阻塞和完成。但这可能与真实业务没有精准匹配。

Kanban最大价值在于为您的团队的工作方式制作自定义列。比如，一个团队的工作是发布文章，所以对应的列可能是从Backlog到Prioritized到Outlines Ready再到Writing、Designing、Technical Review和Shipped，Kanban board帮助团队了解到每周发布的内容，以及瓶颈在哪里。

发布方法

在Kanban中，交付的任务一旦准备好就会发布，没有固定的时间表或预定的截止日期。

理论上，Kanban并没有规定交付任务的固定时间。如果任务提前（或延迟）完成，则可以根据需要发布，而无需等待诸如Sprint评审之类的发布里程碑。 

Kanban角色

整个团队拥有Kanban。一些团队聘请了敏捷教练，但与Scrum不同，没有一个“Kanban Master”可以让一切顺利进行。整个团队的集体责任是协作完成板上的任务。

关键指标

前置时间（Lead time）和周期时间（Cycle time）是Kanban团队的重要指标。处理任务从开始到结束所花费的平均时间。改进周期时间表明Kanban团队的成功。

累积流图（Cumulative Flow Diagram）是Kanban团队用来了解每个状态的工作项数量的另一种分析工具。CFD有助于识别需要解决的瓶颈，以获得更好的吞吐量。

处理瓶颈的另一种方法是通过在制品 (WIP) 限制。WIP限制了同一时间点可以在任何一列中的卡片数量。当您达到WIP限制时，Jira Software之类的工具会限制该列，并且团队会聚焦到这些任务上以推动它们前进。

处理变更

Kanban工作流可以随时更改。新的工作项可以添加到待办列表中，现有的卡片可以根据优先级被阻塞或删除。此外，如果团队能力发生变化，可以重新校准WIP限制并相应调整工作项。这一切都与Kanban的灵活性有关。

有关Kanban方法的更多信息，请参阅什么是Kanban？

Scrum工具与Kanban工具

敏捷认为这种对话不应该只是关于工具的。我们经常看到工具的选择推动了敏捷框架的选择，而框架选择导致了团队采用的原则。这就是本末倒置了。  

只要您的原则与Scrum原则保持一致并对Scrum框架感到满意，那么就该找一个可以很好地为您服务的Scrum工具。Kanban也是如此。总之，作为敏捷团队使用的第一大软件开发工具，我们认为Jira Software可以满足需求。

使用Jira的Scrum和Kanban功能，您可以实现框架相关的原则。当然，前提是我们已经熟悉工具的使用方法。

Kanban vs. Scrum：难以抉择怎么办？

Scrum和Kanban是“敏捷的教科书”。它们以一种久经考验的真实方式工作，这足以证明它们的成功。

但抉择不需要如此非黑即白。数百个团队正在使用受Scrum和Kanban影响的混合模型。在Jira Software中也可以帮助团队这样做，可以按团队管理项目的方式运作。

顾名思义，团队管理的项目允许团队挑选对他们有意义的敏捷特性；无论是Scrum、Kanban还是两者兼而有之。团队管理的项目不是在第一天就实现一个框架，而是让您在了解哪些对您的团队有效（哪些无效）时，可以逐步增加越来越强大的功能。

您可以放心地选择团队管理的Scrum或团队管理的Kanban，因为这两种模板都可以演进以满足您团队的需求。 

不管你选择什么，坚持一段时间。从待办事项的工作一直到完成，然后询问您的团队哪些工作做得好，哪些做得不好。通过尝试Scrum和Kanban并提出这些问题，您就可以顺利享受敏捷的幸福。