什么是看板
- 将流程可视化
1. 把工作拆分成小块，一张卡片写一件任务，再把卡片放到墙上。
2. 每一列都起一个名字，显示每件任务在流程中处于什么位置。 - 限制 WIP（在制品，work in progress）： 明确限制流程中每个状态上最多同时进行的任务数。
-
度量生产周期（完成一件任务的平均时间，又称循环周期），对流程进行调
优，尽可能缩短生产周期，并使其可预测。
什么是srum
- 把组织拆分成小规模的、跨功能的自组织团队。
- 把工作拆分成一系列小而具体的交付物。按优先级排序，估算每项任务的相对
工作量。 - 把时间拆分成固定大小的短迭代（通常为 1-4 周），在每个迭代结束时对基本可
以交付的代码进行演示。 - 在每个迭代结束后跟客户一起检查发布目标，并据此优化发布计划，更新任务
优先级。 - 每个迭代结束后进行回顾，进行过程优化。
我们不是靠一个庞大的团队，花大量时间造出庞然大物；而是用小团队在短时间内做出小块的东西来，在有规律的集成中组装出全貌。
看板和srum的区别和关系
-
相同点
Scrum 和看板都是过程工具：
工具=用于完成任务或达成目的的任何东西
过程=工作方式
Scrum 和看板都是过程工具，它们讲的是做哪些事情能够在一定程度上帮助 你提高工作效率。Java 也是工具，它让编程更加简单。牙刷也是工具，它让你够得到牙齿，方便清洁。二者都是经验主义的：
这种方式有很多叫法：改善（Kaizen。即持续改进，精益术语）,内省与调整（Inspect & Adapt，Scrum 术语），经验式过程控制（Empirical Process Control），乃至科学方法（The Scientific Method）。
它最核心的一点就是反馈环。改变 => 检查结果 => 从中学习 => 继续改变。一般而言，反馈环越短越好，这样可以快速调整过程。-
都允许在多个产品上并行工作:
下面是两个产品，绿色和黄色，每一个都有自己的产品 backlog，也有自己的团队。
WX20190416-185016.png
万一你只有一个团队呢？其实，你可以把产品 backlog 当作团队 backlog 看待。如果
团队在维护多个产品，就把这些产品都合并到一个列表里面。这会迫使我们把产品
放在一起考虑优先级。我们可以采取多种做法：
其一，每个 Sprint 聚焦一个产品：
其二，每个 Sprint 里面，两个产品的特性都要做：
在一张图上可以有多个产品流动。我们可以用不同颜色的卡加以区分：
也可以用“泳道”来区分：
-
都是既精益又敏捷
Scrum 和看板跟精益思想和敏捷宣言里面的价值观和原则是相当吻合的。
1）Scrum 和看板都是拉动式计划系统，跟精益的 JIT（准时化）库存管理原则是
一致的。这表示团队决定从什么时候开始干活，干多少活。等他们准备就绪
的时候就把工作“拉”过去，而不是从外部“推”进来。就像打印机只有在准备
打印的时候才把下一页拉进去一样（当然，打印机还是有些小小库存的）。
2）Scrum 和看板都基于持续的、经验主义的过程优化，这跟精益的改善原则是
一致的。
3）Scrum 和看板都强调响应变化胜过遵循计划（虽然看板的响应速度一般要比
Scrum 快），这是敏捷宣言的四项价值观之一。
-
不同点
Scrum 规定了三种角色：产品负责人（描绘产品远景，定义优先级）、团队（实现产品）、Scrum Master（消除障碍，带领过程运作）。
看板没规定任何角色。
这可不是说你不能或是不应该在看板里有产品负责人的角色。这只是说你不是非有不可。不管是用看板还是 Scrum，你都可以根据需要增加任意角色。-
Scrum 规定了固定时长的迭代:
固定时长的迭代是 Scrum 的基础。你可以选择迭代长度，但一般都会在一定时间内让迭代长度固定不变，继而形成节奏。
• 迭代伊始：综合考虑产品负责人定义的优先级和自己的生产率，团队从产品backlog 里面挑选出一定数量的条目，创建迭代计划。
• 迭代进行中：团队全心投入所承诺的任务。迭代范围已固定。
• 迭代结尾：团队向相关干系人演示他们可以工作的代码，理想情况下，这些代码基本上是可以发布的（经过测试可以交付）。然后团队进行回顾，讨论如何改进过程。
所以 Scrum 的迭代就是一段长度固定的单声部旋律，混合了三种活动：计划、过程改进、（理想中的）发布。
看板没有规定固定时长的迭代:
你可以选择什么时候做计划，什么时候改进过程，什么时候发布。 你还可以选择是有规律的采取行动（如每周一发布），还是按实际需要进行（如有了有用的东西之后就发布）。
WX20190415-190428.png -
看板按流程状态限制 WIP，Scrum 按迭代限制 WIP:
WX20190415-190742.png
• 太低的看板上限 => 发呆的人 => 低生产率
• 太高的看板上限 => 发呆的任务 => 长生产周期 -
反馈机制
Scrum 的基本反馈环就是 Sprint：WX20190415-192304.png
看板的实时度量指标：
• 平均生产周期。每次有任务到达“Done”这一列（不管它叫什么吧，反正是最右边那一列）的时候就更新数据。
• 瓶颈。典型症状就是 X 列里面堆满了卡片，但是 X+1 列里空空如也。找找板上哪里有“气泡”吧。
WX20190416-132316.png
-
Scrum 在迭代内拒绝变化：
WX20190416-133600.png
Scrum团队一般会说，“对不起，这样不行。我们已经承诺了这个sprint要做完A+B+C+D。
不过你可以把它放到产品 backlog 里面。如果产品负责人觉得它优先级很高的话，我
们会从下一个 sprint 开始做。
看板的原则是“一件出去，一件进来”（由 WIP 驱动），所以看板团队的响应时间（多
久才能响应优先级的变化）就等于他们要花多长时间才能把手头的事情做完。
-
Scrum 板在迭代之间重置
WX20190416-134320.png
Sprint 结束以后，板子就会进行清理──所有卡片全部去掉。
看板图的样子几乎是一成不变的──你不需要把板子清理干净，重新开始
-
Scrum 规定了跨功能团队
WX20190416-134955.png
Scrum 板对所有感兴趣的人全都是可见的，但只有它的所属 Scrum 团队才能编辑──这是他们管理迭代承诺的工具。
看板不强制要求跨功能团队，看板图也不是独归某个团队所有。看板图对应的是流程，不必非得是一个团队。
-
Scrum 的 backlog 条目必须能跟 Sprint（生产周期） 搭配的上
Scrum 团队只会承诺他们认为能在一个迭代里面做完（基于他们对“完成”的定义）
的任务。如果任务太大了，一个 Sprint 放不下，团队跟产品负责人就会寻找方法拆
分，直到能放下为止。如果任务都比较大，迭代就会较长（虽然一般都不会超过四
周）。
WX20190416-135931.png
- Scrum 规定了估算和生产率
在 Scrum 里面，团队要对每个承诺的任务估算其相对大小（=工作量），到迭代结束
的时候，把每个任务的大小相加，就得到了生产率。生产率是度量团队能力──我们
每个 Sprint 能交付多少东西──的指标。
看板没有规定估算这回事，但是看板没有规定任何具体的方式，所以就去 Google 吧
- ****Scrum 规定了经过优先级排序的产品 backlog***
- Scrum 规定了每日立会
- Scrum 规定了燃尽图
敏捷宣言
我们一直在实践中探寻更好的软件开发方法，
身体力行的同时也帮助他人。由此我们建立了如下价值观：
个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划
也就是说，尽管右项有其价值，
我们更重视左项的价值。
