Scrum
Scrum源自于橄榄球的一种争球方式。现在作为一种迭代式增量软件开发过程，通常应用于敏捷软件开发。Scrum将工作分解成较小的功能单元，并在周期性固定的时间段内持续的交付。
- 把组织细分成小組、跨功能、自我组织团队。
- 把工作细分成细小、实在的交付成果，交排人员负责需求清单以及跟据重要性排优先级别，由团队估算每个项目相对工量。
- 把整个开发时间分成固定时长的短迭代（通常于一至四星期），在每个迭代后演示新增可发布功能。
- 优化发布以及跟客户一起更新优先级别，基于每个迭代后发布的观察。
- 优化过程，在每个迭代之后进行回顾
Kanban
Kanban方法最初起源于丰田的JIT（Just In Time），之后作为一种高效管理软件开发流程的技术和思想应用于互联网行业。Kanban方法以价值流动为核心，不断发现团队中的瓶颈工序，进行改进，使价值流动更加顺畅和快速。
工作流程形象化
- 把工作细分成任务，写在卡纸上，贴在墙上
- 把栏命名好，來显示任务在工作流程中的狀況
限制“在制品”（work in progress，简称 WIP） – 明确设定限制在每个状态下同一时间能有多少工作任务
度量生产周期（即完成一个任务的平均时间），优化开发过程，缩短开发周期和使它更易于预测。
相似
- 两者都符合精益和敏捷思考
- 两者使用”拉动式”安排日程
- 两者限制开发中工作数目
- 两者是透过透明度来驱动过程开进
- 两者集中提早及衡常的付运软件
- 两者基于自我组织团队
- 两者要求把工作细分
- 在两个情况下发布计划都是基于经验数据（速度／开发周期）持续优化
|
| Scrum | Kanban** | | —- | —- | —- | | 规划 | 它有固定的计划。它专注于规划。它从 sprint 计划开始，以 sprint 回顾结束。召开每日会议，以便团队了解接下来的步骤、优先级以及从先前步骤中获得的经验。 | 它没有固定的计划，也没有举行日常会议。在看板中，随时可能发生变化，即频繁发生变化。 | | 时间线 | 在 Scrum 中，我们处理具有固定持续时间的冲刺，这意味着经过一些固定时间后，我们将向客户交付一些东西。 | 看板没有冲刺的概念，因此它没有将产品交付给客户的固定时间表。 | | 任务估计 | 在冲刺计划期间，决定从产品待办列表中提取多少活动并添加到冲刺待办列表中。例如，如果冲刺是两周，那么选择活动的数量，使它们可以在冲刺内完成，即在两周内完成。 | 它不估计任务。 | | Scrum Master | 在 Scrum 方法论中，我们有一名 Scrum 主管负责管理团队并每天主持会议。 | 在看板方法论中，我们没有任何 Scrum Master。交付有价值的产品是每个人的责任。 | | 适用性 | 这种方法适用于大型项目，因为大型项目可以分为多个冲刺。 | 主要适用于小型项目。 | | 不断变化 | 在 Scrum 中，可以在较短的冲刺中轻松适应不断的变化。 | 如果发生任何重大变化，那么看板方法就会失败。 | | 成本 | 在 Scrum 中，任务是估计的，即在一个 sprint 中进行固定数量的活动，因此项目的总成本最小。 | 在看板中，没有估算任务，因此项目的总成本不准确。 | | 角色和职责 | 在 Scrum 中，Scrum Master 为团队成员分配了特定的角色，而产品负责人则告诉团队成员必须工作的产品目标。 | 没有为团队成员分配预定义的角色。所有团队成员都有责任合作交付有价值的产品。 | | 生产力衡量 | 生产力是通过使用周期时间或完成整个项目从开始到结束所花费的时间来衡量的。 | 生产力是通过冲刺速度来衡量的。 | | 发布方法 | 每个冲刺结束后的小版本。 | 它提供持续交付。 |
区别
在团队的项目管理实践中，我们往往将二者的优势结合起来综合的使用，以便帮助团队更好的完成目标，而不是为了使用方法而使用方法。本文简单的比较一下二者的不同，希望能帮助大家在实施过程中找到最合适的方法。
系统范围
在讨论Scrum和看板之前，有必要澄清系统范围。在Scrum里，系统范围由产品的定义和完成的定义决定；而在看板里，看板系统的边界定义了系统范围。
Scrum的运作是围绕产品的，每个迭代开始从产品待办列表挑选进入下一个迭代的故事，迭代结束将故事做到完成。故事的范围是由产品的定义决定的，故事在产品的范围内是端到端的。完成的定义体现的是故事可交付的程度，也就定义了价值流的终点。
看板系统的边界定义了价值流的范围，由此决定故事的范围。故事会流过整个看板系统，其终点状态完成的定义也就相当于Scrum中完成的定义。
需要指出的是Scrum的系统范围定义通常是基于组织结构的，它涉及到产品的定义和团队的组建，产品待办列表要与团队相对应，因此系统边界相对严格；而看板的系统范围定义只是基于在统一的看板系统做可视化和管理流动，因此系统边界相对宽松。这也跟两者不同的变革导入思路有关。
两者都有一个思想去尽可能地扩展系统范围，以利于管理整体的价值流动和实现。只是体现出来的对Scrum而言是产品定义的扩展和完成定义的扩展，而对看板而言是看板系统边界的扩展。
在我看来，无论Scrum还是看板，都希望帮助到价值交付和持续改进，但是它们采取了不同的方式。最显著的差别在于Scrum采用迭代而看板采用流。
价值交付
- Scrum和看板都致力于最大化价值交付，无论是采用迭代还是流，关键都在于减少在制品。在制品由进行中故事的个数和故事的大小决定。
- 当采用迭代时，限制故事的个数是间接的，迭代长度间接限制了故事的个数。当采用流时，限制故事的个数却是直接的。
故事的大小是另一个影响在制品多少的因素。迭代会推动故事的拆分，因为在迭代结束时要求能够将故事完成。然而，把故事拆得过小会使拆分变得不自然（也就是为了拆而拆），反而降低了那些拆分出来故事的价值。故事不能被无限地拆分，一个故事在有价值的前提下能拆多小通常存在自然的限制。采用迭代有可能会人为地破环故事的自然大小和完整性，而采用流则会更遵照故事自然的颗粒度。
持续改进
Scrum和看板都致力于持续改进，无论是采用迭代还是流，关键都在于创造合适的挑战来驱动改进。当改进目标达成后，改进就会陷入停滞，而持续改进却需要永不停歇。Scrum和看板都是通过提升目标来再次创造合适的挑战以使改进继续，但是提升目标的方式却不同。
Scrum里最重要的改进目标是在迭代结束做到完成。这里有两个变量，迭代长度和完成的定义。当通过改进做到迭代结束完成后，我们会看完成的定义是否可以扩展。扩展后的完成定义产生了新的挑战，从而提供了继续改进的动力。当完成的定义已经达到可以交付时，我们会看是否可以缩短迭代长度，这又能驱动进一步的改进。
看板的改进目标一方面来自于直接的在制品减少。通过在制品限制的降低，系统中更多问题会被暴露出来，从而驱动改进。另一个重要的因素是围绕前置时间的改进，前置时间的缩短对价值交付和提升灵活性都有帮助，因此是很好的改进目标。
变革导入
最后想说说的是关于Scrum和看板的变革思路。我理解的根本在于改善（小变化）和改革（大变化）的平衡。当引入过大变化，由此产生的挑战过大，结果适得其反。当过于保守引入过小变化，又使变化过于缓慢，甚至逐步丧失了改革的能力。
Scrum的有效运作需要组织设计，它的第一步在我看来是改革，然后由每个迭代回顾驱动持续改进。看板尊重现有的组织结构，从现状出发，因此它的第一步更接近改善，然后也是持续改进。对两者而言持续改进理论上引发改善或者改革都有可能，实际中发生更多的是改善。
当变革涉及系统范围的扩展时，Scrum要求组织结构的改变，而看板要求的最小改变只是放在统一的看板上进行可视化管理，因此更能反映“可能的艺术”。而当现有的组织结构制约了协作模式并最终影响到价值流动时，组织结构仍然需要被突破。
区别一：实施过程中关注核心的区别
Scrum实施的核心可以概括为“化繁为简”，从几个维度解释下：
- 团队角色的定义，将团队人员定义为三个角色，Scrum Master（主要负责消除障碍，带领团队运作）、Product Owner（主要负责描绘产品远景，定义优先级）、Scrum Team（主要负责实现产品）
- 工作任务的拆分，将产品需求拆分成小的用户故事，并评估优先级
- 时间的拆分，将项目周期拆分成固定时长的迭代周期，每个迭代交付一部分可验收的功能，通常迭代长度为1到4周
Kanban方法在实施的过程中更多关注的是可视化的价值流动，从几个维度解释下：
- 拉动式生产，下游工作完成后，主动拉动上游的任务移动
- 限制WIP（work in progress），明确设定限制每个状态下，同一时间内有多少工作量，减少同一状态同一时间内，任务和价值的堆积
- 可视化的价值流动通常是端到端的流动，直观的反映用户的价值（通常是可交付的用户需求），并且反映出在价值流动过程中的瓶颈和问题，不断为团队改善提供依据
区别二：限制WIP数量的方式不同
Scrum与Kanban方法都会限制在制品数量，不过限制方式有所不同，Kanban方法限制的更加直接，同一状态同一时间内的工作任务有最大限制；Scrum是间接性的通过迭代（sprint）来限制。限制WIP的核心目的是加速交付用户需求的价值流动。
区别三：对任务变更管理的不同
在Kanban方法的中，下游任务完成后，即可拉动上游任务下移，同时，只要生产力允许，即可新增需求。 
在Scrum方法下，当每个迭代的sprint Backlog确认后，当前迭代是不允许新增需求的，新增加的需求可以体现在下个迭代的sprint backlog中。
区别四：改进依据的不同
- Scrum是以生产率作为计划和改进的依据，以迭代（sprint）数据作为依据，分析迭代的相关数据（包括生产率、完成率等）；
- Kanban方法是使用生产周期作为计划和过程改进的依据。
Scrum和Kanban方法作为即敏捷又精益的典型代表，除了上述不同外，还存在很多相同点：
- 二者都和敏捷与精益相对应。敏捷中的持续改进思想在Scrum和Kanban都有所体现，而且是很核心的一个内容；精益中的拉动式生产在Scrum和Kanban中也都分别覆盖，Kanban方法体现的更加直接，下游直接拉动上游的工作任务。
- 二者都关注尽早的交付价值，尽可能频繁的发布可使用的软件。Scrum将整个项目周期拆分成多个迭代，每个迭代发布可验收的软件；Kanban方法在每个功能开发测试完成后就可以进行部署和发布。
- 团队状态都直观的反应在Scrum board和Kanban Board上，方便找到问题和瓶颈，并进行改善。
比较了Scrum与Kanban方法之后，如何结合二者在团队中进行项目管理实践呢？
笔者结合自己的经验从迭代、版本、变更、改进四个方面给大家进行一个简单的介绍。
迭代：在Kanban方法中，并未规定明确的迭代，而在Scrum中是规定了固定的迭代周期。在我们的团队中，迭代周期从一月一迭代，逐步变为一月两迭代，到现在的两个自然周一个迭代，完全固化了迭代周期的概念。
将复杂开发周期很长的开发任务，分解成多个迭代周期，每个迭代周期交付一些可验收的软件或者功能。有利于减少风险，并更好的适应变化，及时的根据反馈调整工作目标。
版本：在迭代中，我们以排入版本计划的功能点（story）作为工作重点，排入版本的story为交互已经完成的功能点（story），这些功能点可以直接进入开发和测试环节。这些story便是我们当前迭代可以交付的功能或者软件。与此同时，产品、交互和视觉同学会继续拉取需求池中的功能点，开始进行设计，准备下个迭代版本中的内容。使整个价值流动更加顺畅。
变更：对待变更，我们同样有自己的一套流程规范，既没有像Kanban方法一样，只要生产力允许，便可以新增需求；也没有像Scrum一样，版本内容确定，当前迭代基本不允许变更。
在实际过程中，当存在紧急需求，由产品经理发起，和各个角色进行评估风险和对现有版本的影响，并采取相应措施降低由于需求变更对整个系统产生的影响，最后由项目经理发出变更通知的邮件。
改进：我们改进的依据之一是团队数据，由于我们所有的任务都是通过JIRA进行管理，可以方便的拿个团队各种数据，包括：总工作量、总完成工作量、完成率、有效工作量、有效工作率、bug数、bug率等，对这些数据进行分析，发现团队的问题，帮助团队进行改进。
若有收获，就点个赞吧
0 人点赞
