比较Kanban和Scrum

看板开发方式是近年引起很多讨论和注目的一种敏捷开发实施，有不少人问到「看板开发方式如何跟Scrum比较？」，Henrik Kniberg就尝试回应这问题。

Henrik Kniberg最新发表 比较看板开发方式和Scrum的"实务指引" ，Kniberg在这精要的文章中指出看板开发和Scrum如何类似以及如何不同。

文章开始以一个清单介绍两种方式：

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

详情可参考"Scrum and XP from the Trenches"，这本书供免费下载。我认识作者，他很友善 :o) http://www.crisp.se/ScrumAndXpFromTheTrenches.html
（译者注：中文版由李剑翻译，作者译者我也认识，他们都很友善的 :o) http://www.infoq.com/cn/minibooks/scrum-xp-from-the-trenches）

看板开发方式简介
工作流程形象化

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

限制“在制品”（work in progress，简称 WIP） – 明确设定限制在每个状态下同一时间能有多少工作任务
度 量 生产周期（即完成一个任务的平均时间），优化开发过程，缩短开发周期和使它更易于预测。

详情可参看Karl Scotland的介绍：http://availagility.wordpress.com/2008/10/28/kanban-flow-and-cadence/

在之后二十多页中，Kniberg仔细地比较两者的分别，在文章最后总结他的观点：

相似

• 两者都符合精益和敏捷思考
• 两者使用"拉动式"安排日程
• 两者限制开发中工作数目
• 两者是透过透明度来驱动过程开进
• 两者集中提早及衡常的付运软件
• 两者基于自我组织团队
• 两者要求把工作细分
• 在两个情况下发布计划都是基于经验数据（速度／开发周期）持续优化

分別

Scrum	看板开发方式
要求定时迭代	没指定定时限迭代，可以分开计划、发布、过程改进，可以事件驱动而不是限定时限
团队在每个迭代承诺一定数目的工作	承诺不是必须的
以速度（Velocity）作为计划和过程改进的度量数据	使用开发周期作为计划和过程改进的度量数据
指定跨功能团队	没有指定跨功能团队，也容许专门团队
工作任务细分，可于一个迭代中完成	没有指定工作任务大小
指定使用燃烧图	没有指定任何图表
间接限制开发中工作（每个迭代）	设定开发中工作的限制（每个工作流程状态）
规定估算过程	没有指定任何估算方式
在迭代中不能加入新工作任务	只要生产力容许，可以随时加工作任务
由单一团队负责 Sprint Backlog	多个团队和团员分享看板
指定三个角色（产品负责人／ScrumMaster/团队）	没有指定任何团队角色
Scrum board 在每个迭代后重设	看板反映持久开发情况
规定优先化的 product backlog	优先级是非必须的

如果您也曾有此疑问，或者朋友也有类似问题，也许应该花些时间读Kniberg的" Kanban vs Scrum "文章。

查看英文原文 ： Comparing Kanban To Scrum