看板管理与Scrum的比较

2017-11-16 10:10:00
admin
转贴:
CSDN
716
摘要:Henrik Kniberg最新发表 比较看板开发方式和Scrum的"实务指引" ,Kniberg在这精要的文章中指出看板开发和Scrum如何类似以及如何不同。
看板开发方式是近年引起很多讨论和注目的一种敏捷开发实施,有不少人问到「看板开发方式如何跟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楼