Kanban和Scrum的真正区别 | Al Shalloway

这篇博文分两部分贴出。第一部分主要谈Kanban和Scrum的不同，第二部分则描述在此基础上我们应该怎么做。很多人都不愿意谈论Kanban和Scrum之间的区别。有些人说它们没有可比性，好比苹果之于橘子，根本就是两个不同的东西。很多人（几乎都来自Scrum社区）竟然说应该质疑打算对两者进行比较的动机才对。但我相信它们是可以比较的，而且应该进行比较。虽然两者可能不同，但是其初衷都是相似的，即都是为了改进软件产品或IT开发部门的工作方式。因此，如果我想努力提高自己的软件开发能力，就会好好看一看两者之中哪一个更有成效。

至于我的动机嘛？很简单，我只是想帮助人们找到适合自己的正确方法。

世上没有万灵药，这是大家的共识。然而仍然有很多人跑来说“就用这个！”这偏偏对我不起作用。 我们放在第一位的理念是：在企业敏捷转型中，Kanban和Scrum只能覆盖企业中受其影响的部分领域。我们想帮助客户选用符合他们实际需求的方法。所以我们会同时针对这两种方法进行开课和辅导，不过分操心单一方法论顾问可能面临的问题。

远不止是“迭代”

对Kanban一知半解的人认为Kanban和Scrum的区别在于：Kanban不像Scrum那样进行迭代。如果这也算是区别的话，那么另外还有4个受Kanban缔造者David J. Anderson认可的区分标准。

让我们一起看一下Kanban和Scrum之间的区别，看看它们是怎么联系在一起的。

策略显示化

Kanban的一个重要原则是：定义工作流时，需要有明确的策略。有证据表明，这样做将极大促进团队成员之间相互学习，因为团队成员会主动讨论如何有规律地开展工作。在应用Scrum的十多年中，我们注意到团队通常是通过大量回顾会议活动来学习。而对Kanban board进行审视就像是一种每日的小型回顾。不幸的是，Scrum社区的大部分人坚信这是不可保证的甚至是不可能的，具体内容可以参考两个CST的评论：The Agile Value Stream Mapping （Alan Cyment，注1）， Scrum and Kanban – different Animals （Tobias Mayer，注2）。

控制WIP

Kanban的核心实践之一是控制WIP的数量。这能够使团队保持专注力，避免由于工作环节之间的延迟而产生新的工作。Scrum的常见的障碍之一是在Sprint结束时仍然还有很多内容在做测试。控制WIP同样可以帮助Scrum团队。这也需要有明确的策略。

流程可视化，而不只是结果可视化

具备明确的策略意味着管理者可以看到团队为了完成目标当前正在做的事。受益于此，管理者可以看到团队是如何工作的，进而更主动地为团队清除障碍。更重要的是，这样的可视化将带来下一个区别......

内建管理

Kanban的可视化改变了管理者和团队之间的关系。在必要时，管理者可以对团队进行辅导和指引。在管理者认识到团队在尽其所能的同时，也会理解有时候团队不能看到所有需要做的工作。另一方面，Scrum告诉管理者要相信团队，不得进行任何干涉或打扰。具有讽刺意味的是，团队也不相信管理者在他们需要时能进行适当的“干涉”（这里指的是辅导或答疑）。

在实际应用Kanban和Scrum的过程中，内建管理是非常重要的。

• 在Kanban中，因为管理者了解团队是如何工作的，所以能更好地理解他们的要求对团队的影响。在David Anderson的标志性书籍《看板方法：科技企业渐进变革成功之道》（Kanban: Successful Evolutionary Change for Your Technology Business）中，讲述了在管理者了解了超过团队设置的WIP限制后将发生什么，管理者和团队之间的关系将发生怎样的显著变化。管理者也许还会将一些额外的工作分配给团队，但是他们肯定知道这将降低团队的工作效率。有时候，舍弃一些工作是值得的。

• 另一方面，Scrum无法让管理者洞察到谁可以在这个Sprint中多完成一项工作。Scrum Master会坚持立场，并提醒管理者他们曾达成过一致意见，仅让团队工作在Sprint承诺中的内容，这种典型的做法我们称之为CLM（career limiting move，职业生涯限制移动）。Scrum的Sprint天生就是黑盒的，管理者不可能理解为什么仅仅增加一项工作就是灾难性的，反而他们会认为是因为团队不能真正地相互合作，才不情愿接受更多工作。相反，Kanban可以让管理者洞察到这些，因为他们能看到团队是如何工作的。如果他们想插进一个紧急事项，就可以放手去做。但还是要清楚地认识到，这样会对团队产生不良的影响，拉长其他更重要工作的完成时间。

向团队上游扩展价值流

通过内建管理，Kanban可以直接影响到输入给团队的产品管理。这个扩大的范围让开发团队受益匪浅，因为团队中明显过载的工作将被移除。管理者开始领会为何以及如何设置工作层级来最大化团队（产生实际价值的）生产力。

流 vs 迭代

Scrum是需要迭代的。有了迭代的帮助，只要团队足够高效，能够遵从在Sprint结束时完成全部工作规则，Scrum的所有方法都将生效。不幸的是，大部分团队都会因为不可控制的问题而无法做到这点。在将工作打包进1~4周的迭代后，即使没有意识到，团队也会被迫控制其WIP，但这也需要他们能在Sprint结束时真正完成所有的工作。在这个过程中，Scrum团队经常会遇到很多问题，因为没有人向他们清楚地解释必须遵循的原则。

虽然Kanban团队不需要迭代，Kanban还是建议进行有节奏地输入和发布。大部分时候不需要预留时间进行计划、或者给出一个迭代的承诺（有时这个任务会引起冲突，而且是浪费时间的）。如果需要，他们可以这么做，但不是强制的。当Kanban与迭代结合时，为了区别于不明确要求管理WIP的标准Scrum以及不使用迭代的Kanban，通常被称作Scrumban。

...还有最大的区别：可控的变革管理

正是这些区别使得Kanban可以做Scrum做不到的事情：控制转型中的变革速度。这才是Scrum和Kanban最大的区别。使用Kanban，你可以从现有情况出发，通过控制WIP限制，逐步调整流程变革的速度。然而，Scrum经常需要组织进行急剧地变革。如果之前不存在跨领域团队，那么创建这样的团队就可能很痛苦或者实际根本不可能。即使能够完成团队创建，期间需要进行的变更也会给组织带来混乱，让团队成员无所适从。

总结

Kanban和Scrum的区别汇总如下：

	Kanban	Scrum
策略显式化	是	不可行的
控制WIP	是	没有提及，没有明确的策略就不知道怎么做
流程可视化	输入、工作、输出	只有输入、输出，工作是黑盒状态的
管理	内建的	管理者只能旁观
价值流	包含跨产品的产品管理	负责单一产品的单元团队
变革管理	可控的	必须改为Scrum模型——即使是扰乱性的

尽管还存在其他区别，但这些是最主要的。

结论

如果没有学术上的证据，也许不可能明确回答这个问题：哪个理念是正确的。不过，还是有两点是值得思考的：

• 首先，相当多Kanban思想领袖在采用Kanban之前都用过Scrum。有一些人现在仍然是两者都用。虽然我不会因为他们是专家就什么都听他们的，但是我还是坚信只有成功应用过Kanban和Scrum的人，才能真正讲出它们之间的区别。正是这些人提到：Kanban能在Scrum根本无法落地的某些场景中生效。

• 其次，很多案例表明，Kanban团队通过明确定义策略可以显著改善结果。我从未听说过哪个Kanban团队没有做到这一点。曾在Scrum中折戟的团队，总是可以在Kanban的帮助下取得改进。

更多精彩内容请长按一下二维码，关注我们的微信公众号：互联网plus管理新范式。

• 回复：Scrum，看David如何比较Kanban和Scrum

互联网plus管理新范式

Agilean官方博客平台

微信号

iPlusLeadership

点击

阅读原文

访问英文博客

注1：http://www.cyment.com/blog/2009/09/the-agile-value-stream-mapping-oxymoron/

注2：http://agileanarchy.wordpress.com/2009/09/22/scrum-kanban/