看板管理与Scrum的比较
- 2018-03-15 10:10:00
- iamdll
- 转贴：
- CSDN
- 967
看板开发方式是近年引起很多讨论和注目的一种敏捷开发实施，有不少人问到「看板开发方式如何跟Scrum比较？」，Henrik Kniberg就尝试回应这问题。
Henrik Kniberg最新发表 比较看板开发方式和Scrum的"实务指引" ，Kniberg在这精要的文章中指出看板开发和Scrum如何类似以及如何不同。
文章开始以一个清单介绍两种方式：
一、Scrum简介
- 把组织细分成小組、跨功能、自我组织团队。
- 把工作细分成细小、实在的交付成果，交排人员负责需求清单以及跟据重要性排优先级别，由团队估算每个项目相对工量。
- 把整个开发时间分成固定时长的短迭代（通常于一至四星期），在每个迭代后演示新增可发布功能。
- 优化发布以及跟客户一起更新优先级别，基于每个迭代后发布的观察。
- 优化过程，在每个迭代之后进行回顾
我们不是靠一个庞大的团队，花大量时间造出庞然大物；而是用小团队在短时间内
做出小块的东西来，在有规律的集成中组装出全貌。
做出小块的东西来，在有规律的集成中组装出全貌。
二、看板开发方式简介
- 工作流程形象化
- 把工作细分成任务，写在卡纸上，贴在墙上
- 把栏命名好，來显示任务在工作流程中的狀況
- 限制“在制品”（work in progress，简称 WIP） – 明确设定限制在每个状态下同一时间能有多少工作任务。看板的本质是一个很朴素的思想：在制品（work-in-progress，WIP）必须被限制。只有当前的某项工作被交付，或是有了来自于下游的拉动，新的工作才能开始。
- 度量生产周期（即完成一个任务的平均时间），优化开发过程，缩短开发周期和使它更易于预测。
相同点
两者都符合精益和敏捷思考两者使用"拉动式"安排日程两者限制开发中工作数目两者是透过透明度来驱动过程开进两者集中提早及衡常的付运软件两者基于自我组织团队两者要求把工作细分在两个情况下发布计划都是基于经验数据（速度／开发周期）持续优化
不同点
| Scrum | 看板开发方式 |
|---|---|
| 要求定时迭代 | 没指定定时限迭代，可以分开计划、发布、过程改进，可以事件驱动而不是限定时限 |
| 团队在每个迭代承诺一定数目的工作 | 承诺不是必须的 |
| 以速度（Velocity）作为计划和过程改进的度量数据 | 使用开发周期作为计划和过程改进的度量数据 |
| 指定跨功能团队 | 没有指定跨功能团队，也容许专门团队 |
| 工作任务细分，可于一个迭代中完成 | 没有指定工作任务大小 |
| 指定使用燃烧图 | 没有指定任何图表 |
| 间接限制开发中工作（每个迭代） | 设定开发中工作的限制（每个工作流程状态） |
| 规定估算过程 | 没有指定任何估算方式 |
| 在迭代中不能加入新工作任务 | 只要生产力容许，可以随时加工作任务 |
| 由单一团队负责 Sprint Backlog | 多个团队和团员分享看板 |
| 指定三个角色（产品负责人／ScrumMaster/团队） | 没有指定任何团队角色 |
| Scrum board 在每个迭代后重设 | 看板反映持久开发情况 |
| 规定优先化的 product backlog | 优先级是非必须的 |
文章分类
联系我们
| 联系人： | 阿道 |
|---|---|
| 电话： | 17762006160 |
| 地址： | 青岛市黄岛区长江西路118号青铁广场18楼 |
专注看板管理学习交流