去年，Scrum似乎很常见，我听到人们经常使用它来等同于“敏捷”。最近，Kanban似乎是叫嚣比较大的一个术语。已经掌握了Scrum的组织正在向Kanban移动。越来越多的ALM厂商正在把Kanban功能加入到他们的产品中，而且一些会议及用户组织也充斥着类似的会议，例如，如何工作“精益”和“连续流动”，这通常就相当于使用Kanban。但是Kanban真正是什么，它是否与Scrum不同？这两者可以一起使用吗？本文中，项目经理和团队领导者详细地讲述了Scrum和Kanban，既说明了两都不同，也介绍了它们可能互补。

　　可交付的成果不同

　　尽管在什么使软件开发“敏捷”的话题上存在许多争论，但关于具体的方法论上有很多定义。正如前面提到的博客文章, Henrik Kniberg 的“探索Kanban，敏捷开发冉冉升起的新星”和Kanban vs. Scrum文章中，提到Scrum有9条规则，而Kanban只有3条。

　　“规则”规定，团队使用如下：

1. Scrum主管（Scrum Master）
2.产品负责人 （Product Owner）
3. 开发团队（Team）
4. 计划会 Sprint Planning Meeting
5. 每日立会（Daily Scrum）
6.冲刺评审（Sprint review）
7. 产品订单（Product Backlog）
8. 冲刺订单（Sprint Backlog）
9. 冲刺燃尽图（Burndown Chart）

　　Kanban只要求下面的几点：

1可视化工作流
2.限制以流程为工作中心
3.权衡和优化工作流

　　追踪流程使用的测量不同

　　在Scrum中，团队使用迭代方法，它是指“定时”或在特定的时间内做增量，称作冲刺，通常情况下是2-4周。在每一个迭代的开始都会有一个冲刺计划会议，会议上从产品订单中选择出案例，选择出案例在下一次迭代中开发。

　　为了确定出在每一次迭代中的工作量，团队的执行将会通过“燃尽图”进行跟踪，此图中X轴代表需要完成的工作预估，Y轴是迭代时间线。燃尽图衡量着团队的“周转率”，此“周转率”是一个测量，展示出团队在迭代中的生产效率如何。

　　评估每一个安全的任务，通常是用“安全点数”表示是有必要的，从而可以正确地分割工作，分割成他们可以在一次迭代中完成的大小。

　　在Kanban中，使用不同的衡量方法来确定项目是否要被跟踪。队列用来表示工作流。例如，一个队列在清单中包含了所有项目，一个队列给开发，一个队列给测试，还有一个队列给部署。通常会使用一个Kanban面板，把案例卡片随着进程在面板上移动。

　　不是定时一个案例，要求在一次迭代中此案例必须完成，Kanban限制了WIP或以流程为中心的工作。团队必须给每一次活动确定WIP限制，但是一旦满足了WIP的限制，团队成员必须一起工作，清除所有的阻碍区域。整个生命周期时间就是完成此案例的时间。随着时间对此进行测量，团队交会了解多长时间他们会完成所有案例。Kanban支持者相信使用周期时间最终会允许团队在他们需要时做出准确的估计。

　　角色和会议不同

　　Scrum定义了非常具体的角色和必须举行的会议。必须有一个Scrum主管、一个产品负责人和一个开发人员团队编码和测试用例。Scrum主管推动会议并帮助所有阻碍团队进程的障碍。产品负责人代表业务人员或用户，帮助阐明案例并区分先后次序。

　　Scrum规定要有一个冲刺会议来确定哪一个案例要进行冲刺。有一个日常Scrum会议，有称为站立会议，它是一个简短的会议，让团队明白了解前一天每一个成员都做了什么、他们今天的计划和所有的阻碍。在冲刺的最后，有一个冲刺审查会议来演示所做和的软件，并进行回顾，检查什么进行良好，及什么需要改进。

　　Kanban不要求有像Scrum定义的角色和会议；然而，许多从Scrum方法转型的团队维持了在他们Scrum团队中使用的角色和会议。Kanban没有规定衡量和优化流，因此团队没有看到项目的测量和工作方向的持续改进。

　　转变不同

　　比Kanban更规范的Scrum通常对软件开发团队来说更难以转变。有一个特定的必须遵循的框架，而且如是团队现在正在使用转型的软件开发方法，那么对于团队来说将是一个很大的转变，全新的工作方式和新角色。

　　Kanban设计为开始于你正在使用的流程，而且工作方面持续改进。团队鼓励去映射他们目前的工作流流程和确定瓶颈。该流程是为了进化到一个独特的和优化的工作流程的团队的一种手段。

　　Scrum和Kanban是互补的吗？

　　正如我们所看到的，Kanban并不意味着左右你的方法，而是通过优化改进流程流。Kanban可以和Scrum一起使用，尽管在案例或任务分配和衡量的方式上存在不同。无论是Scrum还是Kanban的实践都可能使用视为“敏捷”的技术，如测试驱动开发或持续集成。在这两种情况中，团队的工作方向是衡量和改进。