GitChat·DevOps | 如何结合 Scrum 和 Kanban

来自吴穹、申导、侯伯薇在 GitChat 上精彩分享
原文：如何结合 Scrum 和 Kanban
更多IT技术分享，尽在微信公众号：GitChat 技术杂谈

背景介绍 by 吴穹

这篇文章背后的故事是这样的：某同学写了一篇比较Scrum和Kanban的文章。这是一个老话题了，最近有一些思考，感觉不吐不快。就想写一篇小文，拉上几位老友，一起和大家扯扯这个话题。

比较Scrum和精益Kanban是一个伪命题

Scrum是一个框架，在此框架中人们可以解决复杂的自适应难题，同时也能高效并创造性地交付尽可能高价值的产品。而精益看板是一组促进组织变革的思维（框架）。因此，不理解上述背景，而直接比较两者是可笑的。读者需要意识到，Scrum是一个交付框架，而精益看板是一组变革思维。Scrum相对具体，而精益看板相对抽象。

Scrum的历史作用

不可否认，在敏捷运动的发展过程中，Scrum起到了很大的作用。我把它称为跨越瀑布的拐棍。Scrum的3355框架，简单明了，对刚刚脱离瀑布开发模式的团队来说，比较容易适应。

Scrum实施中的最大陷阱

Scrum实施中有三个常见问题：

Scrum成为小瀑布；
团队职责混乱；
忽视技术实践。

下图就是Scrum实施成小瀑布的实例，例如10天Sprint被规划成2天需求澄清，2天设计，4天开发，2天测试。这样的后果往往是需求延期，开发时间不足，开发移交质量差，测试不充分等等。Scrum成功实施的关键是引入精益流动思想，保证每个Backlog Item独立流动，在10天迭代中基本保证每天都有Backlog Item完成可以移交测试。可惜的是，如此重要的原则在Scrum框架里面竟然没有提及，不能不说这是Scrum框架的一个重大缺陷。

Scrum实施的另一个常见问题是团队职责混乱，这是因为Scrum框架中给出了一个过分理想的角色模型：唯一产品负责人，自组织开发团队，不对交付结果负责的Scrum Master。我见过的大多数团队都没法按照这样的组织结构运作，这种团队在Scrum中叫Scrum-but,特制没有严格按照Scrum要求运作的团队，Scrum不能保证其实施效果。这其实是一个非常好的卖假药逻辑，本药包治百病，只要每天连续服用25个小时，如不能按说明服用，服用无效不退款。

实际上，不同企业有不同特点，我们应该做的是按照精益思想，分析价值流动中的问题，然后对症下药，调整优化组织结构。

Scrum实施的另一个常见问题是忽视技术实践，在Scrum实施过程中未能同步推进。以至于最早XP社区，有所谓“不举”的Scrum的提法。Scrum实施过程中，一定要分析研发团队交付过程中面临的技术挑战，在Scrum实施过程中同步改进。

用精益的思想指导Scrum实施

给大家推荐三本书，在实施Scrum之前，你需要先去理解软件开发的本质，之后你就可以了解Scrum实践背后原理，然后你就能够更成功地实施Scrum了。

感谢

要感谢的人很多，首先要感谢我家人对我一直以往的支持。要感谢David Anderson，Alistair Croll等国际大师的不吝赐教，要感谢路宁和何勉两位引我走上精益之路，要感谢王大爷让我更多关注人的视角，也要感谢所有其他Agilean的小伙伴们多年来的支持。

分析 by 申导

第一性原理

A first principle is a basic, foundational proposition or assumption that cannot be deduced from any other proposition or assumption.

这是来自于量子力学计算的一种说法，意思是从头算，只采用最基本的事实，然后根据事实推论。

早在古希腊哲学家亚里士多德的书中，第一原理是这样表述的：”在每一系统的探索中，存在第一原理，是一个最基本的命题或假设，不能被省略或删除，也不能被违反。”

著名创新企业家马斯克眼中的第一原理是这样的：”我们运用「第一原理思维」而不是「比较思维」去思考问题是非常重要的。我们在生活中总是倾向于比较——别人已经做过了或者正在做这件事情，我们就也去做。这样的结果是只能产生细小的迭代发展。”

总之，「第一原理」的思考方式是用物理学的角度看待世界的方法，也就是说一层层剥开事物的表象，看到里面的本质，然后再从本质一层层往上走。

研发系统是一个复杂系统，需要灵活应对和探索，因此对于产品研发(动词)的第一性是什么？答案是，在反馈循环(loop)进化和学习。

几千年前的《道德经》曰：“反者道之动，弱者道之用。天下万物生于有，有生于无。” 意思是世事无常，万物都在不断的循环之中变化。后有达尔文的进化论，今有互联网精益创业试错手段，无不体现了敏捷思维就是在不确定和复杂环境中，建立低成本地响应变化的能力，让价值能顺畅地流动，保持轻松和优雅，这种灵活性称为敏捷性(agility)。

复杂域下的决策和领导力

敏捷人士应该对Cynefin领导力框架和Stacy Matrix矩阵不陌生，是把事物分为四个领域：

简单
繁杂
复杂
混乱

复杂情况下，因果关系是互为循环关系和互相交叉的，表现出巨大的不确定性和复杂度。美国军方称之为VUCA时代，投入重金研究在不同场景下如何进行决策。在产品研发和软件工业中，一直都出于复杂领域中，传统的过程改进和科学管理理论完全不适用，于是引入复杂科学及衍生的管理3.0来解释如何进行管理。

在90年发展起来的敏捷思维和方法论中，Scrum是发展比较好的一支，其独特的三大角色设定，特别是跨职能团队的设定，非常好地贯彻了“用复杂应对复杂”这个原则，发挥团队的自主性和积极性，而不是用僵化的流程来管控。正如人脑现在已经无法理解基于人工智能的AlphaGo如何打败了全人类的围棋高手一样。

另外，Scrum还提倡对三个方面进行拆分(breakdown)：

时间，把长达几个月的项目周期拆分为短的时间盒(timebox)。这是治疗拖延症，强调节奏感，强迫各方融合协作的灵丹妙药；
内容，把大块的需求分拆为小的用户故事，（在软件中还包括把软件模块进行解耦和抽象）。《道德经》曰”图难为其易，图大为其细”；
团队，把大型组织分拆为跨职能的小团队（亚马逊创始人贝索斯说的”Two pizza team”也是这个意思）。

通过这种拆分，其实就是在将事物从复杂领域拉向简单领域，让人脑能够理解和处理。我称之为“降维打击”，即缩小范围，减少变量，分而治之。把事物从cynefin框架的complex域降到simple域。这是scrum的核心武器，我讲Scrum培训时都会提到这件事情。

Scrum与Kanban之争

两者都借鉴了精益思想，其目标包括低成本、短迭代地快速交付和响应，以最大化客户价值。显著减少任务批量规模，去除瓶颈以加快交付客户价值产出的速度。不再进行规模经济竞争，而是在适应能力、避免库存和小单位工作方面的竞争。可视化、timebox都应该为这个目标而服务。

其实Scrum与Kanban是POV（视角）不同，非要比较的话，Scrum的视角是从responsiveness，更多是破解复杂性，而kanban视角是从flow，更多是整流顺畅性。所以这两种方法的视角和想要达到的状态不同，但互有支持和重叠，本质最终都指向第一性原理。

改进是精益的核心之一，至于怎么改进，精益思想给了一些手段，比如”go see”与可视化管理等，然而相对于Scrum方法，精益与看板对循环（loop）这件事提的都不多。至于价值流建模，Kanban对研发过程是一种落地手段，但是还有很多是Kanban难以进行建模的，比如持续交付流水线、TDD和重构过程、模块化设计等。

Kanban的理论基础很多来自于Don的那本书，其出发点是系统的flow，通过可视化来推动这个变化。Kanban更多是一种可视化的协作模型。它对现有过程进行建模，看板试图通过可视化手段以及WIP限制（因），达到“流动”和“拉动”这种状态（果）。但并未对具体实践给出太多的指导和设定，比如没有固定时间盒，没有要求团队要重组，也没有要求需求拆分。当然你也采可以用迭代，称之为Kanban Cadence。如果是不严格的时间盒，更像FDD/XP；如果应用固定时间盒，那么也就更偏向Scrum的玩法。（kanban创始人其实也试图在融入更多循环的概念）

Kanban更倾向于关注长周期的状态，比如累计流图的运用，而经典scrum则主要关注于一个迭代的状态，比如燃尽图的运用，在这两个方面倒是存在互补。

Scrum更多是一种产品与组织的学习和改进模型，绝不是项目管理方法。也借鉴了精益思想、PDCA戴明环、时间盒/GTD等。

时间盒是Scrum除了三大角色设定（包括跨职能团队）、拆分之外的另一大特点，强调节奏感，这是软件交付的核心，等大家节奏感有了，自然流式交付。时间盒也有助于人们的共识对齐。任何产品和组织协作，最难的一步就是alignment，这是所有方法都梦寐以求的。借用王大爷的话：”Scrum给了我们不需要理解就能得到一些“东西”的框架，通过给你一次又一次失败的机会来调整自己，alignment在动荡之中自然会形成”。短的时间盒也是更调整和响应变化带来更大的余地。

Scrum创始人Ken说Scrum是一种暴露问题的手段，而Kanban也说自己是可视化管理，这不一样吗？

实战中的选择

我自己在辅导团队时，会以Scrum为核心框架，建立基本的迭代运作方式，形成频密的沟通和反馈机制是第一步，附以Kanban（更多是采用了其可视化的功效，其实经典Scrum中的任务板就是一个简化的可视化板）作为协作模型来暴露问题，以及辅导各种XP工程实践来提高持续集成、整洁代码、自动化等能力。更重要的是，我本人认为除了这些硬知识，软技能更能够引发变革，所以通过引导来形成共识，利用教练技术来培养人是必不可少的。

现实中，肯定不是一个团队那么简单，往往会涉及Scaling（大规模扩展）的话题，这个时候，kanban一般会采用多级看板可视化，而Scrum则会涉及如何分割和定义Product Ownership的思考。

Scrum强调各种Ownership的明晰，这戳到了很多组织的痛处，因此的确很难应用，就像理想的共产主义，可能大家永远都是在前进路上而无法达不到终点，所以Scrum-But也是一个常态，小瀑布也比大瀑布进步了不是？多数的kanban应用也就是停留在可视化阶段，角色融合好几年也发生不了，限制WIP上限更只是一个美好的愿望。

看看你的生活、社会，那有完美的事情呢，打折扣是一定的，所以不用焦虑，而是要接纳现实的不完美，并且意识到还有很多需要改善的地方，这才是敏捷和精益思维。如果哪个公司简单套一下，就宣称自己已经敏捷或精益了，那是胡扯。

渐进变革？

看板是渐近变革的工具？看板只是一块板子。你看它，它就是看板，你不看它，它什么都不是。Scrum中每个迭代后做回顾，难道不是渐近变革？PMP要求每个项目之后都做尸检，难道不是渐近变革？百日维新与南北战争中，都有人掉脑袋，区别只是脑袋颜色和数量的问题。Scrum与看板（以及各种转型）都是先革命再渐近。Scrum要重新分配职责角色，看板呢，Duang~，你立起来一块大板子，逼着大家每天早上要对着板子（不是，要对着同事）讲工作，搞得事事都透明兮兮的，难道不是一种革命？管理3.0说了，看板是一种新的协作模型，引入看板就是一种革命。

感谢

我在成为ScrumAlliance的CTC认证敏捷教练这一路，非常感谢李国彪(Scrum/agile)、吴穹(Kanban/lean)多年的支持和鼓励，教会了我从不同视角看问题和学习，同时也感谢所有社区伙伴们的相互扶持，还有从我的各位客户身上学到了很多很多。

参考阅读

认知科学有一个核心信条：只在单一的层级上进行研究，不可能彻底地理解精神和脑。认知科学是一个跨学科领域，包含了来自各领域的贡献，包括心理学、神经科学、语言学、精神哲学、计算机科学、人类学、社会学和生物学。
“Waterfall, Lean/Kanban, and Scrum”, Ken Schwaber, 2010
《管理3.0》
《复杂理论》
《系统思考》
《从管理1.0到管理3.0的大跃进。管，或者不管，问题都在那里，不增不减。》

经历 by 侯伯薇

首先，感谢博士的邀请，让我也一起来和大家聊聊Scrum和Kanban之间的区别与联系。我会从自身经历的角度来说说。

我接触Scrum早于接触Kanban，在此之前，我对Agile的理解更多来自于极限编程。大家也知道，因为是极限，所以对于个人的要求比较高，不仅是技术能力，而且也包括了个人作为程序开发者的基本素质。所以，最早的时候，我会认为想要实施敏捷，就需要团队中的每个个体都有足够高的能力和意识，那样才能够保证Agile的顺利实施，而在普通的技术团队里面，并没有那么简单。

然而，当时就有朋友和我说，如果实施的是Scrum，可以在某种层度上降低对个体的要求，也可以让更多组织实施Agile，这样就降低了敏捷转型的门槛。

正是因为这样，我才潜下心认真学习了Scrum，并获得了一系列的Scrum认证，认证的过程本身就是不断学习和提升的过程。经过了解，我发现，Scrum确实通过一个框架达到了目的。其中的三三五五既照顾到了“心”的层面（价值观），也照顾到了脑的层面（知识），至于实际的手的层面（实践），一方面已经有了基本流程的定义，另一方面我们可以在实际情况下根据具体的问题填充不同的技术实践进来。

然而，在经过了一段时间之后，我发现其实想要完整地——或者说原封不动地——采用Scrum，还存在比较大的困难。因为Scrum定义的三个角色在现有的团队中至少有一个是没有的；而现有团队中存在的多个角色到了Scrum中是会被干掉的。这就让PM、PL等管理职位很尴尬，一时间风声鹤唳草木皆兵，生怕公司实施了敏捷转型之后，一天早上起来就会没了饭碗。所以，大多数采用Scrum的组织都是对其进行了必要的调整，更多的是采用了其中的迭代开发的流程，以及保证节奏感和仪式感的各个会议，从而可以让团队在现有的组织结构下不断持续改进。

敏捷宣言会强调，在敏捷团队中的沟通非常重要，而Scrum中定义了大家定期沟通的会议或者说仪式，却没有定义具体的工具。因此，不少团队都使用了任务板来促进团队中的沟通。最早看到的任务板都是“Todo - Doing - Done”的简单形式。

接下来我接触了Kanban方法，其中的第一条实践“流程可视化”给出了非常大的启发。原来我们可以使用物理或者电子的白板来展示所有的进度，并且在上面可以管理所有任务的流动，在其中发现拥堵、等待、分享等严重影响进度的因素，从而采取相应的措施来对症下药，保证团队效率的提升。

深入学习Kanban方法之后，越来越发现其中的奥妙之处，比方说：如何限制在制品，包括每个人身上的任务数量和每个状态下的任务数量；如何管理流动；如何策略可视化等等。很多内容都是为了保证开发团队任务的顺畅进行，从而在最短的时间内把最有价值的功能交付给用户，获得反馈以持续改进。

在应用Kanban方法的经历中，我会发现，这种方法会非常容易被团队所采用，因为它并不会在开始的时候对企业或者组织的结构造成任何影响，而且也不会直接对团队的运行方式做太大的改变，只是创建一块看板，就可以实现最简单的“流程可视化”的效果，而从中很快就可以体现出团队流程中可能存在的问题了。不过，我也发现，其余几条实践的实行却是任重而道远，比方说：限制每个状态下的在制品数量。这条实践就是很久之后可能都不会在团队中执行，因为大家身上的任务多这种状况已经习惯了，或者说没有真的痛，不痛就不太容易改变。

这两种方法在各自的发展过程中会不断有碰撞，相互学习，当然也会有争论和辩解。而在实际的工作中，我更喜欢融合两种方法的优势或者说擅长的方面，用特定的方法来解决特定的问题。

比方说，我们可能会先用“流程可视化”的看板来让大家发现流程中的问题，让大家关注任务的流动状态，找到其中拥堵和等待的问题和导致问题的风险；同时会对需求进行拆分，缩短开发周期（一般到两周），采用Scrum的方式来开各种各样的会议，保证团队的节奏感，并且快速获得业务用户的反馈；而站会一般会请大家在看板前面开，这样的话可以迅速、具体地了解到任务状态的现状以及变化，而且可以达到“同一地点”的目的；在回顾会议里面，我们可能会请团队也根据情况对看板的使用和效果做持续的调整和改进；

这样就可以把Scrum和Kanban方法结合在一起，发挥出更大的效用。相信这也是很多企业里面所采用的方式。“尺有所短，寸有所长”，我们要做的就是取长补短，达到一加一大于二的效果。

最后借用Google当年对于敏捷的一句话：“当我们谈论做敏捷的时候，本身就已经不敏捷了。”我们可以试着把更多的精力放在具体问题的分析上，在出现问题的时候，不管使用的是Scrum还是看板方法，只要能够解决问题，就都是好方法。

感谢

首先一定要感谢家人对我的支持，你们也是我最大的动力。我要感谢在敏捷路上引领、陪伴我一起前行的各位朋友：滕振宇、吴穹、李国彪、王宇、申健、姜信宝、孟繁强、管婷婷、欧兰辉、尹学罡等等，名单太长，在此无法一一列举，有了你们我在这条路上就不会孤单。

总结 by 王宇

渊源

我先简单说一下我跟Scrum和Kanban的缘分。

对于Scrum来说，我要感恩Bill（李国彪）是他带我出来做咨询和培训的。从12年年中我就开始了有强度的Scrum培训过程。如果说师从的话，其实是Vernon Stinebaker（史文林）给我发的CSM证书。之后我又参加了Bill（李国彪）的CSM课程，滕振宇的CSM课程，黄方的Scrum课程（那个时候他没拿到CST）。我在12到13年度应该交付了很多Scrum的培训，半天的，一天的，两天的，甚至是3天的数量已经记不清楚了。咱们就不说其他的Scrum相关的培训和认证了哈。反正现在应该都过期了（我今年决定放弃所有收费的认证）。在经历Scrum的过程，给我很大的冲击。并不是理论本身，而是之前ThoughtWorks对认证和Scrum理论嗤之以鼻的态度。我在这个过程中加深了对Scrum本身的理解，并尝试应用于我所指导的团队。

对于Kanban来说，我要感恩路宁，是他给我传递了很多Kanban本身的理论和思维（在ThoughtWorks的时候，我们还一起参观过丰田的配件工厂来了解精益的过程）。他也是我从13年开始的咨询伙伴，那时的我们主要服务于平安科技。所以在这里也感恩一下“平安科技”，谢谢。Kanban大学的证书也是他给我发的。我个人认为他的理论和David J Anderson 的理论细节还是有区别的。这里，如果有什么讲错弄错的话，请大家骂他。

关键点

Scrum的关键点在于利用若干角色、工件、仪式使得团队形成纪律性，并反作用于过程的优化。

Kanban的关键点在于利用团队自己对过程通过可视化形成协作平台，通过控制在制品数量形成流动。

关键区别

第一：就如同《思维发条》的文章《Scrum与Kanban，激进与保守》说的一样，我是赞同路宁的观点的。Scrum更为革命，Kanban更为保守。Scrum更强调纪律性，而Kanban更强调对现实的承认并渐进式启动变革的过程。这点其实看似可以互相融合的方法，其实在根本上有质的区别。

第二：Scrum就是一个框架，而Kanban从一定的角度来说是一种方法或是系统。这一点可以从培训的复杂度就可以看出一些眉目。Scrum给我10分钟我就能给你讲得了解它，知道怎么做就不是Scrum。对于Kanban，10分钟估计还在开场热身呢。而且对于Kanban方法本身的讲师数量也能说明一些问题。

第三：玩坏了的结果不同。

Kanban容易玩成管理者微观控制的工具（管理者来设计看板，并推行管理理念），或是不疼不痒的协作平台。

Scrum容易玩成大家对交付非常疲惫（成了压迫的手段），或仅仅多了个ScrumMaster角色。

管理的惯性

任何事物都有惯性，管理也不例外。对于基层出身的管理者当然希望能够实现共产主义。而对于已经位高权重的人来说，如何在这个世纪延续上世纪经典的过程管理方法（新瓶装旧酒）他们还抱有一丝希望。顺理成章，那些领导自然选用自己认为靠谱的方式和方法。但对于Scrum来说，真正有效果的是从开始就拥有Scrum文化或价值观的公司。而Kanban的选用，也在工程能力很强的地方效率异常高（比如在ThoughtWorks内部）。

可悲的是大家看到的大多都是面上的东西，流程、方法、框架。其实不管是Scrum或Kanban我个人认为对于敏捷转型来说……

就是一个假命题

我可能会用到看板，也可能会用到Scrum。并利用教练的心法来使团队更高的提高纪律性，提高协作能力，提高彼此的认同感和荣誉感。我承认导入敏捷的过程要具体情况具体分析，要灵活的使用我们的理论和技巧。但注意

武功套路的存在是为了打退敌人

你不能爬在地上打王八拳，也不能是招式套路展开的品势展演。如果你没有武功套路，或是说我自己研究出来的。这不是不好，只是我担心你的攻击力会受到野路子的局限（当然你可能是大师）。另一方面我追求搏击的“美感”，如果一点美感都没有我是忍受不了的（请大家理解天秤座）。

说了这么多，我就说两个傻傻的趋势，供大家思考（我也要反思自己）：

正因为Scrum框架的简单以及来钱比较方便，一些所谓的“咨询顾问”抱着革命的心态斗志昂扬，不知廉耻的实施敏捷导入的过程。他们就像早期的革命者，或传教士。一方面喊着我们需要不要脸，另一方面自己还真的不要脸地销售自己。
正因为Kanban方法的数据与分析。理科生感觉爽啊，可找到理论依据了。难道你可以否定这些理论吗？他们脑子里的勾兑关系如此的精致且不容他人的质疑。一方面承认看板是团队改进自己的手段，另一方面不停通过管理层推行看板系统的优化和进化。

唉……一声叹息

舶来品，依旧是舶来品。转型导入的艰难依旧是艰难异常。我惊叹团队中有很多人放弃了独立思考，放弃了勇于承担。我一方面心痛，另一方面我完全相信舶来品对人员主动性的假设在中国是错误的。

但我不曾退却，因为这些人与我共同面对这伟大的挑战。平安的国柱、伟丹；顺丰的小林、杰伟、怡雯；招行的余强；东软的繁强、耀东；吴博士；宇安；申健……还有正在阅读这篇文章的你……

实录：《三人行： Scrum 和 Kanban 的结合实战解析》