看板和Scrum-相得益彰-读书笔记

第一部分 二者对比

第1章 究竟什么是Scrum，什么是看板？

1. Scrum简述。P2
   • 把组织拆分成小规模的、跨功能的自组织团队。
   • 把工作拆分成一系列小而具体的交付物。按优先级排序，估算每项任务的相对工作量。
   • 把时间拆分成固定大小的段迭代（通常为1-4周），每个迭代结束时对基本可以交付的代码进行演示。
   • 在每个迭代结束后跟客户一起检查发布目标，并据此优化发布计划，更新任务优先级。
   • 每个迭代结束后进行回顾，进行过程优化。
2. 我们不是一个靠一个庞大的团队，花大量时间造出庞然大物；而是用小团队在短时间内做出小块的东西来，在有规律的集成中组装出全貌。P3
3. 看板简述。P3
   • 将流程可视化。
     • 把工作拆分成小块，一张卡片写一件任务，再把卡片放到墙上。
     • 每一列都起一个名字，显示每件任务在流程中处于什么位置。
   • 限制WIP（在制品，work in progress）——明确限制流程中每个状态上最多同时进行的任务数。
   • 度量生产周期（完成一件任务的平均时间，又称循环周期），对流程进行调优，尽可能缩短生产周期，并使其可预测。

第2章 Scrum和看板有什么关系？

1. Scrum和看板都是过程工具。P5
   工具=用于完成任务或达成目的的任何东西。
   过程=工作方式。
   Scrum和看板都是过程工具，它们讲的是做哪些事情能够在一定程度上帮助你提高工作效率。
2. 在比较工具的时候得谨慎一些。比较是为了更好地理解，而不是评判优劣。P5
3. 跟所有的工具一样，Scrum和看板既不完美，也不全面。它们没有把需要做的事情全部告诉你，只是给了一些明确的约束和指导。比如说，Scrum的约束是固定时长的迭代和跨功能团队，看板的约束是要有可见的板，队列大小要限制。P6
4. 有意思的是，工具的价值恰恰在于它限制了你的选择。如果有一款过程工具，让你什么事情都能做，那它就没多大用了。我们管这种工具叫做“做啥都行”，或者美其名曰“做正确的事”。“做正确的事”这个过程肯定管用。它就是银弹！要是没生效，那肯定是因为你没按照这个过程工作。P6
5. 使用恰当的工具可以帮助你成功，但不能确保成功。人们很容易把项目成败跟工具成败弄混。P6
   • 有一款伟大的工具，项目可能成功。
   • 有一款差劲的工具，项目可能成功。
   • 有一款差劲的工具，项目可能失败。
   • 有一款伟大的工具，项目可能失败。
6. Scrum比看板更规范。P6
   我们可以从每个工具都有哪些规则角度来进行比较。规范性指的是“要遵守更多的规则”，适应性指的是“要遵守的规则较少”。在100%规范性的情况下，你就更笨不用动脑子了，不管做什么事情都按规则行事；而100%的适应性就意味着做什么都行，没有任何规则约束。你肯定能看出来，这两种极端都是很荒谬的。P6
7. 敏捷方法有时被称作轻量级方法，主要原因就在于它们不如传统方法那么规范。敏捷宣言的第一条就是“个体和交互胜过过程和工具”。P7
8. RUP的规范性相当强——它有30多种角色，20多种活动，70多种工件；需要学习的东西不胜枚举。当然，你肯定不会全都用上，为自己的项目选一个合适的子集就行了。但不幸的是，操作起来可是颇有难度。“唔，我们会需要配置审计决定这个工件么？我们会需要变更控制经理的角色么？还定不下来啊，最好还是先留着吧。”这可能就是为什么RUP比起敏捷方法来——例如Scrum和XP——用到最后往往令人不堪重负了。P7
9. XP（极限编程）比Scrum又规范一些。它囊括了Scrum的大部分内容，还多了很多相当具体的工程实践，。例如测试驱动开发和结对编程。P7
10. Scrum的规范性比XP弱，因为它没有规定任何具体的工程实践。但它又比看板规范，因为它规定了迭代和跨功能团队之类的东西。P7
11. Scrum和RUP的主要区别在于，RUP给你的东西太多了，你得自己把不需要的东西去掉；而Scrum给你的东西太少了，你得自己把需要的东西加进来。P7
12. 看板几乎对任何做法都是开放的。它仅有的约束就是将流程可视化和限制在制品。它离做什么都行只有几步之遥，但任有令人惊异的力量。P7
13. Scrum本身已经足够浓缩了，如果你去掉一些东西，然后还叫它Scrum，那这个词就失去了意义，只会带来困扰。你可以给它起个别的名字，比如“Scrum衍生品”，或者“Scrum子集”，要不就“Scrum似是而非”也行。P8

第3章 Scrum规定了角色

1. Scrum规定了三种角色：产品负责人（描绘产品愿景，定义优先级）、团队（实现产品）、Scrum Master（消除障碍，带领过程运作）。看板没规定任何角色。这可不是说你不能或是不应该在看板里有产品负责人的角色。这只是说你不是非有不可。不管是用看板还是Scrum，你都可以根据需要增加任意角色。P9
2. 但是增加角色的时候得小心，要确保新增的角色能带来价值，而且不要跟其他方面有冲突。你觉得你真的需要项目经理么？在大项目里面也许挺好，因为这个人可以在多个团队和多个产品负责人之间进行协调。但在小团队里面这个角色也许就是浪费，甚至更糟——导致局部优化和微观管理。P9
3. Scrum和看板有一个共同的思路：“少就是多”。有疑虑的时候，先从少做起。P9

第4章 Scrum规定了固定时长的迭代

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

第5章 看板按流程状态限制WIP，Scrum按迭代限制WIP

1. Scrum的WIP按单位时间限制，看板的WIP按流程状态限制。P13

第6章 二者都是经验主义的

1. Scrum和看板都是经验主义的产物，你用的时候需要先进行试验，然后根据自己的环境作调整。P14
   • Scrum说，你应该有跨功能团队。那团队里面应该有什么人？不知道，自己试吧。
   • Scrum说，团队选择Sprint里面放多少东西。那到底要放多少东西？不知道，自己试吧。
   • 看板说，你应该限制WIP。那到底上限是多少？不知道，自己试吧。
2. 最核心的一点就是反馈环。改变=>检查结果=>从中学习=>继续改变。一般而言，反馈环越短越好，这样可以快速调整过程。Scrum的基本反馈环就是Sprint，跟XP（极限编程）合并的话就会再多几个：P15
   • Sprint
   • 每日立会
   • 持续集成
   • 单元测试
   • 结对编程
3. 看板给你的几个很有用的实时度量指标。P15
   • 平均生产周期。每次有任务到达“Done”这一列的时候就更新数据。
   • 瓶颈。典型症状就是X列里面堆满了卡片，但是X+1列里空空如也。找找板上哪里有“气泡”吧。
     太长的反馈环会导致过程改进速度过缓。太短的反馈环会导致过程变化太快，没有时间稳定，白做无用功。

第7章 Scrum在迭代内拒绝变化

1. Scrum团队也可以允许产品负责人在sprint中期更改优先级（虽然这往往都会被当作异常情况）。看板团队也可以对修改优先级时机做限制。看板团队甚至可以使用固定期限固定承诺的迭代，就跟Scrum那样。P20

第8章 Scrum板在迭代之间重置

1. Sprint结束以后，板子就会进行清理——所有卡片全部去掉。看板图的样子几乎是一成不变的——你不需要把板子清理干净，重新开始。P21

第9章 Scrum规定了跨功能团队

1. Scrum团队是跨功能的，要完成迭代全部任务所需的技能，这个团队要全都具备。看板不强制要求跨功能团队，看板图对应的是流程，不必非得是一个团队。P22

第10章 Scrum的backlog条目必须能跟Sprint搭配的上

1. Scrum和看板都以增量开发为基础的，即将工作拆分成小块。Scrum团队只会承诺他们认为能在一个迭代里面做完的任务。如果任务太大了，一个Sprint放不下，团队跟产品负责人就会寻找方法拆分，直到能放下为止。P23
2. 看板团队努力缩短生产周期，保持顺畅流动，而这些因素会间接推动团队把任务拆分成相对较小的片段。但是看板对任务规模没有明文规定一定要在某个时间内做完。P23

第11章 Scrum规定了估算和生产率

1. 在Scrum里面，团队要对每个承诺的任务估算其相对大小，到迭代结束的时候，把每个任务的大小相加，就得到了生产率。看板没有规定速算这回事。所以如果需要作承诺的话，就得想一想怎么作预测了。有的团队用Scrum的方式作估算，度量生产率。有的把每个任务都拆分得大小相近——于是生产率就很好算了。P24

第12章 二者都允许在多个产品上并行工作

1. 如果团队再维护多个产品，就把这些产品都合并到一个列表里面。这会迫使我们把产品放在一起考虑优先级，有时候会给我们帮上很大忙。我们可以采取多种做法：P25
   • 其一，每个Sprint聚焦一个产品。
   • 其二，每个Sprint里面，两个产品的特性都要做。

第13章 二者都是既精益又敏捷

1. Scrum和看板跟精益思想和敏捷宣言里面的价值观和原则是相当吻合的。举些例子：P27
   • Scrum和看板都是拉动式计划系统，跟精益的JIT（准时化）库存管理原则是一致的。
   • Scrum和看板都基于持续的、经验主义的过程优化，这跟精益的改善原则是一致的。
   • Scrum和看板都强调响应变化胜过遵循计划（虽然看板的响应速度一般要比Scrum快），这是敏捷宣言的四项价值观之一。
2. 从某个角度来看，Scrum也不那么精益，因为它把批量任务放到固定期限的迭代里面去。但是，如果你不断缩短迭代周期，本质上就等于向看板靠拢。如果你们开始研究把迭代缩成比1星期还短，那还不如干脆把固定期限的迭代干掉了。P27

第14章 小小差异

1. Scrum规定了经过优先级排序的产品backlog。在看板里面，你可以选择任何一种定义优先级的方式。看板可以有也可以没有产品backlog，即便有的话，排不排优先级也不一定。看板图上最左边那列的用途跟Scrum产品backlog基本相同。不管这列排不排优先级，团队总要做出某种决定，先拉哪张卡片来做。比如：P28
   • 总是选最上面那张。
   • 总是选最早的那张（所以每张卡都有时间戳）。
   • 随便选。
   • 花大概20%的时间做维护的任务，80%的时间做新特性。
   • 把团队的生产力平均分配到产品A和产品B上。
   • 如果有红色卡片就先选红的。
2. Scrum规定了每日立会。看板没有规定每日立会，但绝大多数看板团队好像也都在这样做。P29
3. Scrum规定了燃尽图用作跟踪迭代进度的主要工具。看板没有要求任何特殊的图表。P29

第15章 Scrum板 vs. 看板图——一个不大不小的例子

1. 看板只规定了两件事，一个是工作流必须可见，另一个是WIP要有上线。它的目的是在系统中制造无障碍的流动，尽可能缩短生产周期。P37

第16章 小结——Scrum vs. 看板

1. 相似性。P38
   • 都是既精益又敏捷。
   • 都是拉动式计划。
   • 都限制了WIP。
   • 都以透明的方式驱动过程改进。
   • 都关注于尽早交付、频繁交付可发布的软件。
   • 根基都是自组织型团队。
   • 都需要把工作拆分。
   • 发布计划都是根据经验数据（生产率/生产周期）不断优化的。
2. 差异。P38
   • Scrum规定了固定时长的迭代，看板固定时长的迭代是可选的。计划、发布、过程改进等活动可以各有各的节奏。它可以由事件驱动，不用非要固定时长。
   • Scrum团队承诺当前迭代做完一定量的工作。看板承诺是可选的。
   • Scrum用生产率作为计划和过程改进的默认度量手段。看板用生产周期作为计划和过程改进的默认度量手段。
   • Scrum规定了跨功能团队。看板跨功能团队是可选的。可以有专职团队。
   • Scrum任务必须分解，以便在1一个Sprint里面能做完。看板没有规定任务规模。
   • Scrum规定了燃尽图。看板没规定专门的图表形式。
   • Scrum间接限制（每个Sprint的）WIP。看板直接限制（每个工作流状态的）WIP。
   • Scrum规定了估算。看板估算是可选的。
   • Scrum不能往进行中的Sprint里面加认为。看板只要有人富余就可以加任务。
   • Scrum一个Sprint Backlog归一个团队所有。看板一张看板图可以由多个团队或多个公用。
   • Scrum规定了三种角色（PO、SM、Team）。看板没有规定任何角色。
   • Scrum每个Sprint之间重置Scrum板。看板看板图一直保留着。
   • Scrum规定了经过优先级排序的产品backlog。看板优先级排序是可选的。

第二部分 案例分析

第17章 技术支持的现状

1. 缩小问题范围，减少影响，保存现场，等到某人把问题重现后再解决。P41

第18章 到底为什么要改变？

1. 我们不能只帮助开发团队，否则技术支撑团队那边的核心运营设施改进工作就会拖了后腿。两手都要抓。改进工作在开发团队中取得进展以后，管理者就需要把更多的时间投入到创意的分析和反馈，这也意味着他们用来解决问题，及时划分任务优先级的时间就更少了。管理团队意识到，他们得再管理混乱到无可救药之前采取行动了。P42