Kanban vs Scrum：为什么 Flow 胜过 Theater，实现真正的交付

Source: Dev.to

Introduction

现在是上午 9:47。你的团队正在争论一个故事是 5 还是 8 分。已经过去四十分钟。没有任何东西交付。

这就是 Scrum theater——大多数组织都在上演。

Scrum theater

Scrum theater 是指仪式照常进行，产出文档，角色也在，但有价值的软件持续交付仍未实现。

• 每日站会沦为 Jira 背诵。
• Sprint 计划产生没人相信的估算。
• 燃尽图先横向移动，然后在第 10 天神奇地完成。

Why Scrum can become corrupted

• Time‑boxing 产生了没有交付压力的人工压力。
• Estimation rituals 奖励玩游戏而非准确性。
• Velocity 成为 Goodhart 法则的典型案例。

Kanban fundamentals

三件事是必不可少的：

1. 工作可视化
2. WIP 限制
3. 流动优化

不需要任何仪式，也不强制任何角色。

Work‑in‑Progress (WIP) limits

WIP 限制提供了强制性因素，使流动问题变得痛苦且可见。当你的 “In Review” 列达到上限时，代码评审立即成为所有人的事——而不是在冲刺结束时才处理。

Metrics

• Velocity 是一个糟糕的预测指标——它是基于被估算、被玩弄且不一致的 story points 计算得出的。
• Cycle time（周期时间）和 throughput（吞吐量）则是依据实际完成情况来衡量的。

一个成熟的 Kanban 团队可以说：

“根据我们历史的吞吐量，这套功能在 3 月 15 日 前完成的概率为 85 %。”

这比 “我们在 Sprint 12 中承诺完成” 更为诚实。

Transition steps

1. Make the current state visible – 绘制实际工作流，可视化所有进行中的工作，并测量周期时间。
2. Introduce WIP limits – 先宽松地引入，随着流动改善再收紧。
3. Decouple from sprint boundaries – 用队列补给取代冲刺承诺。
4. Drop the theater – 消除那些对交付没有帮助的仪式。

Conclusion

这不是 “Kanban vs Scrum？” 而是：“我们真正要优化的是什么？”

大多数团队并不是框架问题，而是交付问题——而框架正掩盖了这个问题。

Originally published at agilelie.com.