巧用Scrum与Kanban
本文来自网易云社区
文\屈鹏飞
在互联网行业的项目管理实践中，敏捷和精益一直是大家所提倡的思想，其中Scrum和Kanban方法作为即敏捷又精益的典型代表，许多PM都在研究，笔者近期也在学习和实施Scrum和Kanban方法，有些感触拿出来与大家一同分享。
Kanban方法最初起源于丰田的JIT（Just In Time），之后作为一种高效管理软件开发流程的技术和思想应用于互联网行业。Kanban方法以价值流动为核心，不断发现团队中的瓶颈工序，进行改进，使价值流动更加顺畅和快速。
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率等，对这些数据进行分析，发现团队的问题，帮助团队进行改进。
对于Scrum与Kanban方法的应用，笔者还在实践中不断的探索和思考，还有许多需要迭代改进的内容，期待与大家一起沟通交流。
本文来自网易云社区，经作者屈鹏飞授权发布
网易云免费体验馆，0成本体验20+款云产品！
更多网易研发、产品、运营经验分享请访问网易云社区。
相关文章：
【推荐】 组建验证码的具体工作流程
【推荐】 Clojure基础课程2-Clojure中的数据长啥样?
【推荐】 用SolrJ操作Solr做搜索（下篇）
