看板：在制品(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.”)
原文地址：https://www.cnblogs.com/chenliangcl/p/9154524.html