GitChat · DevOps | 如何结合 Scrum 和 Kanban

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

背景介绍 by 吴穹

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

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

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

Scrum的历史做用

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

Scrum实施中的最大陷阱

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

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

下图就是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矩阵不陌生，是把事物分为四个领域：

1. 简单
2. 繁杂
3. 复杂
4. 混乱

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

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

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

1. 时间，把长达几个月的项目周期拆分为短的时间盒(timebox)。这是治疗拖延症，强调节奏感，强迫各方融合协做的灵丹妙药；
2. 内容，把大块的需求分拆为小的用户故事，（在软件中还包括把软件模块进行解耦和抽象）。《道德经》曰"图难为其易，图大为其细"；
3. 团队，把大型组织分拆为跨职能的小团队（亚马逊创始人贝索斯说的"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 的结合实战解析》

---