Scrum VS 看板

什么是看板

• 将流程可视化
  1. 把工作拆分成小块，一张卡片写一件任务，再把卡片放到墙上。
  2. 每一列都起一个名字，显示每件任务在流程中处于什么位置。
• 限制 WIP（在制品，work in progress）： 明确限制流程中每个状态上最多同时进行的任务数。
• 度量生产周期（完成一件任务的平均时间，又称循环周期），对流程进行调
  优，尽可能缩短生产周期，并使其可预测。

什么是srum

• 把组织拆分成小规模的、跨功能的自组织团队。
• 把工作拆分成一系列小而具体的交付物。按优先级排序，估算每项任务的相对
  工作量。
• 把时间拆分成固定大小的短迭代（通常为 1-4 周），在每个迭代结束时对基本可
  以交付的代码进行演示。
• 在每个迭代结束后跟客户一起检查发布目标，并据此优化发布计划，更新任务
  优先级。
• 每个迭代结束后进行回顾，进行过程优化。

我们不是靠一个庞大的团队，花大量时间造出庞然大物；而是用小团队在短时间内做出小块的东西来，在有规律的集成中组装出全貌。

看板和srum的区别和关系

• 相同点

  1. Scrum 和看板都是过程工具：
     工具=用于完成任务或达成目的的任何东西
     过程=工作方式
     Scrum 和看板都是过程工具，它们讲的是做哪些事情能够在一定程度上帮助 你提高工作效率。Java 也是工具，它让编程更加简单。牙刷也是工具，它让你够得到牙齿，方便清洁。

  2. 二者都是经验主义的：
     这种方式有很多叫法：改善（Kaizen。即持续改进，精益术语）,内省与调整（Inspect & Adapt，Scrum 术语），经验式过程控制（Empirical Process Control），乃至科学方法（The Scientific Method）。
     它最核心的一点就是反馈环。改变 => 检查结果 => 从中学习 => 继续改变。一般而言，反馈环越短越好，这样可以快速调整过程。

  3. 都允许在多个产品上并行工作:
     下面是两个产品，绿色和黄色，每一个都有自己的产品 backlog，也有自己的团队。
     

     

     WX20190416-185016.png

万一你只有一个团队呢？其实，你可以把产品 backlog 当作团队 backlog 看待。如果
团队在维护多个产品，就把这些产品都合并到一个列表里面。这会迫使我们把产品
放在一起考虑优先级。我们可以采取多种做法：

其一，每个 Sprint 聚焦一个产品：

WX20190416-185021.png

其二，每个 Sprint 里面，两个产品的特性都要做：

WX20190416-185703.png

在一张图上可以有多个产品流动。我们可以用不同颜色的卡加以区分：

WX20190416-185740.png

也可以用“泳道”来区分：

WX20190416-185744.png

4. 都是既精益又敏捷
   Scrum 和看板跟精益思想和敏捷宣言里面的价值观和原则是相当吻合的。
   1）Scrum 和看板都是拉动式计划系统，跟精益的 JIT（准时化）库存管理原则是
   一致的。这表示团队决定从什么时候开始干活，干多少活。等他们准备就绪
   的时候就把工作“拉”过去，而不是从外部“推”进来。就像打印机只有在准备
   打印的时候才把下一页拉进去一样（当然，打印机还是有些小小库存的）。
   2）Scrum 和看板都基于持续的、经验主义的过程优化，这跟精益的改善原则是
   一致的。
   3）Scrum 和看板都强调响应变化胜过遵循计划（虽然看板的响应速度一般要比
   Scrum 快），这是敏捷宣言的四项价值观之一。

• 不同点

  1. Scrum 规定了三种角色：产品负责人（描绘产品远景，定义优先级）、团队（实现产品）、Scrum Master（消除障碍，带领过程运作）。
     看板没规定任何角色。
     这可不是说你不能或是不应该在看板里有产品负责人的角色。这只是说你不是非有不可。不管是用看板还是 Scrum，你都可以根据需要增加任意角色。

  2. Scrum 规定了固定时长的迭代:
     固定时长的迭代是 Scrum 的基础。你可以选择迭代长度，但一般都会在一定时间内让迭代长度固定不变，继而形成节奏。
     • 迭代伊始：综合考虑产品负责人定义的优先级和自己的生产率，团队从产品backlog 里面挑选出一定数量的条目，创建迭代计划。
     • 迭代进行中：团队全心投入所承诺的任务。迭代范围已固定。
     • 迭代结尾：团队向相关干系人演示他们可以工作的代码，理想情况下，这些代码基本上是可以发布的（经过测试可以交付）。然后团队进行回顾，讨论如何改进过程。
     所以 Scrum 的迭代就是一段长度固定的单声部旋律，混合了三种活动：计划、过程改进、（理想中的）发布。
     看板没有规定固定时长的迭代:
     你可以选择什么时候做计划，什么时候改进过程，什么时候发布。 你还可以选择是有规律的采取行动（如每周一发布），还是按实际需要进行（如有了有用的东西之后就发布）。
     

     

     WX20190415-190428.png

  3. 看板按流程状态限制 WIP，Scrum 按迭代限制 WIP:
     

     

     WX20190415-190742.png
     
     • 太低的看板上限 => 发呆的人 => 低生产率
     • 太高的看板上限 => 发呆的任务 => 长生产周期

  4. 反馈机制
     Scrum 的基本反馈环就是 Sprint：

     

     WX20190415-192304.png
     
     看板的实时度量指标：
     • 平均生产周期。每次有任务到达“Done”这一列（不管它叫什么吧，反正是最右边那一列）的时候就更新数据。
     • 瓶颈。典型症状就是 X 列里面堆满了卡片，但是 X+1 列里空空如也。找找板上哪里有“气泡”吧。
     
     

     WX20190416-132316.png

WX20190416-132656.png

WX20190416-132848.png

5. Scrum 在迭代内拒绝变化：
   
   

   WX20190416-133600.png
   
   Scrum团队一般会说，“对不起，这样不行。我们已经承诺了这个sprint要做完A+B+C+D。
   不过你可以把它放到产品 backlog 里面。如果产品负责人觉得它优先级很高的话，我
   们会从下一个 sprint 开始做。

WX20190416-133613.png

看板的原则是“一件出去，一件进来”（由 WIP 驱动），所以看板团队的响应时间（多
久才能响应优先级的变化）就等于他们要花多长时间才能把手头的事情做完。

6. Scrum 板在迭代之间重置
   
   

   WX20190416-134320.png

Sprint 结束以后，板子就会进行清理──所有卡片全部去掉。

WX20190416-134326.png

看板图的样子几乎是一成不变的──你不需要把板子清理干净，重新开始

7. Scrum 规定了跨功能团队
   
   

   WX20190416-134955.png

Scrum 板对所有感兴趣的人全都是可见的，但只有它的所属 Scrum 团队才能编辑──这是他们管理迭代承诺的工具。

WX20190416-135001.png

看板不强制要求跨功能团队，看板图也不是独归某个团队所有。看板图对应的是流程，不必非得是一个团队。

8. Scrum 的 backlog 条目必须能跟 Sprint（生产周期） 搭配的上
   Scrum 团队只会承诺他们认为能在一个迭代里面做完（基于他们对“完成”的定义）
   的任务。如果任务太大了，一个 Sprint 放不下，团队跟产品负责人就会寻找方法拆
   分，直到能放下为止。如果任务都比较大，迭代就会较长（虽然一般都不会超过四
   周）。
   
   

   WX20190416-135931.png

WX20190416-135937.png

9. Scrum 规定了估算和生产率

WX20190416-183452.png

在 Scrum 里面，团队要对每个承诺的任务估算其相对大小（=工作量），到迭代结束
的时候，把每个任务的大小相加，就得到了生产率。生产率是度量团队能力──我们
每个 Sprint 能交付多少东西──的指标。

看板没有规定估算这回事，但是看板没有规定任何具体的方式，所以就去 Google 吧

10. ****Scrum 规定了经过优先级排序的产品 backlog***
11. Scrum 规定了每日立会
12. Scrum 规定了燃尽图

敏捷宣言

我们一直在实践中探寻更好的软件开发方法，
身体力行的同时也帮助他人。由此我们建立了如下价值观：

个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划

也就是说，尽管右项有其价值，
我们更重视左项的价值。