“Kanban 还是 scrum？”这是每个新领导都会问的敏捷问题，而最敏捷的内容却回答得很糟糕。诚实的答案是，它们的形状不同，适合不同的工作；没有更好或更坏，一旦你了解了每个产品实际提供的内容，就很少会出现非此即彼的情况。这篇文章是实用版本：每一种的真正含义、告诉您哪一种适合的四个信号，以及最成功的混合团队实际运行的情况。
一行的区别
Scrum 是一个节奏。 Kanban是一个流程。
Scrum 说：将工作分成两周的迭代，开始时计划，最后演示，回顾周期。节奏是单位。
Kanban 说：持续拉动工作，限制同时飞行的事物数量，优化流程。流量是单位。
两者都是敏捷的（在价值观意义上）。两者都可以产生优秀的团队，也可以产生功能失调的团队。选择是关于 什么形状 你正在做的工作，而不是你的团队对于看板来说是否“足够先进”。
Scrum 到底是什么
由 Scrum 指南定义。三种角色（产品负责人、 Scrum 大师，开发者），五个事件（冲刺、 规划、 每日例会, 评论, 回顾性的）、三件文物（产品待办列表、冲刺待办列表、增量）。
明确的承诺： 冲刺是价值单位。你承诺在两周内完成一组工作，将其作为一个连贯的增量交付，你反思，然后重新开始。
在以下情况下，这一承诺才有意义：
- 您可以预测 2 周的工作，不会有太多意外
- 作品具有特色；离散的、可设计的、可完成的
- 利益相关者希望定期进行演示
- 团队受益于已知时间间隔的强制反思（回顾）
当出现以下情况时它会崩溃：
- 工作是被动的；支持工单、操作升级、紧急错误
- 项目的大小差异很大，您无法有效地“承诺”冲刺
- 团队的工作是吸收进来的一切，而不是发布功能
看板实际上是什么
没有 Kanban 指南的等效项；看板是一种方法，而不是一个框架。源自精益传统的核心实践是：
- 可视化工作：一个板，其中包含每个工作流程状态的列
- 限制正在进行的工作（在制品)：每列的明确数值限制
- 管理流程：测量工作从开始到结束需要多长时间（周期时间, 交货时间)
- 政策明确：每列中“准备好”或“完成”的含义有明确的规则
- 持续改进：基于流量数据的小实验
就是这样。没有冲刺，没有必要的仪式，没有必要的角色。
明确的承诺： WIP 限制是纪律单位。在某件事完成之前，你不会拉出新项目。周期时间和吞吐量是重要的指标，而不是 速率.
这在以下情况下是有意义的：
- 工作的到来是不可预测的，你无法围绕它计划冲刺
- 项目的大小或完成时间大致相似，因此累积流量视图很有用
- 您想要优化 交付时间 针对单个商品，而非捆绑商品
- 团队足够成熟，可以自我调节，无需强制仪式节奏
当出现以下情况时它会崩溃：
- 团队没有内部动力来反思和改进（回顾被跳过，从未恢复）
- 工作需要明确的跨团队同步（例如，捆绑多个项目的版本）
- 利益相关者期望定期更新“这一时期发布的内容”
适合您的四个信号
当团队问“scrum 还是看板？”时，答案有四个信号。
1. 即将到来的工作的可预测性
- 可预测、可分两周进行计划 → 混乱
- 反应性，无法计划 → 看板
示例：
- 产品路线图上的功能交付 → scrum
- 客户支持第 2 层 → 看板
- 平台/SRE 团队 → 看板（主要）
- 移动应用团队每月发布版本 → scrum
2. 商品尺寸差异
- 物品尺寸大致相似 → 任一作品
- 项目差异很大（1 天到 3 周） → Scrum 挣扎，看板处理它
故事点 部分解决 scrum 中的规模差异，但前提是团队估计得很好。如果你的团队在同一个冲刺中有 1 分和 13 分的项目，你就会不断地承诺不足或过度。具有 WIP 限制的 Kanban 不关心项目大小；它只是限制了飞行中的数量。
3. 利益相关者的节奏期望
- 利益相关者想要一个“这个冲刺即将发生什么”+“交付了什么”的节奏 → 混乱
- 利益相关者希望尽快交付单个物品，而不是分批 → 看板
销售路线图更新的 B2B SaaS 产品团队需要 scrum（或 scrum-shape）。运行 A/B 测试的增长工程团队则不会；他们希望快速地一次交付一个实验。
4. 团队对仪式的兴趣
- 团队重视结构化反思时间 → 混乱
- 团队发现会议让人筋疲力尽并且自我调节良好 → 看板
在这里说实话。许多球队 说 他们想要看板，因为他们讨厌仪式，然后陷入从不反思他们的过程并慢慢退化。 Scrum 的强制回顾抓住了这一趋势；看板的“管理流程”实践只有在有人真正做到的情况下才有效。
大多数团队实际运行的混合动力
纯粹的 Scrum 和纯粹的看板都很少见。对于大多数产品工程团队来说，什么在实践中有效：
Scrumban：scrum 的节奏 + 看板的流程规则。
- 保持两周冲刺作为计划+回顾节奏
- 放弃严格的冲刺承诺；可以在冲刺中通过讨论添加或删除项目
- 在板上每列添加 WIP 限制
- 跟踪速率（用于预测）和周期时间（用于流量健康）
- 每个冲刺进行 30 分钟的回顾，而不是每周
这是有效的，因为大多数产品团队都有 部分地 可预测的工作；他们想要发布的功能，加上反应性错误和小请求。纯粹的 scrum 迫使不可预测的事情进入不适合的冲刺提交。纯粹的看板放弃了利益相关者所需的计划节奏。
这在实践中意味着什么
如果您是一个功能交付产品团队（前端、后端、产品路线图上的全栈）：从 scrum 开始，然后在 6 个冲刺后转向 scrumban。
如果您是平台/SRE/运营团队：从看板开始。进行每月回顾而不是冲刺回顾。
如果您是支持团队或任何超过 60% 的工作都是被动的团队：看板，毫无疑问。
如果您是一个小型初创工程团队（3-6 人）：scrumban 通常是正确的。节奏有帮助，但完整的仪式开销不适合小规模。
工具影响
团队犯的根本错误是选择工具 之前 决定形状。大多数“敏捷”工具都是 Scrum 形状的（冲刺、故事点、 燃尽，速率）并螺栓上 看板 视为事后的想法。有一些是看板形状的（连续流程、WIP 限制、周期时间）并且对冲刺的固定效果很差。
如果您是 Scrum 或 Scrumban，那么 Scrum 型工具就是您的最佳选择。 SprintFlint 围绕冲刺周期（自动速率、本机回顾、冲刺感知燃尽）构建，并具有支持 WIP 规则（如果您愿意）的看板视图。
如果您是没有冲刺的纯看板，请查看流程优先工具（Kanbanize、流程模式中的平面、带有 Power-Ups 的 Trello）。 Scrum 工具安装不方便。
长话短说
- Scrum：节奏优先。计划冲刺、交付、回顾、重复。适合可预测的功能工作。
- Kanban: 流量优先。 WIP 限制、周期时间、无冲刺。适合反应性工作或变化很大的项目。
- 这四个信号：可预测性、项目大小差异、利益相关者节奏期望、团队对仪式的兴趣。
- 大多数成功的产品团队都运行 scrumban；冲刺节奏与看板风格的流程纪律。
- 首先选择形状，然后选择工具。不要让你的工具为你做出选择。