Scrum和看板的区别

看板：在制品(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.”)