相较于Scrum, 我更推崇Kanban，帮助团队建立价值交付流，识别瓶颈

最近在学习实践精益Kanban方法，结合自己团队实践Srum的经历，整理些资料二者的差异。相较于Scrum, 我更推崇精益Kaban。

Agile是一套理论和原则，就像天边的北极星。Devops是一种软件开发和运维团队间自动化和集成过程的方法。当实现Agile和Devops方法时，Kanban和Scrum提供了管理这些复杂工作的不同的实践。
简单来说，Kanban和Scrum是进行敏捷开发或项目管理工作的两个不同的策略或者方法论。

• Kanban方法意味着持续性与更好的流畅性。
• Scrum则是基于更短，更加结构化的工作冲刺。

Scrum：一种结构化的敏捷方式

Scrum源自于橄榄球的一种争球方式。现在作为一种迭代式增量软件开发过程，通常应用于敏捷软件开发。Scrum将工作分解成较小的功能单元，并在周期性固定的时间段内持续的交付。

• 把组织细分成小組、跨功能、自我组织团队。
• 把工作细分成细小、实在的交付成果，交排人员负责需求清单以及跟据重要性排优先级别，由团队估算每个项目相对工量。
• 把整个开发时间分成固定时长的短迭代（通常于一至四星期），在每个迭代后演示新增可发布功能。
• 优化发布以及跟客户一起更新优先级别，基于每个迭代后发布的观察。
• 优化过程，在每个迭代之后进行回顾

在我们考虑考虑采用SCRUM之前，先问自己一个问题：整个开发团队是否是专职团队，并且负责该项目。
SCRUM团队会承诺每个Sprint结束都会交付产品或者价值。如果你的团队成员有肯能去做别的其他项目，那么SCRUM团队无法承诺每个Sprint的交付。另外，在选择SCRUM时，还需要考虑以下方面：

• 节奏

SCRUM强调的是快速交付，在每个Sprint结束时交付用户可用的可交付物，每个Sprint一般2周最多4周，有着清晰的开始和结束时间。该框架的背后思想是利用短的时间段强迫把复杂任务分解为小的user story.

• 关键指标

衡量一个SCRUM团队表现的关键指标是velocity（效率），即在一个Sprint中交付的story points的数量。该指标用以指导后续Sprint中可以承诺完成的story points。想象一下，如果一个团队每个Sprint中平均完成35个storypoints，那么后续的sprint中我们不会完成45个story points.

• 应对变化

一般情况下，SCRUM团队尽量不要在Sprint过程中进行范围变更。如果团队通过客户反馈发现他们正在开发的功能没有他们认为的那么有价值，这种情况下需要变更该Sprint的开发范围，以便优先交付对客户最优价值的功能或价值。

Kanban：一种持续改善，变化灵活的过程

Kanban方法最初起源于丰田的JIT（Just In Time），之后作为一种高效管理软件开发流程的技术和思想应用于互联网行业。Kanban方法以价值流动为核心，不断发现团队中的瓶颈工序，进行改进，使价值流动更加顺畅和快速。

工作流程形象化

• 把工作细分成任务，写在卡纸上，贴在墙上
• 把栏命名好，來显示任务在工作流程中的狀況

限制“在制品”（work in progress，简称 WIP）

• 明确设定限制在每个状态下同一时间能有多少工作任务

度量生产周期（即完成一个任务的平均时间），优化开发过程，缩短开发周期和使它更易于预测。

发布方式

• 看板过程中，软件更新只要完成就可以随时发布，没有一个周期或者提前决定的日期。理论上，看板并不需要预先确定一个时间点来交付一个任务或者软件更新。如果一个特性完成，无论早晚，都无需像SCRUM过程那样等到Sprint结束再发布。

角色

• 整个团队对看板负责。有些团队可能需要一个敏捷教练的角色来帮助看板过程的顺利进行，但是不像SCRUM一样，有一个看板master, 来保证每件事情都平稳运行。看板过程中，整个团队相互协作，来负责交付看板上的每个任务。

关键指标

• 循环周期（Cycle Time）是看板过程的一种重要指标。它指的是一个工作项从开发到结束所花费的平均时间。工作项循环周期的改善意味着团队的成功。

看板团队经常用来分析项目进展状况的工作是累计流图（CFD）。它可以用来表示每个状态下的工作项的数量，从而帮助识别出限制工作流的瓶颈。

应对变化

• 看板的工作流可以任何时候进行变更。任何时候都可以添加新的工作项，也可以暂停或删除正在进行中的项目，这一切取决有优先级。而且，如果团队交付能力发生变化，可以重新设定WIP（Work In Progress）限制，工作项也可以被随之调整。

比较差别，探索适合自己的方法

在团队的项目管理实践中，我们往往将二者的优势结合起来综合的使用，以便帮助团队更好的完成目标，而不是为了使用方法而使用方法。

相同点：

• 两者都符合精益和敏捷思考
• 两者使用"拉动式"安排日程
• 两者限制开发中工作数目
• 两者是透过透明度来驱动过程开进
• 两者集中提早及衡常的付运软件
• 两者基于自我组织团队
• 两者要求把工作细分

• 在两个情况下发布计划都是基于经验数据（速度／开发周期）持续优化

  不同点：

  系统范围

  在讨论Scrum和看板之前，有必要澄清系统范围。在Scrum里，系统范围由产品的定义和完成的定义决定；而在看板里，看板系统的边界定义了系统范围。

• Scrum的运作是围绕产品的，每个迭代开始从产品待办列表挑选进入下一个迭代的故事，迭代结束将故事做到完成。故事的范围是由产品的定义决定的，故事在产品的范围内是端到端的。完成的定义体现的是故事可交付的程度，也就定义了价值流的终点。

• 看板(Kanban)系统的边界定义了价值流的范围，由此决定故事的范围。故事会流过整个看板系统，其终点状态完成的定义也就相当于Scrum中完成的定义。

需要指出的是Scrum的系统范围定义通常是基于组织结构的，它涉及到产品的定义和团队的组建，产品待办列表要与团队相对应，因此系统边界相对严格；而看板的系统范围定义只是基于在统一的看板系统做可视化和管理流动，因此系统边界相对宽松。这也跟两者不同的变革导入思路有关。

两者都有一个思想去尽可能地扩展系统范围，以利于管理整体的价值流动和实现。只是体现出来的对Scrum而言是产品定义的扩展和完成定义的扩展，而对看板而言是看板系统边界的扩展。

在我看来，无论Scrum还是看板，都希望帮助到价值交付和持续改进，但是它们采取了不同的方式。最显著的差别在于Scrum采用迭代而看板采用流。

Introduction to Jira Software Boards | Atlassian

价值交付

• Scrum和看板都致力于最大化价值交付，无论是采用迭代还是流，关键都在于减少在制品。在制品由进行中故事的个数和故事的大小决定。
• 当采用迭代时，限制故事的个数是间接的，迭代长度间接限制了故事的个数。当采用流时，限制故事的个数却是直接的。

故事的大小是另一个影响在制品多少的因素。迭代会推动故事的拆分，因为在迭代结束时要求能够将故事完成。然而，把故事拆得过小会使拆分变得不自然（也就是为了拆而拆），反而降低了那些拆分出来故事的价值。故事不能被无限地拆分，一个故事在有价值的前提下能拆多小通常存在自然的限制。采用迭代有可能会人为地破环故事的自然大小和完整性，而采用流则会更遵照故事自然的颗粒度。

持续改进

Scrum和看板都致力于持续改进，无论是采用迭代还是流，关键都在于创造合适的挑战来驱动改进。当改进目标达成后，改进就会陷入停滞，而持续改进却需要永不停歇。Scrum和看板都是通过提升目标来再次创造合适的挑战以使改进继续，但是提升目标的方式却不同。

Scrum里最重要的改进目标是在迭代结束做到完成。这里有两个变量，迭代长度和完成的定义。当通过改进做到迭代结束完成后，我们会看完成的定义是否可以扩展。扩展后的完成定义产生了新的挑战，从而提供了继续改进的动力。当完成的定义已经达到可以交付时，我们会看是否可以缩短迭代长度，这又能驱动进一步的改进。

看板的改进目标一方面来自于直接的在制品减少。通过在制品限制的降低，系统中更多问题会被暴露出来，从而驱动改进。另一个重要的因素是围绕前置时间的改进，前置时间的缩短对价值交付和提升灵活性都有帮助，因此是很好的改进目标。

变革导入

最后想说说的是关于Scrum和看板的变革思路, 根本在于改善（小变化）和改革（大变化）的平衡。当引入过大变化，由此产生的挑战过大，结果适得其反。当过于保守引入过小变化，又使变化过于缓慢，甚至逐步丧失了改革的能力。

Scrum的有效运作需要组织设计，它的第一步在我看来是改革，然后由每个迭代回顾驱动持续改进。看板尊重现有的组织结构，从现状出发，因此它的第一步更接近改善，然后也是持续改进。对两者而言持续改进理论上引发改善或者改革都有可能，实际中发生更多的是改善。

当变革涉及系统范围的扩展时，Scrum要求组织结构的改变，而看板要求的最小改变只是放在统一的看板上进行可视化管理，因此更能反映“可能的艺术”。而当现有的组织结构制约了协作模式并最终影响到价值流动时，组织结构仍然需要被突破。

先导入Scrum还是 Kanban?

从属性上来看:

Scrum 容易探讨未知，处理复杂项目，拿来开发新东西威力无比。
Kanban 是教我们如何自我检讨，可以迅速消除浪费，而得到好的效能。

如果你是开发团队，当然是先从Kanban 开始。
先检讨团队的基本动作，整顿好了再来开始作新的东西，从事开发的动作，自然减少浪费。这是精益Lean 的好处。
(有太多开发团队，只晓得一意往前冲刺，忽略了自己在开发上的浪费，这会造成很难走得久远，尤其是Startup的团队尤其如是。)

如果你是运维团队，当然是先从Kanban 开始。
视觉化是最大的亮点，团队可以看见工作上的维护流程是一件相当有价值的事，针对个人亦是如此，人们常常因为养成习惯了，就一直持续做同样的事情，很少会有机会回过头来检讨，哪里做得浪费了应该改进。
看板方法的第一步: 视觉化。正是团队可以拿来持续改进的基础。这一点对维护工做更显得珍贵。

如果你是测试团队，当然是先从Kanban 开始。
看的见以后才可以减少猜测的比例。测试团队在拟定测试计划之前，一定要对待测的产品或程序有足够的了解，才可能写出实用的测试案例，不至于浪费大量的测试资源，或做了过多的重复性测试。

你可能觉得奇怪，为什么都是Kanban Method 先行呢?
其实原因很简单，因为它"单纯“，不是简单喔! 它没有想像上的简单，因为它可以演进得很有深度，但是它的目的很单纯，就是追求效能。不像Scrum 的目的，是要来应付复杂的项目开发作业，基本上的方向就完全不一样的

相较于Scrum, 我更推崇Kanban, 因为限制少，推动Kanban的过程本身其实是定义团队流程规则的过程，不需要特定的角色，容易理解和接受。

将看板方法融入Scrum的开发过程才是上策
看板方法是一种流程控制，他不是一种具有完备基础的方法学，虽然他的潜在发展相当可观，但目前他仍只是一种提供我们产出高效能的流程控制法而已。
他缺少需求描述、没有完备的会议规划、少了团队职责分配，少了很多很多软件开发上该有的措施，这一点让他看起来十分空泛，但就是这个特性也让他十分适合融入其它开法方法中，尤其是Scrum。

看板方法之父 David J. Anderson 是在Microsoft 公司推行敏捷开发法 Scrum 的时候发明看板方法的。他原本的目的只是要求能够在最少阻力之下顺利在组职中推行敏捷式的开发方法而已。却由于他熟悉限制理论的运作而开创了看板方法Kanban Method。做出了对敏捷开发的精益Lean 一支的重大贡献。
也就是这样的典故，让看板方法Kanban Method可以十分容易的融入到Scrum的开发过程。

著名的《 Essential Scrum 》 的作者Kenneth S. Rubin(它是2013年Amazon 敏捷理论最畅销书)，书中就大量的采用 WIP(Work-In-Process)的观念，实际的运用在工作看板上面。让Scrum在开发流程上减少了许多的浪费现象。

看板方法先行
因为它可以减少组织在推行敏捷上的阻力，它能让工程师以最好的节奏持续进行开发工作。又能将精益观念带入团队运作。
融入Scrum的开发过程
因为看板方法的流程控制方式是用来提升Scrum运行时的效能，让 Scrum 能真正用来克服复杂的软件程序开发过程。

Scrum 的目的在解决复杂的软件开发作业
许多人误把Scrum 当成加速软件开发的银子弹。这是错的!

它的目的不在加速开发(加速开发工作是开发工具的广告词)，它的目的是在解决复杂的软件开发作业，让它提高成功率。在协助团队能够提供给客户真正要的产品，且让他在市场上具有实际的竞争力。这一点也正好是看板方法所缺少的。

开发团队千万别因为实施了看板方法而误以为需要把 Scrum 抛弃了，这是一种错误的想法，让他们相辅相成才能有更大的效益。

先导入 Scrum还是 Kanban? 二者之间并没有冲突存在，都是通往敏捷开发的路径，就看你现在最需要的是那一样，那一样就先来吧

• 已经在使用 Scrum 作开发工作的人士，学习 Kanban Method 可以让他们进入精益的领域，有所依据的持续追求更好的效能。
• 先学会Kanban 方法 再跨足 Scrum 的人呢? 则可以看到敏捷开发在处理复杂问题上的具体方法，真正懂得去追求效能之外的正确性与方向。

实践分享 - 结合业务性质，持续改进，适应外部变化

基于团队业务情况（服务交付类型），结合自己对两者的理解，以及实践中遇到的问题，画了如下图：

我们遇到的问题：

• 需求不固定，经常面临随时插入高优先级需求
• 客户反馈需要快速解决，特别是阻塞性的
• 资源紧张，负责平台模块多，业务差异较大

探索改进过程

1. 混乱期，团队新组建，需求没有得到有效跟踪
2. 建设期，逐步开始通过Jira跟踪需求，尝试敏捷Scrum, 各种站会，评审会，评估故事点等实践，此时外部需求可控，从2周迭代发布（小瀑布）逐步过渡到随时可发布状态 （伴随着建立了分支模型，分支模型也随之调整了两版，建立了和环境对应的持续交付流水线）
3. 问题期，业务压力大，各种Scrum会议感觉作用不大，团队成员不需要参与所有需求评审，PO需要多个业务板块切换准备需求
4. 调整期，推动研发人员专职负责某个模块，负责整体迭代把控，拆分成迭代火车，各负其责，把sprin当作一个个专题需求火车
5. 改进期，虽然划分了责任边界，但是外部需求/事务增加，积压严重（状态更新不及时），无法从宏观了解整体情况（整个看板都是满的），所以尝试使用Kanban方法，梳理业务流程，在原有流程不变情况下，明确定义团队协作规则，制定不同纬度/角色关注的看板，同时建立个人/团队仪表盘，关注动态变化
   1. 需求看板 - 研发/产品经理关注
   2. Scrum迭代看板 （专注于内部开发迭代）- 研发同学关注
   3. 客户问题看板 （划分优先级泳道）
   4. 缺陷看板 - 测试同学关注
   5. 运维/运营看板 - 包括技术债务，改进，支持事项等
   6. 整体全局看板

经过上述过程，团队逐步向 “自组织“团队演化，”分工有序“，简化花里胡哨的Scrum仪式, sprint变成了业务发布火车（划分迭代范围之用），把整个团队跑迭代变成了2-3人的“按照业务领域划分的迭代”，放弃了故事点评估（实践证明似乎不太适合我们），相比于scrum偏重于迭代间的改进，我们更看重需求交付速度，不希望有挤压，降低外部插入的需求或事项带来的干扰，让成员更专注。

总结

• Kanban主要用来可视化你的工作，限制在制品，使其最大效率的流动。Kanban团队聚焦在减少花在项目（或者用户故事）上的从开始到结束的时间。他们通过Kanban board 来实现它并持续改进他们的工作流。

• Scrum通过设置称为冲刺（Sprint）的间隔去承诺需要承载的软件开发。它的目标是通过搜集和集成客户反馈去创造一个产品的快速学习环。Scrum团队采取特定的角色，创造特定的工件，执行特定的仪式来保持事情的推进。

区别一：实施过程中关注核心的区别

Scrum实施的核心可以概括为“化繁为简”，从几个维度解释下：

1. 团队角色的定义，将团队人员定义为三个角色，Scrum Master（主要负责消除障碍，带领团队运作）、Product Owner（主要负责描绘产品远景，定义优先级）、Scrum Team（主要负责实现产品）
2. 工作任务的拆分，将产品需求拆分成小的用户故事，并评估优先级
3. 时间的拆分，将项目周期拆分成固定时长的迭代周期，每个迭代交付一部分可验收的功能，通常迭代长度为1到4周

Kanban方法在实施的过程中更多关注的是可视化的价值流动，从几个维度解释下：

1. 拉动式生产，下游工作完成后，主动拉动上游的任务移动
2. 限制WIP（work in progress），明确设定限制每个状态下，同一时间内有多少工作量，减少同一状态同一时间内，任务和价值的堆积
3. 可视化的价值流动通常是端到端的流动，直观的反映用户的价值（通常是可交付的用户需求），并且反映出在价值流动过程中的瓶颈和问题，不断为团队改善提供依据

   区别二：限制WIP数量的方式不同

   Scrum与Kanban方法都会限制在制品数量，不过限制方式有所不同，

• Kanban方法限制的更加直接，同一状态同一时间内的工作任务有最大限制；

• Scrum是间接性的通过迭代（sprint）来限制。限制WIP的核心目的是加速交付用户需求的价值流动。

  区别三：对任务变更管理的不同

  在Kanban方法的中，下游任务完成后（有显式化的拖动规则），即可拉动上游任务下移，同时，只要生产力允许，即可新增需求。
  
  在Scrum方法下，当每个迭代的sprint Backlog确认后，当前迭代是不允许新增需求的，新增加的需求可以体现在下个迭代的sprint backlog中。
  

  区别四：改进依据的不同

• Scrum是以生产率作为计划和改进的依据，以迭代（sprint）数据作为依据，分析迭代的相关数据（包括生产率、完成率等）；

• Kanban方法是使用生产周期作为计划和过程改进的依据。

Scrum和Kanban方法作为即敏捷又精益的典型代表，除了上述不同外，还存在很多相同点：

1. 二者都和敏捷与精益相对应。敏捷中的持续改进思想在Scrum和Kanban都有所体现，而且是很核心的一个内容；精益中的拉动式生产在Scrum和Kanban中也都分别覆盖，Kanban方法体现的更加直接，下游直接拉动上游的工作任务。
2. 二者都关注尽早的交付价值，尽可能频繁的发布可使用的软件。Scrum将整个项目周期拆分成多个迭代，每个迭代发布可验收的软件；Kanban方法在每个功能开发测试完成后就可以进行部署和发布。
3. 团队状态都直观的反应在Scrum board和Kanban Board上，方便找到问题和瓶颈，并进行改善。

   案例

   比较了Scrum与Kanban方法之后，如何结合二者在团队中进行项目管理实践呢？这里提供一个案例，从迭代、版本、变更、改进四个方面来介绍

迭代：在Kanban方法中，并未规定明确的迭代，而在Scrum中是规定了固定的迭代周期。在我们的团队中，迭代周期从一月一迭代，逐步变为一月两迭代，到现在的两个自然周一个迭代，完全固化了迭代周期的概念。

将复杂开发周期很长的开发任务，分解成多个迭代周期，每个迭代周期交付一些可验收的软件或者功能。有利于减少风险，并更好的适应变化，及时的根据反馈调整工作目标。

版本：在迭代中，我们以排入版本计划的功能点（story）作为工作重点，排入版本的story为交互已经完成的功能点（story），这些功能点可以直接进入开发和测试环节。这些story便是我们当前迭代可以交付的功能或者软件。与此同时，产品、交互和视觉同学会继续拉取需求池中的功能点，开始进行设计，准备下个迭代版本中的内容。使整个价值流动更加顺畅。

变更：对待变更，我们同样有自己的一套流程规范，既没有像Kanban方法一样，只要生产力允许，便可以新增需求；也没有像Scrum一样，版本内容确定，当前迭代基本不允许变更。
在实际过程中，当存在紧急需求，由产品经理发起，和各个角色进行评估风险和对现有版本的影响，并采取相应措施降低由于需求变更对整个系统产生的影响，最后由项目经理发出变更通知的邮件。

改进：我们改进的依据之一是团队数据，由于我们所有的任务都是通过JIRA进行管理，可以方便的拿个团队各种数据，包括：总工作量、总完成工作量、完成率、有效工作量、有效工作率、bug数、bug率等，对这些数据进行分析，发现团队的问题，帮助团队进行改进。