看板方法-科技企业渐进变革成功之道-读书笔记

第一部分 导论

第1章 解决敏捷管理者的困境

1. “大型软件开发是一场马拉松，不是短跑冲刺”。如果要求项目成员在18个月之久的长期项目中保持步调，那么绝不能让他们在头一两个月就精疲力竭。必须为项目制定计划、预算成本、进行调度和估算，以确保团队成员每天合理的工作时间，避免他们过度疲劳。作为经理的我，所面临的挑战是，在实现这一目标的同时，还能能够确保满足所有的业务需求。P4
2. 一个过程需要根据每种具体情况进行适配调整。要做到这一点，需要每个团队拥有积极的领导者，而这点往往是团队所缺乏的。即使有了正确的领导者，如果没有框架指引裁剪过程来适应不同的环境，我依然怀疑能否发生什么重大的有益变革。如果领导者、教练或过程改进工程师缺乏这种引导，就很可能会基于自己盲目的信仰，主观地将变化强加给团队。这与因强行施加不适宜的流程模板而招致更大的愤怒和反对，是同样的道理。P5
3. 艾利·高德拉特提出的方法。该方法的主旨是：识别并设法减少瓶颈因素，知道瓶颈因素不再对效能产生约束；消除一个瓶颈之后，又会涌现出另外一个新的瓶颈，如此循环不已。这种方法以迭代方式，通过识别和消除瓶颈，系统性地提升效能。P6
4. 我认识到，可以将这项技术（通过迭代方式识别和消除瓶颈，系统性地提升效能）和精益方法中的一些理念合成在一起。首先以价值流（value stream）对软件开发生命周期的工作流程进行建模，然后建立一个可视化跟踪系统，此后，当新工作“流”经该系统时，通过跟踪其状态的变化，便可识别出瓶颈。在约束理论的基本模型中，具备识别瓶颈的能力是第一步。P7
5. 看板（kan-ban）是一个日语词汇，英文字面意思是“信号卡”。在生产制造环境中，这种卡片作为一种信号，通知生产过程中的上游工序继续生产。在这种生产过程中，除非从下游工序中获得看板信号，否则每个工序中的工人不准进行额外生产。除非从下游工序中获得看板信号，否则每个工序的工人不准进行额外的生产。P7
6. 丰田生产方式（Toyota Production System）的创建者之一大野耐一（Taiichi Ohno）曾经说过：“丰田生产方式的两大支柱，是及时生产（just-in-time）和有人工介入的自动化（autonomation）。驱动这个系统运转的工具，便是看板。”换言之，看板是丰田公司所使用的改善（kaizen，持续改进）的过程的基础。P8
7. Corbis公司实施一个看板拉动系统。包括可视化工作流程、工作项类型、节奏、服务类别、专门的管理报告和运营回顾等，共同定义了看板方法。P8
8. 在许多方面，知识性工作是和重复性的生产活动对立的。软件开发和制造业之间的差异在很多方面都便显出很大的不同。制造业具有低变异性（variability）；而软件开发极其易变，它利用变异性，通过设计上的创新来产生价值。软件天然是“软”的，一般能够很容易地以低成本进行变化，而制造业则围绕着很难变化的“硬”件开展工作。P10
9. 总结。P11
   • 看板系统来自一系列称为拉动系统的实践方法。
   • 埃利亚胡·高德拉特的“鼓-缓冲-绳”作为约束理论的一种应用，是拉动系统的实施方法之一。
   • 我之所以探索拉动系统，来自两方面的动机：一方面是寻找一种系统性的途径，使团队在工作中实现可持续的步调；另一方面是寻找一种方法，能够以最小的阻力引入过程变革。
   • 看板是丰田生产方式及其改善方法的支撑机制，能够带来持续改进。
   • 第一个虚拟的软件工程看板系统，是从2004年开始在微软公司实施的。
   • 从早期的看板实施来看，结果令人鼓舞。看板确实可以实现可持续步调，通过渐进增量的方式，最大限度地降低变革阻力，并产生显著的经济效益。
   • 作为一种变革技术的看板方法，自2007年8月在华盛顿特区召开的2007年敏捷大会展示之后，开始广受社区关注。
   • 在本书中，看板（kanban）（小写字母“k”开头）指的是信号卡，看板系统（kanban system）（小写字母“k”开头）指的是使用（虚拟）信号卡实施的拉动系统。
   • 看板（Kanban）（大写字母“K”开头）方法指的是自2006-2008年间在Corbis公司涌现的渐进增量式的过程改进方法学。这些年来，看板方法在更为广泛的精益软件开发社区中得到了持续深入的发展。

第2章 什么是看板方法

1. 看板（或卡片）的数量，等价于系统设置（核定）的流通能力。一张卡片与一个工作项关联。每张卡片都充当一种信号机制。这种机制就是所谓的拉动系统（pull system），这是因为系统只有具备了处理的能力才能拉入新工作项，而不是基于需求将工作项推入系统中。由于流通中的信号卡数量表征了系统能力，所以只要恰当地设置能力阈值，拉动系统就不会出现过载（overloaded）现象。P15
2. 卡片墙本身并不是看板系统。它们仅仅是可视化控制系统（visual control system）。它们让团队以可视化的方式观察在制品并进行自组织（self-organize），无需项目经理或产品经理的指令，便可自行分派任务，将工作从待办列表中移向完成状态。但是，如果其中并没有明确在制品数量，也不能在系统中发送信号拉动新工作项，那么这个系统并不能算是一个看板系统。P16
3. 看板能迅速暴露那些影响效能的问题，因此，目前团队所面临的挑战是专注于解决问题以维持稳定的工作流。看板为质量和过程中出现的问题提供了可见性，使得缺陷、瓶颈、变异性以及经济成本等因素对流动与交付速率的影响变得更明显。单就使用看板来限制在制品工作项这一做法，就能促成更高的质量和更高的效能。流程改进和更好的质量结合在一起，有助于缩短前置时间（lead time），提高可预测性和准时交付能力。通过建立稳定的发布节奏，实现始终如一的可靠交付，看板能帮助团队与客户、依赖的相关部门、供应商、价值流下游合作伙伴建立信任关系。P16
4. 看板有助于实现组织文化的演进。通过暴露问题，引导组织聚焦于解决这些问题并消除其对未来的影响，看板能促进高度协作、高度信任、高度授权和持续改进的组织文化的形成。事实表明，通过定期、可信赖、高质量地发布有价值的软件，看板能够提升客户满意度、事实还表明，看板能够提高生产率、质量，缩短前置时间。此外，有证据显示，在演进式文化变革中将涌现出更为敏捷的组织，看板在其中起到了关键的催化剂作用。P17
5. 看板5项核心特性。P17
   • 可视化工作流。
   • 限制进行中的工作（work-in-progress）。
   • 度量和管理流动。
   • 明确过程策略。
   • 使用模型来识别改进机会。
6. 看板方法还有5个附加的特性。P18
   • 根据延迟（机会）成本进行工作项的优先级排序。
   • 通过服务分类来优化价值。
   • 通过产能分配（capacity allocation）来管理风险。
   • 鼓励工艺和过程创新。
   • 定量化管理。
7. 看板并不是一种软件开发生命周期的方法学，也不是一种项目管理的方法。P18
8. 一些公司已经发布了敏捷成熟度模型（agile maturity models），以设法评估实践的采纳状况。这些基于实践的评估方法的设计，旨在推动一致性和遵循度，而否认根据具体情境进行适应变化的需求。看板方法则允许市场忽略这些基于实践的评估方案，它鼓励多样性（diversity）。P19
9. 每个看板当然会不一样，每个团队的情况不同。他们必须演化过程，以适应自己的具体情境。但我知道，这些过程均派生自同样的原则，由于团队成员都理解这些基本的原则，因此，即使将它们从一个团队转派到另外一个团队，他们也能够适应性地进行调整。看板授予了人们保持与众不同的权利：你的团队可以不同于同一楼层的团队，可以不同于隔壁楼层的团队，可以不同于旁边建筑里的团队，可以不同于隔壁公司里的团队。看板也授予了人们不死守教科书里哪些条条框框的权利。看板方法最大的好处是，提供了一种工具，让我们可以解释（和辩护）为什么与众不同更好，为什么那种情境下某种与众不同的选择才是正确的选择。P19
10. 总结。P20
    • 任何情况下，都可以使用看板来限制系统内的某些事物的数量。
    • 东京皇居东御苑公园使用了看板系统来控制公园的游客数量。
    • 可供流通的“看板”信号卡数量为在制品（进行中的工作项）设置了限额。
    • 当前工作项或任务完成时，信号卡便被收回，用于将新的工作项拉入流程中。
    • 在IT工作中，由于没有实际的物理卡片用于传递和定义在制品限额，所以我们（通常）使用虚拟的看板系统。
    • 在敏捷软件开发中，常见的卡片墙并不是看板系统。
    • 看板系统在工作场中创建了一种积极张力，驱动大家去讨论问题。
    • 看板方法（大写字母“K”开头的“Kanban”）利用看板系统（kanban system）作为改进的催化剂。
    • 看板方法要求对过程中的规则进行明确的定义。
    • 看板使用来自不同知识领域的工具，鼓励分析问题和探索解决方案。
    • 通过不断探索发现影响过程效能的问题，看板方法可以实现增量式的过程改进。
    • 可以通过Limited WIP Society的在线站点http://www.limitedwipsociety.org/获取关于看板方法的最新定义。
    • 在软件开发行业，看板起到权限授予这（permission giver）的作用，鼓励团队根据具体情境制定过程解决方案，而不是教条式地遵循某种软件开发生命周期过程定义或模板。

第二部分 看板方法的益处

第3章 一种成功秘诀

1. 看板秘诀中包含的六个步骤如下：P24
   • 专注于质量。
   • 减少进行中的工作（work-in-progress）。
   • 频繁交付。
   • 根据交付速率来平衡需求（demand）请求量。
   • 进行优先级排序。
   • 消除变异性的根源，提升可预测性。
     沿着列表向下，到“进行优先级排序”这一步，可控制性将逐步降低，而和其他上下游群体进行合作的要求则会逐步加强。
2. 缺陷过多是软件开发中最大的浪费。团队花费超过百分之九十的精力在修复缺陷上是一种普遍现象。P25
3. 鼓励提高初始质量（initial quality），会对高缺陷率团队的生产力和交付速率产生巨大的影响。获得2~4倍的交付速率提升是很有可能的。如果团队真的很糟糕，那么通过“专注于质量”的做法，甚至都有可能获得10倍的交付速率提升。P26
4. 代码检查能够提高质量。无论是结对编程、同行评审、代码走查，或者完整的费根式检查（Fagan inspections），进行代码检查都是很有效的。代码检查能够帮助改善外部的代码质量和内部的代码质量。代码检查最好经常做，并且以小批量进行为好。我建议团队成员每天至少花30分钟进行代码检查。P26
5. 减少在制品的数量或缩短迭代的长度，将对初始质量产生重大影响。很明显，在制品数量与初始质量之间是非线性的关系，也就是说，随着在制品数量的增加，缺陷数量会不成比例地增加。为期2周的迭代比4周的迭代好是很有道理 的。为期1周的迭代会比2周的迭代更好。较短的迭代会产生更高的质量。P30
6. 频繁发布能够建立起信任。P31
   减少在制品数量能够缩短前置时间。缩短前置时间，意味着可以更为频繁地发布可用的代码。频繁地发布代码，能够与外部团队，尤其是与市场营销团队或业务方之间建立信任。信任是一种很难定义的事物。社会学家将之称为社会资本（social capital）。他们发现，信任是由事件驱动的，小而频繁的表现（gestures）或活动，较之那些大但只是偶尔发生的表现或活动而言，更能增进信任的产生。
7. 隐性知识。P32
   在软件开发中，有很多的知识迁移（knowledge transfer）和信息发现（information discovery）活动，它们是隐性的，而且都是在面对面的协作过程中发生的。虽然这些信息具备口头表述性（verbal）和可视性（visual）的特征，但它们大多以像画在白板上的草图之类的非正式形态存在。我们的大脑要全部存储这些隐性知识是不可能的，即使记住，也会很快遗忘的。我们无法记得确切的细节，并会因此犯错。随着时间的流逝，隐性知识也会不断被遗忘，因此，对于隐性知识处理活动而言，更短的前置时间是至关重要的。我们知道，减少进行中的工作项，能够直接缩短前置时间。由此可以推断，如果减少进行中的工作项，则能减少隐性知识的遗忘，从而获得更高质量的产品。P32
8. 根据交付速率来平衡需求请求量。P32
   根据交付速率来平衡需求请求量，意味着要根据交付可工作代码的速率，来设置新需求进入软件开发管道的速率。这样便可有效地将进行中工作项的数量固定在某个值。在有工作项交付后，便会从需求提请者那里拉入新的工作项（或需求）。因此，任何对新工作的优先级排序，只可能再现有工作项被交付的情境下才发生。
9. 产生富余时间。P33
   想要进行持续改善，就要具备富余时间。为了产生富余时间，要做到根据交付速率来平衡需求请求量，限制在制品的数量。消除这些富余时间，会阻碍改善文化的发展。为了能够得到持续改善，需要具备富余时间。为了具备富余时间，就必须允许价值流保持不平衡，允许有一项瓶颈资源存在。以提高资源利用率为目的的优化，是不可取的的。
10. 优先级。P34
    优先级排序本不由工程技术部门来控制，因此，也不应由工程技术管理层所掌控。要改进优先级排序，需要产品负责人、业务方或市场营销部门改变他们的行为。最好的情况下，工程技术管理层也只在优先级排序上具有一定的影响力。
11. 循序渐进地构建成熟度。P34
    我认为，一个团队应该这样逐步迈向成熟。第一，要学习构建高质量的代码。第二，减少进行中的工作项数量，缩短前置时间，并频繁发布。第三，根据交付速率来平衡需求请求量，对在制品设置限额，进而产生富余时间并释放个体的创造力（free up bandwidth）,促进改善行为的发生。第四，随着软件开发的顺畅运转和能力优化，通过改善优先级排序来优化交付的价值。
12. 为了降低软件开发中的变异性，知识工作者需要改变他们的工作方式，学习新的技术，并改变他们的个体行为。P35
13. 总结。P36
    • 看板方法包含了成功秘诀的所有方面。
    • 成功秘诀解释了看板方法为什么具有价值。
    • 质量低下是软件开发中最大的浪费。
    • 减少在制品即进行中的工作项数量，能够提高产品质量。
    • 提高质量能够增加与下游合作伙伴如运维部门等之间的信任。
    • 频繁发布能够增进与上游合作伙伴如市场营销部门等之间的信任。
    • 可以通过拉动系统，根据交付速率来平衡需求请求量。
    • 拉动系统能够暴露瓶颈所在，并在非瓶颈处产生富余时间。
    • 对于运作良好的软件开发价值链，高质量的优先级排序活动能够使交付的价值最大化。
    • 如果没有良好的初始质量，交付上也缺乏可预测性，那么优先级排序几乎毫无价值。
    • 为了降低变异性而进行的改变，需要富余时间。
    • 降低变异性能够减少对富余时间的需要。
    • 降低变异性能够减少对富余时间的需要。
    • 降低变异性有利于实现资源平衡（并潜在地降低对人数的需求）。
    • 降低变异性能够降低对资源的需求。
    • 降低变异性能够减少看板令牌（kanban tokens）、减少在制品数量，最终体现为平均前置时间下降。
    • 富余时间能够使更多的改进机会成为可能。
    • 过程改进能够带来更高的生产率和更好的可预测性。

第4章 在五个季度内，从最差变为最好

1. 可视化工作流程。画一幅简图来描述变更请求处理的生命周期过程。P38
2. 估算是一种浪费。P41
   首先，团队将停止估算活动。他想回收浪费在估算活动中的产能，将之用于软件开发和测试工作。消除因估算导致的计划紊乱现象，也能提高可预测性，他希望这两者结合在一起后，能够对客户满意度产生重大影响。
3. 限制在制品。P41
   选择将在制品限定在1名开发人员对应1个请求项的水平上，对于测试人员也采用类似的规则。
4. 在每一时刻都保持每位开发人员只对应一个变更请求的状态。这就是一种策略选择。此后仍然可以 对这一策略进行修改。将过程视为一组策略的集合，是看板方法的一个关键点。P41
5. 建立输入节奏。P42
   在看板方法中，节奏指的是某种活动发生的间隔周期规律。优先级排序、交付、回顾，以及其他任何循环往复发生的活动，都可以采用特定的不一样的节奏。
6. 达成新契约。P43
   他期望产品经理接受这样的方案：每周会面一次讨论优先级排序，而他会对在制品进行限制，并且团队不再进行估算活动。作为交换，他将确保交付期在25天之内，并且以此作为度量标准，报告准时交付的达成情况（due-date performance）。
7. 调整策略。P44
   明确的策略、透明性和可视化这三者结合在一起，使授权团队成员自己进行决策和管理风险的做法成为可能。当管理层能够理解“过程是由各种策略构成”的时候，他们便会相信系统运行的有效性。这些策略的设计意图，便是管理风险和交付客户所期望的价值。策略明确，团队工作可透明跟踪，所有团队成员就能理解和知道如何使用这些策略。
8. 总结。P49
   • 第一个看板系统始于2004年，最早是在微软的XIT软件维护团队中实施。
   • 第一个看板系统中使用了电子化的跟踪工具。
   • 第一个看板系统是在微软公司的一家离岸外包供应商团队中实施的，该供应商具有CMMI5级资质，该团队再印度的海德拉巴办公。
   • 应该将工作流绘制出来，以可视化的形式呈现工作流。
   • 应该通过一组明确定义的策略来描述过程。
   • 看板方法能够促成增量式的变革。
   • 看板方法能够降低变革中的政治风险。
   • 看板方法能够最小化变革过程中遭遇的阻力。
   • 使用看板方法，能够发现改善的机会，而且其中不会涉及复杂的工程方法变更。
   • 第一个看板系统的实施，在生产率上有老超过200%的提升，前置时间减少了90%，在可预测性上有了大幅提升。
   • 通过管理瓶颈、消除浪费和降低那些影响客户期望值与满意度的变异性，产生显著改善是很有可能的。
   • 变革需要经历一段时间才能充分展现效果。第一个看板实施案例在15个月才完全显现成效。

第5章 持续改进的文化

1. 改善文化。P52
   在改善文化中，员工可以获得极大的授权。个体具有行动上的自由，能够自由地去做正确的事。员工会自发地聚在一起攻克难题，讨论各种可能方案，并进行修复和改善。在改善文化中，员工不会再有恐惧感。在改善文化中，管理的基本标准是，如果实验和创新是出于改善过程和提升效能的目的，就要能够承受其可能的失败。在盖上文化中，个体能够围绕手头的工作和方法，自由地（在某些限制条件内）进行自组织。整个过程清晰可控，工作任务一般是由员工自愿选择完成，而不是由上级指派。在改善文化中，一起去探索如何提升业务的整体效能。在改善文化中，团队进行局部改善时，同事也会专注于系统层面，致力于提高整体的效能。
2. 看板方法会加速组织成熟度和能力的提升。P53
   开始实施看板方法，要先从寻求优化现有流程和改善组织文化入手，而不要抛弃现有流程转向也许会带来巨大经济效益的其他流程。这会招致一些批评，认为看板方法只是优化了一些需要改变的事物。但是，现在有重要的证据表明，在和兴的高度成熟度过程领域，如根因分析和解决（causal nanlysis and resolution, CAR）、组织创新和部署（organizaitonal innovation and deployment, OID）等方面，看板方法能够促进组织成熟度和能力的加速提升。
3. 看板方法不但提供了工作上的透明度，还提供了过程（或工作流）上的透明度。通过展示工作是如何从一个小组传递到另一个小组，看板为团队带来了一种可见性。看板方法使得每一个干系人都能看到他们积极行动或者消极怠惰所产生的影响。如果一个工作项受阻，而有人有能力对阻塞进行疏导，那么看板会显示这一点。P57
4. 除了过程流动上的可见性，限制在制品也能够驱动大家更快捷、更频繁地进行富有挑战性的互动。团队成员很难对一个受阻工作项视而不见、自顾自地继续做其他事情。看板方法的停止生产线（stop the line）机制，能够鼓励整个价值流中的人员产生群策群力、攻克难题的行为。P58
5. 总结。P62
   • kaizen的意思是“持续改善”。
   • 在持续改善的文化中，每个个体都有充分的授权感，能够毫不畏惧地行动，自动自发进行协作和创新。
   • 在持续改善的文化中，无论成员身处组织结构中的哪个级别，彼此间都具备高度的社会资本和信任度。
   • 工作在流行中流董，看板方法则同时为工作和流程提供了透明性。
   • 过程的透明性使得所有干系人都能看到自己作为或不作为时所产生的影响。
   • 当能够看到自己的影响效果时，个体会变得更乐于贡献时间和进行协作。
   • 看板方法中对在制品设限的做法，能够使停止生产线（stop the line）的行为变为可能。
   • 看板方法中对在制品设限的做法，鼓励集思广益共同解决问题。
   • 通过共同解决问题和与外部利益相关者开展合作，团队的协作性得到了提升，最终提升了团队的社会资本水平和团队成员之间的信任程度。
   • 看板方法中对在制品设限及服务分类的做法，能够授权个体主动拉动工作，进行优先级排序和计划调度策略，而无需管理人员进行监管。
   • 授权水平的提升能够增加社会资本以及员工与管理人员之间的信任程度。
   • 协作行为能够以病毒传播的方式扩散。
   • 个体会跟随资深领导者。资深领导者之间的共担与协作行为，将影响全体员工的行为。

第三部分 实施看板方法

第6章 价值流映射

1. 启动看板方法的关键要义是，变化要越少越好。你必须要抵制住改变工作流程、职位名称、角色及其职责，以及当前在用的具体实践的诱惑。不要试图去改变团队成员与其他合作伙伴、参与者、干系人的内驱力、专业自豪感和自我心理（ego），主要要噶变的是在制品的数量、与上下游业务间的接口及交互方式。因此，必须与团队一起把现有的价值流图描绘出来，不要试图去改变它或重新发明一种理想化的新过程。P65
2. 定义控制起点和终点。P66
   有必要确定哪里是进行过程可视化的起点和终点，并且，这样做时，要定义好和上下游合作伙伴的接口位置。
3. 工作项类型。P66
   一旦选定工作流或价值流的起点，下一步要做的就是识别那些到达该点的工作项类型，以及其他已在工作流中并且需要对之进行限制的工作。在采纳看板方法的团队中，已经发现的典型工作项类型包括但不限于以下所列。
   • 需求（requirement）。
   • 功能特性（feature）。
   • 用户故事（user story）。
   • 用例（use case）。
   • 变更请求（change request）。
   • 产品缺陷（production defect）。
   • 维护工作（maintenance）。
   • 重构（refactoring）。
   • 错误（bug）。
   • 改进建议（improvement suggestion）。
   • 受阻问题（blocking issue）。
4. 绘制卡片墙。P66
   卡片墙通常是用来呈现针对工作项所进行的活动，而不是用来描述特定的职能或职务的活动。是对工作项建模，而不是对工作者、职能或不同职能部分间的工作切换建模，这已经成为软件项目中使用看板的惯例做法。在绘制卡片墙对工作流进行可视化之前，先画一个草图对工作流进行建模会很有帮助。
   • 输入队列。
   • 分析。
   • 开发。
   • 测试。
   • 就绪。
   • 已发布。
5. 总结。P79
   • 确定看板管理的实施范围，划清外部边界。最好只在自己的职务权利范围内实施看板。不要强迫任何没有意愿进行协作的部门实施可视化管理、提供透明度和设置在制品限额。
   • 根据外部边界选择的决定，建立卡片墙模型，设置在制品限额，使工作可视化。
   • 定义工作项类型，建立工作流动的模型。有些类型的工作也许不需要走完流上的每一个步骤。
   • 设计工作项卡片，使其拥有充足的信息，引导团队以自组织的方式拉动工作项，便于团队成员根据工作项类型、服务水平协议和服务类别综合呈现的风险状况，做出高质量的决策。
   • 如果团队成员分布于多处，或者如果允许员工在家工作等，以及渴望通过电子化系统提供的定量信息来引领更高级更成熟的行为发生，那么需要使用电子跟踪系统。
   • 根据情况采用合适的方法来处理并行活动，选择合适方法为之建立模型，并实现可视化。
   • 根据情况采用合适的方法来处理无需遵循特定顺序的活动，选择合适方法为之建立模型，并实现可视化。

第7章 使用看板进行协调

1. 高成熟度的组织，会制定一份检查列表或一个框架，以更便捷地规划发布。其中要考虑的事情如下。P87
   • 系统中哪些工作项已经（或即将）做好发布准备？
   • 将每个工作项发布到生产环境中还需要做哪些工作？
   • 发布后，需要进行哪些测试来验证生产环境系统的一致性？
   • 其中有哪些风险？
   • 如何缓和与规避这些风险？
   • 需要有哪些应急计划？
   • 在这次发布中需要哪些人参与？将系统推向生产环境（或执行其他部署机制）时，需要哪些人在工作现场？
   • 发布将耗时多久？
   • 还有其他哪些相关事情要筹备妥当？
2. 鉴别分类是从医学界借用的一个术语，它是指对急诊患者进行评估和分类，根据需要关注的优先级进行归类的做法。这种方法最初使用在战地医疗单位中，病人被分为三类：无法挽救，可能不久于人世；如果给予及时救治，很可能就能生存下来；即使不立即救治也能存活下来。急诊室现在使用的是类似的系统，在病人送达时先对他们进行优先级归类排序。软件开发中采纳了鉴别分类法，用于在传统软件项目的稳定化阶段对缺陷和bug进行分类处理。P88
3. 在看板方法中，如果看板系统中有工作项受阻，那么这些工作项需要被标识出来进行处理，同事创建一个对应的问题工作项（issue work item）。这些问题会一直保持在open状态，只要障碍得以移除、最初的工作项能够顺利在系统中向前流动为止。因此，审查处于open状态的问题，对改善系统中的流动性至关重要。P89
4. 总结。P92
   • 最佳实践是同时使用物理卡片墙和点子跟踪系统。
   • 使用电子跟踪系统，就可以跨多个地理位置应用看板。
   • 有多家供应商提供模拟物理卡片墙功能的电子看板产品。
   • 定期召开会议能够减少会议的协调成本，提高出席率。
   • 优先级排序和发布规划应独立完成，并应具有各自独立的节奏。
   • 每日站立会议应该用来讨论缺陷、障碍和流动性问题，它们并不一定要沿袭其他敏捷开发方法中的既定模式。
   • 每日站立会议是鼓励持续改进的文化中的重要组成部分。由于站立会议每天都把整个团队简短地聚集在一起，提供了一个所有利益想干着能哦故提出建议并讨论改善的机会。站立会议之后的时段，往往会出现一个与过程改进相关的非正式讨论。
   • 通过对待办项李彪进行定期分类梳理来缩减待办项规模，以提高优先级排序会议效率。
   • 问题管理、问题升级和问题解决是提升团队效能的核心实践，应该在团队发展的早期阶段便重视这种能力的培养。
   • 应该清晰定义问题的升级路径和规则。

第8章 建立交付节奏

1. 总结。P103
   • 交付节奏指的是交付可用软件上形成的固定频率。
   • 采用看板方法们可以将交付节奏与开发前置时间和优先级排序节奏分离开来。
   • 在尝试敏捷开发方法时，一些团队由于采用了固定时间盒迭代，遭遇了一些麻烦。
   • 交付（或发布）软件的过程中，需要对参与其中的各种不同职能的人员进行协调。这些协调活动都具有可度量的成本。
   • 交付（或发布）软件的过程中，无论是在时间还是费用上，都同样伴随着一系列事务成本。可以对这些事务成本进行测定和跟踪。
   • 可以通过将进行1次交付所需的事务成本和协调成本之和，与本次软件交付的总成本相除来计算交付效率。
   • 可以将1次发布的总成本与本次发布交付的价值进行对比，来确定交付节奏。
   • 聚集于降低事务成本和协调成本，可以提升交付效率和改善交付节奏。
   • 定期交付能够建立信任关系。
   • 设定定期交付的逾期并持续达成这种预期，是一件富有挑战性的事情。
   • 根据定期交付的节奏进行调度，能够降低协调成本。
   • 高成熟度的组织中，由于已经形成了高水平的信任文化，而且交付的事务成本和协调成本很低，实行随需或临时交付更具有意义和价值。
   • 允许加急交付（expedited delivery）请求，可能会引发1次非常规性的发布。在执行完1次特殊的非常规发布之后，要尽快回复定期发布的节奏。

第9章 建立输入节奏

1. 总结。P113
   • “优先级排序节奏”指的是达成共识的定期召开会议的时间间隔，会议中按优先级将新工作项拉入输入队列以便开发。
   • 通过将优先级排序节奏与开发前置时间及交付节奏分离的策略，看板方法移除了敏捷迭代计划协调活动中可能存在的技能障碍。
   • 对新工作请求（比如一个用户故事）进行优先级排序时，需要对来自多个不同职能部门的许多人进行协调。这些协调活动的成本是巨大的。
   • 如果为了便于做出优先级排序决策而需要对工作项进行评估，那么这表明优先级排序活动在时间和金钱方面都存在事务成本。这些成本可以被确切计算和跟踪。
   • 在优先级排序方法和确定队列输入内容的过程中所使用的策略，代表了看板方法中优先级排序这一协作性合作博弈活动的规则在软件开发领域的应用。
   • 在敏捷方法中使用的计划游戏无法扩展，相比单一产品线团队，如果要在关注面更广的大型团队中使用这些规则方法，则需要付出巨大的协调成本。
   • 视其中涉及的事务成本和协调成本而定，可以通过鼓励参与优先级排序决策的相关人员以合适频率定期召开会议，建立优先级排序节奏。
   • 可以通过极力降低优先级排序活动中的事务成本和协调成本的方法，来提高效率和提升排序节奏。
   • 频繁召开的优先级排序会议能够在组织成员间构建起信任关系。
   • 以固定频率定期召开优先级排序会议能够降低协调成本，对低成熟度的组织而言，这种策略尤其有用。
   • 对已经建立高层次的信任，而且和优先级排序决策策略先关的事务成本和协调成本都很低的高成熟度组织，可以选择随需或者临时进行优先级排序。

第10章 设置在制品限额

1. 看板方法背后有两条基础性的原则。一条原则是限制在制品的数量。另外一条原则是仅当有可用产能时才通过信号卡传递机制来拉动工作的流动。P115
2. 在选择在制品限额数值上，并没有什么魔法公式。重要的是要记住，这个数值是可以通过试验观察不断调整的。可以先选择一个数值，然后观察这个数值是否能很好地工作。如果不理想，则可以将之调高或者调低。P116
3. 总结。P123
   • 需要和价值流上下游的干系人和职能部门资深管理者对WIP限额达成一致共识。
   • 虽然可以单方面定义WIP限额，但是此后遭遇压力时要捍卫住这个限额将会十分困难。
   • 工作任务的WIP限额应该按照每个人、每个开发结对或者每个协同工作的小团队的平均工作项数量来设置。
   • 一般而言，限额数值应该设置在1~3/人（/结对/团队）范围内比较合适。
   • 输入队列的限额要保持越小越好，一般将其大小设置在足以消化工作项规模和任务工时上的变异所带来的影响就可。
   • 在瓶颈前要设置缓冲区域。
   • 缓冲区域额度越少越好，但是其大小设置要确保瓶颈资源得到充分利用，并足以维持系统中的稳定流动。
   • 所有的WIP限额都可以通过不断的试验进行调整。
   • 实施看板是一个试验性的过程。
   • 不要浪费时间视试图确定完美的WIP限额大小；只需要先设置一个差不多大小的限额，往前走，必要时对限额进行调整、观察、再调整。
   • 工作流下游的一些区域不设置WIP限额，有时也是可行的。
   • 要特别注意，不设WIP限额的工序步骤，不能成为瓶颈工序，也不能导致在交付（批量向下游交付）时引入大量的事务成本或协调成本。
   • 一旦已经建立WIP限额规则，就可以根据工作项类型来分配产能。
   • 根据工作项类型拉设置横向泳道，并为每个泳道设置WIP限额。
   • 进行产能分配时，需要对看板系统接收的不同类型工作项进行请求分析，确定各工作项类型的相对规模。

第11章 建立服务水平协议

1. 总结。P139
   • 划分服务类别为优化客户满意度提供了一种便捷方法。
   • 须依据工作项的业务影响来设置其服务类别。
   • 须对服务类别进行明晰可视的标识，如采用不同颜色的卡片或在卡片墙上划分不同的泳道等方法，来标识不同的服务类别。
   • 须针对每个服务类别定义一套管理规则。只有那些涉及较高风险的工作项，才需在其中包含诸如估算之类的高成本活动。
   • 必须对团队成员进行培训，确保他们理解各个服务类别以及相关规则。
   • 某些服务类别的规则定义中须包含目标前置时间。
   • 要监控目标前置时间的达成表现（通过“准时交付率”这个度量指标）。
   • 服务类别划分让自组织成为可能，它能给团队成员带来更多授权，并节省出更多的管理时间，使管理者可以更多专注于过程而非工作的内容本身。
   • 应用服务类别，可以改变客户的心理。
   • 如果服务类别的方法应用得当，再加上有规律的交付节奏，即使有相当一部分工作项未能按目标前置时间交付，也很少会出现客户抱怨的情况。
   • 在看板系统中要根据每个服务类别配置相应的产能。
   • 分配给各个服务类别的产能比例，要与需求情况相匹配。

第12章 度量和管理报告

1. 总结。P149
   • 使用累积流图对WIP进行跟踪，每日监控WIP限额。
   • 跟踪每个已处理完毕的工作项的前置时间，报告每种服务类别的平均前置时间和光谱分析结果。
   • 前置时间是展示业务敏捷性的一个信息指示器。
   • 对固定交付日期类工作项，要跟踪预估前置时间与实际前置时间的差异。
   • 可以将准时交付率作为展示可预测的一个信息指示器。
   • 障碍阻塞了流动，影响了前置时间和准时交付率；可以通过一幅累积流图来报告阻塞问题和受阻工作项数量，并在该累积流通上叠加一张受阻在制品图。可以使用这幅图作为信息指示器，来展示组织识别问题与快速解决问题的能力。
   • 流动效率是指前置时间与分配的工程实践两者之比。它展示的是组织处理新工作项的效率水平，可以将之作为表征业务敏捷性的第二种指示器。它也可以用于展示在不改变当前使用的工程方法前提下还有多大的改善空间。
   • 初始质量报告的是测试人员在看板系统范围内发现的缺陷数量，通过这个信息指示器，可以展示由于糟糕的初始质量所导致的产能浪费状况。
   • 破坏负载报告的是由于系统存在的一些问题所引致的工作项占比，通过这个信息指示器，可以展示一些产能浪费状况，这些产能本来可以用在开发新的增值特性上。

第13章 使用两层系统扩展看板

1. 总结。P160
   • 大型项目同样也应该遵循看板方法的核心原则。
   • 对于大型项目，WIP限额、优先级排序节奏、交付节奏和服务类别也是同样适用的技术。
   • 大型项目一般拥有层次化需求；可以使用不同的工作项类型来表示不同层次的需求。
   • 一般而言，团队会在卡片墙上跟踪需求层次结构中顶上的两层，并在两个层次上都设置WIP限额。
   • 最高层次的需求一般是面向客户市场的需求，这些需求是最小价值单位，能够单独进行发布，推向市场。
   • 第二层次的需求通常以客户和用户为中心的方式来编写，并使用类似的方式对之进行分析，将这些需求分解为具备较细的粒度，而且它们的大小规模也比较类似。
   • 通过降低看板拉动系统中的变异性，第二层次的细粒度需求能够促进看板的流动性。
   • 两层卡片墙要求对骑上跟踪的两层需求都进行可视化管理。
   • 泳道已经成为展现需求层次结构和有利于对WIP进行限制的流行方法。
   • 粗粒度的WIP可以通过泳道个数来限制。
   • 如果需要，可以在每个泳道上为细粒度的需求设置WIP限额。
   • 每个泳道分配给一个小型的跨功能团队。
   • 可以通过在一个常规的工作项卡片上贴附小标签的方式，对共享资源进行可视化管理。
   • 可以通过在工作项卡片上贴附受阻问题便签（在示例中使用的是紫色）的方式来对共享资源的非即时可用性（non-instant availability）进行可视化管理。
   • 为了全局控制，共享资源应该建立自己的看板系统。
   • 在项目组合中为共享资源建立的看板系统形成了一个网络，可以将之视为是针对软件开发自身的一种面向服务架构。

第14章 运营回顾

1. 总结。P167
   • 运营回顾应该在整个组织范围内进行。
   • 运营回顾应该专注于客观数据上的呈现和分析。
   • 每个部门都应在运营回顾会议上汇报各自的数据。
   • 演讲时要保持简短，通常应该汇报类似于第12章所述的各种度量数据和信息指示器。
   • 以财务信息开场，强调了软件工程这样 的职能部门是更大业务的一部分，也表明良好的管理是重要的。
   • 每月召开一次运营回顾会是一个合适的节奏。太过频繁会占用太多的时间，加重数据采集和会议准备的负担。频率太低则会降低回顾会的价值，有驳回顾会的设计初衷。
   • 运营回顾会应当简短，通常以2小时为宜。
   • 运营回顾会要能够提供一种反馈循环机制，驱动全公司或者事业部进行持续改善。
   • 运营回顾会能向团队成员展示管理者带来的附加价值，让他们了解高效的管理者是如何工作的。
   • 有效的运营回顾会有助于在管理者与员工之间建立相互信任 关系。
   • 外部利益干系人参与运营回顾会，有机会了解软件工程及IT团队是如何运作的，从而也能了解他们面临的问题域挑战。这有助于促进彼此间的信任与合作。
   • 除了晒成绩和展示团队的有点外，在运营回顾会上，同样也要对糟糕的数据与问题进行认真的分析讨论。
   • 在公司外部的场所召开运营回顾会，有助于参会者专注思考。
   • 在会议过程中提供食物，看起来能够提升参会者的参与积极性。
   • 高管参与运营回顾会，能够向员工传递出组织重视效能与持续改善的信息。
   • 显示对效能、还需改善及量化管理的浓厚兴趣，对在广大员工中营造改善文化有着至关重要的作用。
   • 事实表明，通过运营回顾会，能够直接提升组织成熟度。
   • 应当将改善建议梳理成管理行动计划，并在下次及后续会议的开头更新进展情况。
   • 管理者要担负起责任，贯彻落实采纳的各项改善建议。

第15章 启动看板变革

1. 看板系统的目标。P170
   • 优化现有流程。
   • 高质量交付。
   • 提升前置时间的可预测性。
   • 提升员工满意度。
   • 为改善留出富余时间。
   • 简化优先级排序。
   • 使系统设计及运作透明化。
   • 设计能够打造高成熟度组织的流程。
2. 看板实施步骤。P176
   • 与相关利益干系人就导入看板方法的一系列目标达成共识。
   • 绘制价值流图。
   • 在流程中定义某个节点，在那里你想对输入做些控制。明确该节点的上游以及上游的利益干系人。例如，是否系统控制流向设计工序的需求。产品经理则便可能是上游的利益干系人。
   • 根据从上游利益干系人处提交的请求，设置工作项类型。是否存在有些类型的工作项对时间较为敏感，而其他工作项类型对时间则没有特别要求的情况？如果有，那么相应地或许就要对这些工作项进行服务分类。
   • 分析各种类型工作项的提请特征，观察到达率和其中的变异。这些变异是季节性的还是事件驱动型的？此类请求的处理需要考虑哪些相关风险？应该按照平均请求水平还是高峰请求水平来设计看板系统？如果此类工作项的交付产生延迟或不可靠，后果将会如何？
   • 与上下游的利益干系人进行会谈，其形式可能是一次大型会议，也可能是多次小型会议。
     • 对纳入控制范围的价值流的产能分配规则进行讨论，并就WIP限额达成共识。
     • 讨论输入队列的协调机制并达成共识，例如，确定与上游合作伙伴以定期举行优先级排序会议的方式来填充输入队列。
     • 讨论发布/交付的协调机制并达成共识，例如，和下游合作伙伴约定将定期进行软件发布。
     • 或许还需要为工作请求引入服务类别的概念。
     • 就各种不同服务类别工作项的目标前置时间达成共识，即建立“服务水平协议（SLA）”。
   • 建立看板/卡片墙，对要控制的价值流区域进行跟踪。
   • 建立一个电子跟踪系统，对要控制的价值流区域进行跟踪和汇报。这是一个可选项。
   • 与团队约定每天在看板墙前召开站立会议；邀请上下游的利益干系人加入站立会议，但并不要求强制参加。
   • 约定定期召开运营回顾会议，对流程进行回顾分析；邀请上下游的利益干系人参加回顾会议，但并不要求强制参加。
   • 对团队进行看板墙、在制品限制及拉式系统的培训。其他一切都不做任何改变。职责描述保持不变，工作内容保持不变，工作转接次序保持不变，工件类型保持不变，除了要求团队成员接受WIP限额并依据服务类别进行拉式而非推式工作之外，其他所有流程均保持不变。
3. 总结。P185
   • 向组织导入看板方法至少可以实现8大目标。
   • 通过以导入阻力最小的方式进行过程改进，并以此来提升组织效能。
   • 确保进行高质量的发布/交付。
   • 通过控制在制品的数量来确保前置时间的可靠性。
   • 通过改善工作/生活之间的平衡，为团队成员创造更好的生活。
   • 根据产出平衡输入的需求，从而为系统创造赋予能力。
   • 提供一种简单的优先级排序机制，允许延迟决策（commitment delay）和开放式选择（open options）。
   • 提供能够看到改善机会的透明机制，从而使组织向更具合作性、鼓励持续改善的文化转变。
   • 努力构建一个结果可预测、业务敏捷、管理良好的流程，打造软件工程研究所（SEI）所定义的高成熟度的组织。
   • 为了和其他利益干系人达成共识，务必要明确实施目标并清洗阐明导入看板方法的益处，这一点非常重要。
   • 遵循导入看板流程的12步骤指南。
   • 看板使开发团队得以以一种新的模式与外部利益干系人和业务负责人进行谈判。这种谈判模式假设各方都期望建立长期合作关系，并愿意共同致力于提升整个体统的效能表现。
   • 邀请外部利益干系人一起参与建立看板系统基本要素的相关约定，使他们成为其中的合作者。
   • 有关WIP限额、目标前置时间、服务类别、优先级排序及交付等方面的基本约定代表着软件开发协作性博弈中的规则。
   • 让外部干系人成为这些博弈规则的共同制定者，这能促成之后的合作行为，特别是当系统面临压力时更为需要。

第四部分 继续改进

第16章 三类改进机会

1. 五步聚焦法。P191
   • 识别（identify）约束。找到价值流中的瓶颈。
   • 做出决定，以最大化利用（exploit）约束。找出瓶颈潜在的最大产出，并将之和实际现状进行对比。
   • 使系统中的其余一切部分都服从于（subbordinate）第2步中做出的决定。做出任何必要的改变，以实施第2步中做出的决定和提出的想法。这可能要求在价值流中的其他地方也要做出一些改变，以最大化地输出瓶颈处的产能。这种使瓶颈处产能输出最大化的行动称为“最大化利用瓶颈”。
   • 突破（elevate）约束。以增强产能和充分提升产出，解除当前的瓶颈，这时，系统的约束就转移到价值流的其他地方。
   • 避免惰性：识别下一个约束，重返（return）第2步。给做出的这些变化一段时间，以使这些变化稳定下来，然后在价值流中识别出新的瓶颈，并重复整个过程。这样便能打造出一个持续改进的系统。
2. 总结。P195
   • 在实施看板方法时，需要采用一些模型来识别改进机会。
   • 看板方法支持至少三种类型的持续改进方法：约束管理（移除瓶颈）、减少浪费、变异性管理（SPC和渊博知识体系）。
   • 看板方法能够用于识别瓶颈，完整实施约束理论的五步聚焦法。
   • 看板方法能够以可视化方式展示浪费的活动，有助于在软件系统、产品开发或者IT组织领域启动全面的精益变革。
   • 看板方法采纳了戴明博士的渊博知识体系和统计过程控制方法的所需要的仪表盘设施。它既可以用来驱动持续改善式的变革，也可以用来驱动六西格玛方法的变革。

第17章 瓶颈和非即时可用资源

1. 总结。P210
   • 瓶颈约束和限制了工作的流动。
   • 有两类瓶颈：能力受限瓶颈——无法完成更多的工作；非即时可用瓶颈——由于可用性的限制（但通常是可预测的）导致处理能力有限。
   • 可以使用约束莅临的五步聚焦法来管理瓶颈。
   • 增加瓶颈能力的管理举措，称为“突破举措”。
   • 一般来说，对能力受限资源采取的瓶颈突破举措，和对非即时可用资源采取的瓶颈突破举措是不同的。
   • 突破举措，可能涉及增加资源、采用自动化，或者改变策略使此前非即时可用资源转变为即时可用资源。
   • 突破举措，通常需要花费资金和时间来实施。通常认为，突破举措是在过程改进方面的战略性投资。
   • 通常情况下，过程瓶颈的效能表现，远低于其潜在能力，即其理论上的能力约束水平。
   • 通过挖掘和保护举措，瓶颈处的交付速率可以提高到其理论上可以达到的能力约束水平。
   • 通常情况下，采用保护举措需要在瓶颈前增加WIP缓冲区。对于能力受限资源或非即时可用资源，这么做都是有效的。
   • 挖掘举措通常涉及策略变更，以控制瓶颈资源的工作状况。
   • 可以将服务类别（class of services）作为一种瓶颈挖掘举措。
   • 服从举措，指的是为了能哦故达到充分挖掘或保护瓶颈资源的目的，在价值流中其他地方进行改变的举措。服从举措通常都表现为策略变更。
   • 挖掘、保护和服从举措一般都易于实施且成本较低，因为它们主要涉及的是策略变更。因此，通过充分挖掘瓶颈以最大限度地提高瓶颈的交付速率，可以视为是战术性的过程改进。
   • 尽管充分挖掘瓶颈能力具有战术特性，但是其中的收益可能是非常显著的，往往可以达到2.5倍的交付速率提升，同事前置时间还会随之下降，而且短期内也无需为此付出成本。
   • 在使用突破举措之前，首先应该考虑使用挖掘举措。
   • 实施一个战术性的瓶颈挖掘和服从举措计划时，可以从一个更长远的视角来规划战略性变革，以真正突破瓶颈约束。

第18章 精益的一种经济学模型

1. 总结。P220
   • 浪费主要可以分为以下三种抽象类别：事务成本、协调成本和破坏负载。
   • 浪费是一种隐喻。
   • 浪费这一隐喻无法为所有人所接受，因为浪费常常也是必需的，尽管它们没有带来什么额外的增值。因此，我使用一种经济学成本模型来代替浪费这一隐喻。
   • 可以通过询问“如果可以，我们愿意更多地开展这项活动吗？”的方式来判别一项活动是否真的属于浪费。如果答案是否定的，那么这项活动就是某种形式的浪费。
   • 事务成本可以分为两种类型：初始准备活动和交付清理活动。
   • 协调成本指的是那些任务分配、计划安排等活动引起的开销，或者是那些为了使两人或更多人朝同一产出目标工作所需的协调工作引起的开销。
   • 破坏负载是一种新型的增值工作，但是其中的增值是由于交付了先前没有成功交付的价值，如先前软件中的缺陷、设计或实现上的不足，从而导致客户接纳度低、没有实现预期的关键功能、服务台呼入和服务请求攀升等情况。
   • 破坏负载占用了本可用于开发创新性新功能的产能，这些新功能中包含更多的客户价值，能够带来更多的营收回报。
   • 将想法更快速地转化为可向客户交付的可用代码，能够最大化潜在价值，最小化浪费。

第19章 变异性的根源

1. 总结。P234
   • 沃尔特·休哈特于20世纪20年代开始研究工业过程的变异，W·爱德华兹·戴明、约瑟夫·杜兰和大卫·钱伯斯在20世纪中后期对该领域有了进一步发展。
   • 对变异的研究及其统计分析方法，是丰田生产方式（因此也是精益）和致力过程改进的六西格玛方法的共同核心。
   • W·爱德华兹·戴明和约瑟夫·杜兰的工作成果启发了卡内基-梅隆大学软件工程研究所的工作及能力成熟度模型（现在称为能力成熟度模型集成，或CMMI）。
   • 休哈特将变异根源分为两类：一类变异来源于过程或系统的内部，一类变异来源于过程或系统的外部。
   • 内部变异也称为机会致因变异。
   • 外部变异也称为可归因变异。
   • 在软件开发生命周期的价值链里，存在许多机会致因变异的根源。典型的例子包括工作项规模、工作项类型、服务类别、不规则紊流和返工。
   • 要列出可归因变异根源，典型的例子包括需求模糊、加急请求、环境可用性、不规则紊流、市场因素、人员因素和来自对协调活动进行调度的挑战等。
   • 对于机会致因变异，可以通过改变定义软件开发生命周期和项目管理过程的系列规则和策略来控制。
   • 对于可归因变异，可以通过利用问题管理和解决能力以及风险管理能力来应对。可以通过利用根因分析和消除能力来降低或消除可归因变异。
   • 与强大的事件驱动的风险管理结合，看板系统能够产出更好的经济效益。
   • 看板方法也提供了其他方法来管理风险，如按服务类别与工作项类型来设置WIP限额，使用风险属性来将工作分为不同类型或类别进行相应处理等。
   • 关于使用看板方法进行风险管理的相关策略措施，目前还正在研究中，在将来的一本书中将会包含该方面的主题。

第20章 问题管理和升级策略

1. 总结。P240
   • 看板系统应该包含一个第一级别的工作项、问题项，用来跟踪导致其他客户价值工作受阻的问题。
   • 在卡片墙上使用粉色（或红色）便签来可视化受阻问题，已经成为一种惯例做法。
   • 粉色的问题便签贴在受阻工作项的旁边。强大的问题管理和解决能力，对于维持流动而言是最基本的要素。
   • 受阻工作项和问题并非瓶颈。它们应该作为特别致因变异来管理，而不是作为产能受限资源或非即时可用资源来管理。
   • 应该将问题管理作为每日站立会议的主要焦点。
   • 很强的问题升级能力，是强大的问题管理能力的基本部分。
   • 应该清晰定义升级规则，写成文档，并让全体团队成员都了解这些规则。
   • 当参与到价值流中的所有部门都对升级规则达成富有协作性的共识时，升级规则就能发挥更好的作用。
   • 要使用电子化方式来跟踪问题。
   • 一些基于电子化数据的报告，能够帮助组织进行大型项目的日常问题管理。
   • 使用问题和受阻工作项的累积流图，可以呈现问题管理与解决和根因分析与解决能力的发展状况。