Scrum与看板区别

coding

看板:在制品(work-in-progress, WIP)必须被限制

WIP上限和拉动式生产

 

1. Scrum与看板简述

Scrum:组织拆分,工作拆分,开发时间拆分,优化发布计划,过程优化

看板:流程可视化,限制WIP,度量生产周期

 

2. Scrum和看板的关系

Scrum和看板都是过程工具

Scrum和看板只是给了一些明确的约束和指导,比如,Scrum的约束是固定时长的迭代和跨功能团队,看板的约束是要有可见的看板,队列大小要有约束

敏捷方法也被称作轻量级方法

 

3. Scrum规定了角色

Scrum规定了三种角色:PO/Team/SM,看板没规定任何角色

 

4. Scrum规定了固定时长的迭代

Scrum的迭代混合了三种活动:计划/过程改进/发布

 

5. Scrum按迭代限制WIP,看板按流程状态限制WIP

 

6. 

Scrum与看板都是经验主义,需要自省/反馈/调整

 

7. 

Scrum在迭代期间内拒绝变化


看板的原则是“一件出去,一件进来”,响应时间等于手头事情的处理时间

Scrum的平均响应实践等于sprint长度的一半

 

8. 

关于任务规模

     Scrum团队只承诺一个迭代内能完成的任务,如果任务太大会进行拆分

     看板对任务规模没有明确规定必须要在某个时间段做完

 

9. Scrum规定了估算和生产率,看板没有规定估算

     有的团队跳过估算,把每个任务拆分得大小接近,统计每周完成的特性数

     有的团队把任务打包成MMF(最小适销特性),度量每个MMF的生产周期,建立SLA(服务品质承诺)

 

10. 跨产品的团队如何使用backlog

    可以把产品backlog当作团队backlog看待     

    可以通过泳道来区分多个产品

 

---------------------------------------

scrum与看板,看了本书之后确实比以前更清楚(自认为)

 

1. scrum更侧重团队的组织与工作任务拆分(实施),看板更侧重于任务流的可视化(呈现)

2. 看板让团队的工作更透明,更多的细致工作需要scrum来落实实施(三会,各种角色,估算,sprint)

3. 两者都是过程工具,和设计模式一样是前人经验,应用到团队中需要取其精华去其糟粕,摸索适合本团队的方法

4. 团队通常会将scrum和看板结合使用

 

书中出现的几个关键字,

 

WIP:work-in-progress,在制品,WIP必须被限制是kanban的主要思想之一

泳道:最开始是在UML中出现,叫swimlane也有人叫partition,除了纵向的按照状态定义的列,还可以使用横向的泳道区分,比如区分一个团队中的多个产品

T恤法:用来做估算,小/中/大,定性不定量

 

Scrum

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

 

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

 

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

 

  • 优化发布以及跟客户一起更新优先级别,基于每个迭代后发布的观察。 
  • 优化过程,在每个迭代之后进行回顾

 

我们不是靠一个庞大的团队,花大量时间造出庞然大物;而是用小团队在短时间内


做出小块的东西来,在有规律的集成中组装出全貌。

 

二、看板开发方式简介 

  • 工作流程形象化
  • 把工作细分成任务,写在卡纸上,贴在墙上
  • 把栏命名好,來显示任务在工作流程中的狀況
  • 限制“在制品”(work in progress,简称 WIP) – 明确设定限制在每个状态下同一时间能有多少工作任务。看板的本质是一个很朴素的思想:在制品(work-in-progress,WIP)必须被限制。只有当前的某项工作被交付,或是有了来自于下游的拉动,新的工作才能开始。
  • 度量生产周期(即完成一个任务的平均时间),优化开发过程,缩短开发周期和使它更易于预测。

 

相同点

 

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

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

两者限制开发中工作数目

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

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

两者基于自我组织团队

两者要求把工作细分

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

 

不同点

 

 

 

 

Scrum

看板开发方式

要求定时迭代

没指定定时限迭代,可以分开计划、发布、过程改进,可以事件驱动而不是限定时限

团队在每个迭代承诺一定数目的工作

承诺不是必须的

以速度(Velocity)作为计划和过程改进的度量数据

使用开发周期作为计划和过程改进的度量数据

指定跨功能团队

没有指定跨功能团队,也容许专门团队

工作任务细分,可于一个迭代中完成

没有指定工作任务大小

指定使用燃烧图

没有指定任何图表

间接限制开发中工作(每个迭代)

设定开发中工作的限制(每个工作流程状态)

规定估算过程

没有指定任何估算方式

在迭代中不能加入新工作任务

只要生产力容许,可以随时加工作任务

由单一团队负责 Sprint Backlog

多个团队和团员分享看板

指定三个角色(产品负责人/ScrumMaster/团队)

没有指定任何团队角色

Scrum board 在每个迭代后重设

看板反映持久开发情况

规定优先化的 product backlog

优先级是非必须的

Scrum 与  XP

不同点:Scrum 非常突出Self-Orgnization(管理 ),XP 注重强有力的工程实践 约束 。在具体的应用中可以将两者结合,在管理模式上启用Scrum, 而在实践中,创造一个适合自己项目组的XP(“start with Scrum and then invent your own version of XP.”)

以下为转载:

区别之一 : 迭代长度的不同

XP的一个Sprint的迭代长度大致为1~2周, 而Scrum的迭代长度一般为 2~ 4周.

区别之二 : 在迭代中, 是否允许修改需求

XP在一个迭代中,如果一个User Story(用户素材, 也就是一个需求)还没有实现, 则可以考虑用另外的需求将其替换, 替换的原则是需求实现的时间量是相等的。 而Scrum是不允许这样做 的,一旦迭代开工会完毕, 任何需求都不允许添加进来,并有Scrum Master严格把关,不允许开发团队收到干扰

区别之三 : 在迭代中,User Story是否严格按照优先级别来实现

XP是务必要遵守优先级别的。 但Scrum在这点做得很灵活, 可以不按照优先级别来做,Scrum这样处理的理由是: 如果优先问题的解决者,由于其它事情耽搁,不能认领任务,那么整个进度就耽误了。 另外一个原因是,如果按优先级排序的User Story #6和#10,虽然#6优先级高,但是如果#6的实现要依赖于#10,则不得不优先做#10.

区别之四 :软件的实施过程中,是否采用严格的工程方法,保证进度或者质量

Scrum没有 对软件的整个实施过程开出养个工程实践的处方, 要求开发者自觉保证 .

但XP 对整个流程方法定义非常严格,规定需要采用TDD, 自动测试, 结对编程,简单设计,重构等约束团队的行为 。因此,原作者认为, 这点上,XP的做法值得认同的,但是却把敏捷带入了一个让人困惑的矛盾, 因为xp的理念,结合敏捷模式,表达给团队的信息是“你是一个完全自我管理的组织, 但你必须要实现TDD, 结对编程, ...等等”

不难发现,这四个区别显见的是: Scrum非常突出Self-Orgnization, XP注重强有力的工程实践约束

 在管理模式上启用Scrum, 而在实践中,创造一个适合自己项目组的XP(“start with Scrum and then invent your own version of XP.”)

以上是 Scrum与看板区别 的全部内容, 来源链接: utcz.com/z/508782.html

回到顶部