关于Kanban有别于Scrum的几点思考 | David博客系列

关于Kanban有别于Scrum的几点思考 | David博客系列

这篇文章是David在2010年的博客，作为David博客系列的开篇文章最合适不过，未来Agilean学院的同学们会陆续将其他优秀博客翻译分享给大家。这篇文章虽然是五年前写的，但是内容到今天也不过时，Scrum五年来也经历了几次改版，被David诟病的承诺驱动被从Scrum Guide上移除，结合五年来的变化看这篇文章会更加有趣。

Scrum、Kanban或其他方法，孰优孰劣？对于这方面的纷争，我一直保持隔岸观火的态度。我也一直非常支持MattiasSkarin和Henrik Kniberg，因为他们在《Scrumand Kanban making the best of both!》一书中对两者进行了精彩的分析和对比。

现在，我觉得可以增加一些个人见解，对Henrik和Mattias没有讲到的东西进行补充。这些想法来源于我过去九个月在全球五大洲周游列国时与敏捷团队和敏捷教练的合作经历，他们有的来自小而美的新创公司，有些来自世界一流的行业和技术企业。

从某一层面上说，Scrum是一种相当规范的项目管理流程，有Sprint，Scrum，Sprint Planning，Retrospective，Demo，等等。当然，Scrum社区的带头大哥还会热切地强调指出，Scrum远不止如此，它作为一个框架，还可以用于在组织中引发变化和促进一些涌现行为。

Kanban不是一种项目管理或者软件开发生命周期管理的方法。它是一种变革管理的方法，一个促进组织变革的框架。所以，它不同于Scrum，不能用作一种工作流程。它需要应用于现有的流程中。现有流程可以是Scrum，或者其他类似的我们都熟悉的生命周期管理方法，甚至那些我们还没有来得及命名的工作流程，即非正式流程。作为一种促进变革的框架，Kanban和Scrum还是有一些可比性的。

两者作为促进变革的框架时有何不同？我觉得自己可以在Kniberg & Skarin没有涉及的这个方面补充一些个人见解。

1.变

革催化剂不同

Kanban使用WIP限制这一控制机制来引发关于变革的对话。不尊重WIP限制、不讨论问题，会导致无进展、无改进。关于改进的讨论涉及可视化、度量、明确策略与模型（来自精益、约束理论和戴明的质量体系）。通过改进讨论，团队可以更科学地分析自己的问题并提出解决方案。

Scrum运用承诺这一控制机制来引发变化。承诺有两个层级：1）个人每日认领--通过Scrum和每日三问“你昨天为我们做了什么？”“你今天要为我们做什么？”“完成今天的目标有什么障碍吗？”2）团队层级，Sprint承诺，承诺在确定的某个日期交付价值。承诺无法兑现，将会进行关于失败的讨论来引发对流程改进。当我们讨论这种方法的有效性，我们自然认为它是可行的。

Kanban使用WIP限制作为变革代理，而Scrum使用的是承诺。这是两种方法论的本质区别。

2.革

命还是演进

Ken Schwaber曾谈到Scrum的一些固有名词，比如Scrum，Scrummaster， Sprint。Scrum对于组织来说是一种休克疗法，经常牵扯到相关人承担新的头衔、角色和责任，而且这往往会引入这样一种变革管理模式：通过培训引入新方法后直接设定固定时间点完成切换。引入Scrum意味着革命：重组组织结构并影响（正面的以及负面的）到团队成员对于专业性的自我认知。不是所有项目经理的价值都是通过一个新的头衔来体现的。对于一部分组织这可能是正确的方法，但对于其他的组织，革命会在员工中产生情绪上的抵触，以及消极的、对抗性的行为。

Kanban以一种完全区别于Scrum的方式带来改变。应用Kanban时，还是从现有的流程起步，通过映射并可视化价值流、限制WIP来创立拉动系统实现“看板化”。角色、责任和头衔都将完整的保留，唯一的变化是上下游之间的接口，比如业务管理和系统运维之间。这些变化是为了避免组织结构的重组或引发相关人情绪上的抵触。

Kanban触发的是逐步演进。开始是流程优化（Kaizen），而后随着组织能力逐渐成熟，再进行更大的、可控的变化（Kaikaku）。按目前的观察来看，有效的kaizen优化将提升组织的成熟度和进行更高层次（Kaikaku）变化的能力。

所以Kanban引入的是一种与Scrum完全相反的模式，Kanban是温和的而Scrum是硬性的处理。

3.需

不需要流程符合度评估

当Scrum作为触发改变的起点和框架时，实践的符合度评估就存在逐步增长的市场空间，其中最有名的而且被JeffSutherland认可的是Nokia Test。这些评估将判断团队是否在遵循Scrum，如果结论是否定的话团队将被称为是Scrum-But，Ken Schwaber用一个特殊的名词Scrum-Butt来形容这些未遵从Scrum的从业者。这种符合度评估的效果是打击了创新，从而背离了书本中的定义。这种实际效果也会给从业者带来这样的困惑：一方面管理层强调Scrum是在促进组织中涌现行为，同时他们又规定了这样一种评估来惩罚那些背离了标准定义的人。

Kanban被设计为一种可定制化、演进现有流程的方法，任何现有流程都可以作为起点，所以就不可能存在对于Kanban的符合度评估。Kanban使用5个基础属性来促进流程演进中的涌现行为：工作流可视化、限制WIP、度量流动、明确流程策略、使用模型评估可改进机会。这代表着必须采用5种Kanban方法的实践来实现改变。团队的软件开发及项目管理的流程往往是独一无二的。同时为了适应价值流、风险、团队能力、客户需求、影响团队的瓶颈及带来差异化的根源，流程还将逐步被调整和优化。这些都无法进行一致性测试。任何可应用的指标都需要对引入Kanban方法后是否产生了更好的经济学、社会学上的影响进行度量。

4.容

器 vs 系统

Kanban团队和Scrum团队实践相比，表现出了一些不同的特性，这些表现的差异大多是没有采用Scrum容器方法所带来的副作用。Sprint（冲刺）是Scrum所采用的容器，指在限定的时间区间内完成一批研发任务，并尽量避免外部的干扰，最理想的状态是没有外部干扰。类似于好的软件架构，Scrum寻求的是最小化容器的接口，以达到松耦合的效果。 理想的效果是尽可能将容器里的活动（冲刺研发）变成可预测，以满足冲刺交付的承诺。

Kanban并没有引入类似的容器，而是鼓励一个全局的系统视角。Kanban采用一些方法来简化系统中各元素的协调。例如，将可视化和WIP限制组合起来的拉动系统，使得业务管理的接口非常简单。使得大多数采用Kanban的团队并不需要Scrum的唯一产品责任人概念，这些团队可以很容易与参加队列补充会议的多个有竞争关系的业务管理方进行合作。

Kanban的每日站会已经被证实对50个或更多人生效。原因是在进行可视化工作流中的任务时，团队获取了充分信任。站会并不是用来强调个人交付承诺，站会可以把焦点集中在任务，而不是具体的个人。团队将在工作卡片中迭代，而不是在团队成员中迭代。Scrum的三个问题可以被取消，更多成熟的Kanban团队减少讨论并专注于阻碍或缺陷，聚焦在异常而不是顺利进行中的工作。

据观察，使用Kanban的团队通过合并较小的团队，可以减少合作开销，并更好地利用人力资源池。可以看到20～30人规模团队很普遍，有时多个Scrum团队， 或者Scrum和非敏捷的混合团队被合并成超过50人的团队。 可视化工作流程经常涉及多排（或泳道）来表示不同的研发工作流， 一些团队成员作为固定的成员被分配到一个泳道，为该泳道的工作负责，与此同时其他团队成员可以跨泳道灵活安排，以提供团队补员或专家技能。这样做的效果是更有效利用人力资源池，产生更多生产力和更短的指导时间。

5.结论

我相信我们仅仅是刚开始了解Scrum和Kanban的区别，随着更多Kanban组织模式被发现， 我们更深入地了解到Kanban和Scrum是不同的。 我们还在学习推广Kanban到Scrum团队会怎样改变团队的组织、文化和目标，我相信Kanban和Scrum的机制是兼容的，Kanban和Scrum的项目管理方法是一致的。增加WIP和可视化到Scrum，将会改善Sprint的承诺有效性，还可以促进越来越多的变化，采用这种方法的Scrum团队也被叫做Scrumban团队，WIP限制省去了驱动变化时的承诺，降低对英勇行为不正常的依赖，在考虑潜在的改善时提高了整体系统思维。引入Kanban方法的Scrumban将会取代Scrum理念和框架，Scrumban从实践来看有点像Scrum，但在文化层次上来说是Kanban，这个是逐步演变而不是休克疗法和变革。

在考虑Scrum和Kanban哪一个适合你和你的公司，需考虑到文化和成熟度，如果公司还不够成熟，在风险管理、变动管理和决策能力受限， 专业性和抵抗风险上存在不确定性，那么Kanban可能是个更好的选择。如果你有能力让文化和业绩改善几个月或几年，那么Kanban是个正确的选择。 从另一方面来说， 如果公司高度成熟，能够接受风险、评估过程选择、 做出高质量的决定、能从容处理高影响度的变革，那么Scrum是你正确的选择。 如果你正在面对严重问题，没有时间让演变在公司绩效上施展魔法，也许Scrum变革值得你去冒风险。

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

• 回复：学院，进一步了解翻译这篇文章的Agilean学院

• 回复：看板方法，进一步了解看板方法

• 回复：深入浅出，获取深入浅出看板系列历史文章

互联网plus管理新范式

Agilean官方博客平台

微信号

iPlusLeadership

点击

阅读原文

访问英文博客