《看板方法-科技企业渐进变革成功之道》书摘笔记【第3章】
第3章 一种成功秘诀
Ø 秘诀中包含的六个步骤如下：
1. 专注于质量；
2. 减少进行中的工作（work-in-progress）；
3. 频繁交付；
4. 根据交付速率来平衡需求（demand）请求量；
5. 进行优先级排序；
6. 消除变异性的根源，提升可预测性。
3.1 使用秘诀
Ø 业务管理人员没能承担起工作优先级排序责任，而把排序扔给技术经理来做，然后反过来又责备技术经理做出糟糕的选择，这样的事情也相当常见。
笔记：需求接到后的第一个问题，这个需求的优先级是什么？
Ø 最好把消除变异性留在后面，等前面的步骤成功实施且组织氛围有所改变之后再行实施。因为要求人们改变行为是很困难的。
Ø 为了促成那些先期步骤的成功实施，有时候需要先消除一些变异性的根源。其中的诀窍在于，要挑选那些几乎不需要行为改变而能为人们所欣然接受的变异性根源，须从它们开始入手。
Ø 能与其他团队建立相互的信任，可使很多艰难的改进成为可能。
Ø 构建和提交缺陷很少的高质量代码，能够增进彼此的信任。
Ø 通过有规律的构建活动来发布高质量的代码，也可以增加更多的信任。
Ø “消除变异性的根源，提升可预测性”是很难的一步。在一个团队变得更为成熟和效能水平提升到某种水平之前，都不应该进入这一步中。秘诀中的前四步，都能产生显著的影响。实施这些步骤，能够为一名新任经理带来成功。但是，要真正形成一种具有创新和持续改进的文化氛围，就必须在过程中不断消除变异性的根源。
A. 专注于质量
Ø 代码检查能够提高质量。无论是结对编程、同行评审、代码走查，或者完整的费根式检查（Fagan inspections），进行代码检查都是很有效的。代码检查能够帮助改善外部的代码质量和内部的代码质量。代码检查最好经常做，并且以小批量进行为好。我建议团队成员每天至少花 30 分钟进行代码检查。
Ø 协作式的分析和设计，能够提高质量。团队一起分析问题和设计解决方案，产出的质量会更高。我建议团队成员召开协作式的分析与设计建模会议。设计建模会议应该以小批量的方式每天进行。
Ø 使用设计模式（design patterns）能够提高质量。设计模式总结了对已知问题的已知解决方案。使用设计模式能够确保更早地获取更多的信息，使设计缺陷在软件生命周期的早期就得以消除。
Ø 使用现代开发工具也能够提高质量。许多现代开发工具都包括静态代码分析和动态代码分析的功能。对每个项目，应该把代码分析的开关打开，不断进行代码优化。这些分析工具，可以防止程序员犯低级错误，如安全漏洞这类众所周知的问题。
Ø 减少进行中的设计（design-in-progress）的数量，能够提升软件质量。
B. 减少进行中的工作并频繁交付
Ø 交付周期（Lead Time）是指从订货到交货的时间。这个比前置时间的翻译更好。
笔记：现在的团队缺陷过多，与一个周期在制品数量过多有直接关系。这点需要谨记！
Ø 在制品数量和平均前置时间之间存在相关性，而且是线性相关。前置时间和质量之间存在相关性，前置时间增加，则质量会下降。前置时间越长，质量越会显著下降。
Ø 提高质量的管理杠杆点（leverage point）是减少在制品数量。
Ø 随着在制品数量的增加，缺陷数量会不成比例地增加。
Ø 仅需使用看板系统来限制在制品数量便可提升质量，这种做法更有道理。如果已经知道管理好在制品数量能够提高产品质量，那么为什么不引入明确的规则来限制在制品数量。
笔记：要有明确的在制品数量控制。
Ø 一个成员能力参差不齐的团队也能够产出世界一流的成果。
笔记：要对自己的团队有信心！
频繁发布能够建立起信任
Ø 频繁地发布代码，能够与外部团队，尤其是与市场营销团队或业务方之间建立信任。
Ø 小规模的发布表明，软件开发团队具有交付能力，并能够一直致力于产出价值。
隐性知识
Ø 随着进行中工作项数量的增加，问题的复杂性也会呈指数级增加在软件开发中。
Ø 有很多的知识迁移（knowledge transfer）和信息发现（informationdiscovery）活动，它们是隐性的，而且都是在面对面的协作过程中发生的。
Ø 团队成员在一起工作并互相帮助，通过讨论或利用群体的共享记忆（shared memory），就可以解决隐性知识记忆丢失（memoryloss）的问题。
Ø 如果减少进行中的工作项，则能减少隐性知识的遗忘，从而获得更高质量的产品。
Ø 减少进行中的工作项，能够提高产品质量，并促进更为频繁的发布。更为频繁地发布更高质量的代码，则能增进与外部团队之间的信任。
C. 根据交付速率来平衡需求请求量
Ø 根据交付速率来平衡需求请求量，意味着要根据交付可工作代码的速率，来设置新需求进入软件开发管道的速率。这样便可有效地将进行中工作项的数量固定在某个值。在有工作项交付后，便会从需求提请者那里拉入新的工作项（或需求）。因此，任何对新工作的优先级排序，只可能在现有工作项被交付的情境下才发生。
Ø 根据交付速率来平衡进入的需求请求量，在价值流中限制在制品，只有瓶颈资源才会保持满负荷的状况。很快，处于价值流中其他环节的员工都会发现，他们有了富余能力（slack capacity）。同时，那些在瓶颈处的员工的工作会很忙，但不会过载且会被掩盖。
产生富余时间
Ø 想要进行持续改善，就要具备富余时间。为了产生富余时间，要做到根据交付速率来平衡需求请求量，限制在制品的数量。
Ø 为了能够得到持续改善，需要具备富余时间。为了具备富余时间，就必须允许价值流保持不平衡，允许有一项瓶颈资源存在。以提高资源利用率为目的的优化，是不可取的。
优先级排序
Ø 如果秘诀中的前三步都已经实施，那么整体应该运行得比较顺畅，应该能够做到频繁发布高品质的代码。随着在制品数量被约束，开发前置时间应该也会缩短。只有当现有工作完成、产能被释放出来时，才能将新工作拉入开发流中。这时，管理重心应该转向优先级排序，而不仅仅只是交付的代码数量。当交付方面尚缺乏可预测性时，很少有人会去关注优先级排序的问题。当需求的交付次序不可靠时，为什么要浪费精力去排定它们的输入次序呢？在解决这个问题之前，最好将管理精力重点用于改善交付能力和交付的可预测性上。
Ø 一旦能够真正做到按照需求请求的大致次序交付需求，就应该把思考转向如何对输入的需求进行优先级排序。
Ø 这是因为已交付的业务价值才是真正成功的衡量标准。
循序渐进地构建成熟度一个团队应该这样逐步迈向成熟。
1. 要学习构建高质量的代码。
2. 减少进行中的工作项数量，缩短前置时间，并频繁发布。
3. 根据交付速率来平衡需求请求量，对在制品设置限额，进而产生富余时间并释放个体的创造力（free up bandwidth） ，促进改善行为的发生。
4. 随着软件开发的顺畅运转和能力优化，通过改善优先级排序来优化交付的价值。期望一步实现优化业务价值，只是一种不切实际的美好愿望。遵循成功的秘诀（the recipe for success）并采取行动，才能逐步达到期望的成熟度水平。
D. 消除变异性的根源，提升可预测性
Ø 为了降低软件开发中的变异性，知识工作者需要改变他们的工作方式，学习新的技术，并改变他们的个体行为。所有这一切都很困难。变异性会导致更多的在制品及更长的前置时间。变异性要求非瓶颈资源具有更多的富余时间，以应对工作流中的波动，而富余时间又影响流经价值流中的工作流负载量。
3.2 成功秘诀和看板方法
3.3 总结
Ø 看板方法包含了成功秘诀的所有方面。
Ø 成功秘诀解释了看板方法为什么具有价值。
Ø 质量低下是软件开发中最大的浪费。
Ø 减少在制品即进行中的工作项数量，能够提高产品质量。
Ø 提高质量能够增进与下游合作伙伴如运维部门等之间的信任。
Ø 频繁发布能够增进与上游合作伙伴如市场营销部门等之间的信任。
Ø 可以通过拉动系统，根据交付速率来平衡需求请求量。
Ø 拉动系统能够暴露瓶颈所在，并在非瓶颈处产生富余时间。
Ø 对于运作良好的软件开发价值链，高质量的优先级排序活动能够使交付的价值最大化。
Ø 如果没有良好的初始质量，交付上也缺乏可预测性，那么优先级排序几乎毫无价值。
Ø 为了降低变异性而进行的改变，需要富余时间。
Ø 降低变异性能够减少对富余时间的需要。
Ø 降低变异性有利于实现资源平衡（并潜在地降低对人数的需求）。
Ø 降低变异性能够降低对资源的需求。
Ø 降低变异性能够减少看板令牌（kanban tokens）、减少在制品数量，最终体现为平均前置时间下降。
Ø 富余时间能够使更多的改进机会成为可能。
Ø 过程改进能够带来更高的生产率和更好的可预测性。
版权归原作者所有，此为整理集合