看板管理与Scrum的比较

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

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

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

一、Scrum简介

把组织细分成小組、跨功能、自我组织团队。

把工作细分成细小、实在的交付成果，交排人员负责需求清单以及跟据重要性排优先级别，由团队估算每个项目相对工量。

把整个开发时间分成固定时长的短迭代（通常于一至四星期），在每个迭代后演示新增可发布功能。

优化发布以及跟客户一起更新优先级别，基于每个迭代后发布的观察。

优化过程，在每个迭代之后进行回顾

二、看板开发方式简介

工作流程形象化

把工作细分成任务，写在卡纸上，贴在墙上

把栏命名好，來显示任务在工作流程中的狀況

限制“在制品”（work in progress，简称 WIP） – 明确设定限制在每个状态下同一时间能有多少工作任务

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

相同点

两者都符合精益和敏捷思考

两者使用"拉动式"安排日程

两者限制开发中工作数目

两者是透过透明度来驱动过程开进

两者集中提早及衡常的付运软件

两者基于自我组织团队

两者要求把工作细分

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

不同点

Scrum看板开发方式

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