Scrum 和 Kanban 在中国乃至全球都是最为流行的敏捷开发方法，选择哪一种？又或者两种同时使用？这是大多数敏捷转型者都要思考的问题，本文将提供一些关键的考虑因素。
Scrum 和 Kanban 是关于敏捷开发和项目管理的两种不同理论框架。Kanban 是灵活的持续交付模式，而 Scrum 是结构化的短期工作模式。
敏捷是一套价值观和原则，对敏捷团队具有指导意义。DevOps 是一组实践、方法与系统的总称，用于促进开发、技术运营和质量保障（QA）部门之间的沟通、协作与整合。在实施敏捷开发和 DevOps 时，Scrum 和 Kanban 提供了不同的方法。
表面来看，很容易发现 Scrum 和 Kanban 之间的区别，但其实两者的原则大体上是相同的。这两个框架都将帮助您更高效地打造好的产品和服务。 那么，对于两者我们应该怎么作选择呢？
敏捷是一种结构化的迭代项目管理和产品开发方法。它根据开发需求不断变化的特点，指导团队在不偏离轨道的情况下应对变化。如今敏捷开发理论已经普遍应用于大多数开发团队，因为没有谁可以在固定的黑匣子中开发一种产品数年甚至数月。 Scrum 承诺通过固定的迭代交付完成增量工作。他们的目标是通过不断循环固定周期来快速收集和实现客户反馈。Scrum 团队采用特定的角色，并定期举行特定会议来保持进展。
Kanban 将团队工作流程可视化，限制每个流程的工作数量，最大限度地提高工作效率。Kanban 团队专注于提升研发效能。他们通过使用看板并不断改进工作流程来做到这一点。
一、Scrum：结构化的敏捷开发方法
通过 Scrum 敏捷开发，团队承诺在每个迭代结束时交付一些有价值的工作增量。Scrum 建立在经验主义之上，专注于小的工作增量。以下是它的工作特点：
1、工作节奏
Scrum 工作进展迅速，迭代周期通常持续一至四周，有明确的开始和结束日期。由于开发周期较短，复杂任务通常被拆分为小的用户故事。同时对研发团队发布代码的质量和速度有一定要求。
Scrum 迭代工作由迭代计划、每日站会、迭代演示会、回顾会构成，这些会议随着一个个迭代持续反复地进行。
2、团队角色
Scrum 具有三个明确定义的角色：
- 产品负责人（Product owner）代表业务需求方，管理产品待办列表，并帮助开发团队规划工作优先级
- 敏捷教练（Scrum）指导开发团队遵循 Scrum 敏捷开发原则
开发团队 负责计划完成的工作并交付增量，体现集体责任感
那是谁管理 Scrum 团队呢？其实没有任何人。Scrum 团队是自发组织的，尽管职责不同，但每个角色都是平等的。团队以向客户提供价值为目标而聚集到一起。
3、数据指标
Scrum是 Scrum 团队可以用来提高工作效率和有效性的依据。数据指标可以为工作决策提供参考信息，并帮助团队提高执行效率。在迭代规划阶段，团队可以参考迭代目标、团队速率、团队容量等维度的数据。在每日站会上，团队还可以从迭代目标的进度、迭代燃尽图、工作负载分布等指标中帮助了解工作进展，及时调整工作安排。
4、拥抱变化的理念
Scrum 团队一般会在固定迭代周期中承诺交付多少的价值增量。但是，Scrum 团队也可以在迭代中采纳客户反馈，鼓励团队调整和改变迭代计划来提供最大的客户价值。但不是说团队可以在冲刺中频繁更改工作范围，因为变化会使可交付增量潜在风险。团队会因为没有充分理解迭代计划的工作，或者被业务或计划外工作扰乱了进度。因此在迭代回顾期间，Scrum 团队可以讨论变化的边界、如何更好地控制和拥抱变化。
二、Kanban ：持续性交付方法
Kanban 有助于将工作进展可视化，限制在制品 (WIP) ，并且快速将工作从“开始”转移到“完成”状态。Kanban 非常适合有大量优先级工作的团队。相比 Scrum 流程对工作范围严格控制，看板让团队工作更加顺其自然。以下是 Kanban 五个要素，可以帮助您了解更多。
1、工作节奏
Kanban 基于持续交付的工作原则，让团队时刻准备和应对不断变化的工作优先级。工作内容（以卡片为载体）在看板工作栏上按团队规定的工作流程移动。常见的工作流程是“待办”、“进行中”、“被阻止”和“已完成”，但这不是固定的。
看板最灵活的是可以根据团队工作方式自定义工作流程。比如我们团队需要交付某项工作，看板上会进行待办事项列表优先级梳理、补充详细描述信息，再到计划、设计、开发、测试、发布等活动。而看板会帮助我们了解大概什么时间段会进行交付，以及我们当前工作中是否存在交付瓶颈。
2、发布方法
在看板中，工作内容一旦完成即可发布，没有固定的截止日期。理论上，Kanban 没有规定工作交付的发布时间。如果工作较早（或较晚）完成，则可以根据需要发布，无需像 Scrum 迭代那样等待发布的里程碑节点。
3、团队角色
Kanban 团队每位成员都有权利查看看板工具上的内容。与 Scrum 团队会聘请敏捷教练指导团队工作不同的是，Kanban 团队不需要“看板教练”来让工作顺利进行，因为整个团队的集体责任是协作完成板上的任务。
4、关键指标
交付周期是衡量 Kanban 团队速率的重要指标，这是指工作从开始到结束所花费的平均时间。改进交付周期可以促进团队发展。
累积流图 (CFD) 是 Kanban 团队用来了解每个状态的工作项数量的另一种分析指标。累积流图有助于团队识别特定流程中需要解决的工作，帮助团队获得更好的工作吞吐量。
处理瓶颈的另一种方法是在制品限制（WIP）。在制品限制可以控制在任何流程中的工作卡片数量。当工作达到限制额时，工作会禁止进入该流程，这有利于推动团队共同解决问题，加快工作进程。
5、拥抱变化的理念
看板工作流程可以随时更改。新的工作内容可以添加到待办列表中，现有的工作卡片可以根据优先级暂停或停止。此外，如果团队容量发生变化，可以重新校准在制品限制并相应地调整工作量。这一切都与 Kanban 项目的灵活性有关。
三、Scrum 工具与 Kanban 工具
敏捷团队经常先选择了项目管理的工具而被动选择开发框架，从而固定了团队采用的开发原则。其实选择的顺序应该是相反的，我们第一步应该选择适合团队的敏捷开发框架。比如，一旦确认了团队采用 Scrum 框架，就可以找到一个可以更好为团队服务的 Scrum 工具了。
Kanban 也是如此。作为专注国内敏捷团队的研发管理工具，我们 PingCode 可以满足您的需求。我们提供使用 Scrum 或 Kanban 专用项目类型，您可以任意选择并实践。
四、Scrum vs. Kanban：如何选择？
Scrum 和 Kanban 是被无数研发团队实践总结出来的工作方式。团队不会因为选择了 Scrum 或 Kanban 而无法开展工作。而且我们不是只能选择一种。目前有数百个团队正在使用 Scrum 和 Kanban 的混合模式，我们 PingCode 也不例外。另外 PingCode 研发管理工具还支持在 Scrum 项目中融入 Kanban，满足团队更多的敏捷研发场景：
当同时管理多个项目时，团队可以根据不同项目的敏捷特性来选择不同的模式：无论是 Scrum、Kanban 还是两者兼而有之，毕竟团队的项目不是一天就能适应一种模式的，我们可以先让团队尝试哪个模式更有效再做选择。
因此，您可以放心地选择Scrum 和 Kanban，因为这两种模式都可以发展以满足研发团队的工作需求。 不管团队最终选择哪种模式，我们都要坚持实践一段时间。从待办工作一直到交付完成，然后团队要去讨论和总结过程中哪些工作做得好，哪些做得不好。通过不断尝试 Scrum 和 Kanban 提出问题并分析原因，这样的话，团队可以更快地掌握敏捷开发的秘诀。
