《看板方法》读书笔记
2023-08-14 09:52:26 0 举报AI智能生成
敏捷项目管理，KANBAN
作者其他创作
大纲/内容
第一部分 导论
第1章 解决敏捷管理者的困境
1. 看板系统来自一系列称为拉动系统的实践方法。
2. 埃利亚胡·高德拉特的“鼓-缓冲-绳”作为约束理论的一种应用，是拉动系统的实施方法之一。
3. 我之所以探索拉动系统，来自两方面的动机：一方面是寻找一种系统性的途径、使团队在工作中实现可持续的步调；另一方面是寻找一种方法，能够以最小的阻力引入过程变革。
4. 看板是丰田生产方式及其改善方法的支撑机制，能够带来持续改进。
5. 第一个虚拟的软件工程看板系统，是从 2004 年开始在微软公司实施的。
6. 从早期的看板实施来看，结果令人鼓舞。看板确实可以实现可持续步调，通过渐进增量的方式，最大限度地降低变革阻力，并产生显著的经济效益。
7. 作为一种变革技术的看板方法，自2007年8月在华盛顿特区召开的2007年敏捷大会展示之后，开始广受社区关注。
8. 在本书中，看板(kanban)(小写字母“k”开头)指的是信号卡，看板系统(kanban system)(小写字母“k”开头)指的是使用(虚拟)信号卡实施的拉动系统。
9. 看板(Kanban)(大写字母“K”开头)方法指的是自 2006-2008 年间在 Corbis 公司涌现的渐进增量式的过程改进方法学。这些年来，看板方法在更为广泛的精益软件开发社区中得到了持续深入的发展。
第2章 什么是看板方法
1. 任何情况下，都可以使用看板来限制系统内的某些事物的数量。
2. 东京皇居东御苑公园使用了看板系统来控制公园内的游客数量。
3. 可供流通的“看板”信号卡数量为在制品 (进行中的工作项) 设置了限额。
4. 当前工作项或任务完成时，信号卡便被收回，用于将新的工作项拉入流程中。
5. 在 IT 工作中，由于没有实际的物理卡片用于传递和定义在制品限额，所我们(通常)使用虚拟的看板系统。
6. 在敏捷软件开发中，常见的卡片墙并不是看板系统。
7. 看板系统在工作场所中创建了一种积极张力，驱动大家去讨论问题。
8. 看板方法(大写字母“K”开头的“Kanban”)利用看板系统(kanban system)作为改进的催化剂。
9. 看板方法要求对过程中的规则进行明确的定义。
10. 看板使用来自不同知识领域的工具，鼓励分析问题和探索解决方案。
11. 通过不断探索发现影响过程效能的问题，看板方法可以实现增量式的过程改进。
12. 可以通过 Limited WIP Society 的在线站点 http://www.limitedwipsociety.org/获取关于看板方法的最新定义。
13. 在软件开发行业，看板起到权限授予者(permission giver)的作用，鼓励团队根据具体情境制订过程解决方案，而不是教条式地遵循某种软件开发生命周期过程定义或模板。
第二部分 看板方法的益处
第3章 一种成功秘诀
1. 看板方法包含了成功秘诀的所有方面。
2. 成功秘诀解释了看板方法为什么具有价值。
3. 质量低下是软件开发中最大的浪费。
4. 减少在制品即进行中的工作项数量，能够提高产品质量。
5. 提高质量能够增进与下游合作伙伴如运维部门等之间的信任,。
6. 频繁发布能够增进与上游合作伙伴如市场营销部门等之间的信任。
7. 可以通过拉动系统，根据交付速率来平衡需求请求量。
8. 拉动系统能够暴露瓶颈所在，并在非瓶颈处产生富余时间。
9. 对于运作良好的软件开发价值链，高质量的优先级排序活动能够使交付的价值最大化。
10. 如果没有良好的初始质量，交付上也缺乏可预测性，那么优先级排序几乎毫无价值。
11. 为了降低变异性而进行的改变，需要富余时间。
12. 降低变异性能够减少对富余时间的需要。
13. 降低变异性有利于实现资源平衡(并潜在地降低对人数的需求)。
14. 降低变异性能够降低对资源的需求。
15. 降低变异性能够减少看板令牌 (kanban tokens)、减少在制品数量，最终体现为平均前置时间下降。
16. 富余时间能够使更多的改进机会成为可能。
17. 过程改进能够带来更高的生产率和更好的可预测性。
第4章 在五个季度内，从最差变为最好
1. 第一个看板系统始于2004 年，最早是在微软的XIT软件维护团队中实施。
2. 第一个看板系统中使用了电子化的跟踪工具。
3. 第一个看板系统是在微软公司的一家离岸外包供应商团队中实施的，该供应商具有CMMI5级资质，该团队在印度的海德拉巴办公。
4. 应该将工作流绘制出来，以可视化的形式星现工作流。
5. 应该通过一组明确定义的策略来描述过程。
6. 看板方法能够促成增量式的变革。
7. 看板方法能够降低变革中的政治风险。
8. 看板方法能够最小化变革过程中遭遇的阻力。
9. 使用看板方法，能够发现改善的机会，而且其中不会涉及复杂的工程方法变更。
10. 第一个看板系统的实施，在生产率上有了超过 200%的提升，前置时间减少了 90%，在可预测性上也有了大幅提升。
11. 通过管理瓶颈、消除浪费和降低那些影响客户期望值与满意度的变异性产生显著改善是很有可能的。
12. 变革需要经历一段时间才能充分展现效果。第一个看板实施案例在 15 个月后才完全显现成效。
第5章 持续改进的文化
1. kaizen 的意思是“持续改善”。
2. 在持续改善的文化中，每个个体都有充分的授权感，能够毫不畏惧地行动，自动自发进行协作和创新。
3. 在持续改善的文化中，无论成员身处组织结构中的哪个级别，彼此间都具备高度的社会资本和信任度。
4. 工作在流行中流动，看板方法则同时为工作和流程提供了透明性。
5. 过程的透明性使得所有干系人都能看到自己作为或不作为时所产生的影响。
6. 当能够看到自己的影响效果时，个体会变得更乐于贡献时间和进行协作。
7. 看板方法中对在制品设限的做法，能够使停止生产线 (stop the line)的行为变为可能。
8. 看板方法中对在制品设限的做法，鼓励集思广益共同解决问题。
9. 通过共同解决问题和与外部利益相关者开展合作，团队的协作性得到了提升，最终提升了团队的社会资本水平和团队成员之间的信任程度。
10. 看板方法中对在制品设限及服务分类的做法，能够授权个体主动拉动工作，进行优先级排序和计划调度决策，而无需管理人员进行监管。
11. 授权水平的提升能够增加社会资本以及员工与管理人员之间的信任程度。
12. 协作行为能够以病毒传播的方式扩散。
13. 个体会跟随资深领导者。资深领导者之间的共担与协作行为，将影响全体员工的行为。
第三部分 实施看板方法
第6章 价值流映射
1. 确定看板管理的实施范围、划清外部边界。最好只在自己的职务权力范围内实施看板。不要强迫任何没有意愿进行协作的部门实施可视化管理、提供透明度和设置在制品限额。
2. 根据外部边界选择的决定，建立卡片墙模型，设置在制品限额，使工作可视化。
3. 定义工作项类型，建立工作流动的模型。有些类型的工作也许不需要走完流上的每一个步骤。
4. 设计工作项卡片，使其拥有充足的信息，引导团队以自组织的方式拉动工作项，便于团队成员根据工作项类型、服务水平协议和服务类别综合呈现的风险状况，做出高质量的决策。
5. 如果团队成员分布于多处，或者如果允许员工在家工作等，以及渴望通过电子化系统提供的定量信息来引领更高级更成熟的行为发生，那么需要使用电子跟踪系统。
6. 根据情况采用合适的方法来处理并行活动，选择合适方法为之建立模型，并实现可视化。
7. 根据情况采用合适的方法来处理无需遵循特定顺序的活动，选择合适方法为之建立模型，并实现可视化。
第7章 使用看板进行协调
1. 最佳实践是同时使用物理卡片墙和电子跟踪系统。
2. 使用电子跟踪系统，就可以跨多个地理位置应用看板。
3. 有多家供应商提供模拟物理卡片墙功能的电子看板产品。
4. 定期召开会议能够减少会议的协调成本，提高出席率。
5. 优先级排序和发布规划应独立完成，并应具有各自独立的节奏。
6. 每日站立会议应该用来讨论缺陷、障碍和流动性问题，它们并不一定要沿袭其他敏捷开发方法中的既定模式。
7. 每日站立会议是鼓励持续改进的文化中的重要组成部分。由于站立会议每天都把整个团队简短地聚集在一起，提供了一个所有利益相干者能够提出建议并讨论改善的机会。站立会议之后的时段，往往会出现一个与过程改进相关的非正式讨论。
8. 通过对待办项列表进行定期分类梳理来缩减待办项规模，以提高优先级排序会议效率。
9. 问题管理、问题升级和问题解决是提升团队效能的核心实践，应该在团队发展的早期阶段便重视这种能力的培养。
10. 应该清晰定义问题的升级路径和规则。
第8章 建立交付节奏
1. 交付艾奏指的是在交付可用软件上形成的固定频率。
2. 采用看板方法，可以将交付节奏与开发前置时间和优步级排序节奏分离开来。
3. 在尝试敏捷开发方法时，一些团队由于采用了固定时间盒的短迭代，遭遇了一些麻烦。
4. 交付（或发布)软件的过程中，需要对参与其中的各种不同职能的人员进行协调。这些协调活动都具有可度量的成本。
5. 交付（或发布)软件的过程中，无论是在时间还是费用上，都同时伴随着一系列事务成本。可以对这些事务成本进行测定和跟踪。
6. 可以通过将进行1次交付所需的事务成本和协调成本之和，与本次软件交付的总成本相除来计算交付效率。
7. 可以将1次发布的总成本与本次发布交付的价值进行对比，来确定交付节奏。
8. 聚集于降低事务成本和协调成本，可以提升交付效率和改善交付节奏。
9. 定期交付能够建立信任关系。
10. 设定定期交付的预期并持续达成这种预期，是一件富有挑战性的事情。
11. 根据定期交付的节奏进行调度，能够降低协调成本。
12. 高成熟度的组织中，由于已经形成了高水平的信任文化，而且交付的事务成本和协调成本很低，实行随需或临时交付更具意义和价值。
13. 允许急交付(expedited delivery)请求，可能会引发1次非常规性的发布。在执行完1次特殊的非常规发布之后，要尽快恢复定期发布的节奏。
第9章 建立输入节奏
1. “优先级排序节奏”指的是达成共识的定期召开会议的时间间隔，会议中按优先级将新工作项拉入输入队列以便开发。
2. 通过将优先级排序节奏与开发前管时间及交付节奏分离的策略，看板方法移除了敏捷迭代计划协调活动中可能存在的机能障碍。
3. 对新工作请求（比如一个用户故事)进行优先级排序时，需要对来自多个不同职能部门的许多人进行协调。这些协调活动的成本是巨大的。
4. 如果为了便于做出优先级排序决策而需要对工作项进行评估，那么这表明优先级排序活动在时间和金钱方面都存在事务成本。这些成本可以被确切计算和跟踪。
5. 在优先级排序方法和确定队列输入内容的过程中所使用的策略，代表了看板方法中优先级排序这一协作性合作博弈活动的规则在软件开发领域的应用。
6. 在敏捷方法中使用的计划游戏无法扩展，相比单一产品线团队，如果要在关注面更广的大型团队中使用这些规划方法，则需要付出巨大的协调成本。
7. 视其中涉及的事务成本和协调成本而定，可以通过鼓励参与优先级排序决策的相关人员以合适频率定期召开会议，建立优先级排序节奏。
8. 可以通过极力降低优先级排序活动中的事务成本和协调成本的方法，来提高效率和提升排序节奏。
9. 频繁召开的优先级排序会议能够在组织成员间构建起信任关系。
10. 以固定频率定期召开优先级排序会议能够降低协调成本，对低成熟度的组织而言，这种策略尤其有用。
11. 对已经建文高层次的信任，而且和优先级排序决策策略相关的事务成本和协调成本都很低的高成度组织，可以选择随需或者旋时进行优先级排序。
第10章 设置在制品限额
1. 需要和价值流上不游的干系人和职能部门资深管理者对 WIP 限额达成一致共识。
2. 虽然可以单方面定义 WIP 限额，但是此后遭遇压力时要捍卫住这个限额将会十分困难。
3. 工作任务的 WIP 限额应该按照每个人、每个开发结对或者每个协同工作的小团队的平均工作项数量来设置。
4. 一般而言，限额数值应该设置在 1~3/人 /结对/团队)范围内比较合适。
5. 输入队列的限额要保持越小越好，一般将其大小设置在足以消化工作项规A模和任务工时上的变异所带来的影响就可。
6. 在瓶颈前要设置缓冲区域。
7. 缓冲区限额越小越好，但是其大小设置要确保瓶颈资源得到充分利用，并足以维持系统中的稳定流动。
8. 所有的 WIP 限额都可以通过不断的试验进行调整。
9. 实施看板是一个试验性的过程。
10. 不要浪费时间试图确定完美的 WIP 限额大小；只需要先设置一个差不多大小的限额，往前走，必要时对限额进行调整、观察、再调整。
11. 工作流下游的一些区域不设置 WIP 限额，有时也是可行的。
12. 要特别注意，不设 WIP 限额的工序步骤，不能成为瓶颈工序，也不能导致在交付(批量向下游交付)时引入大量的事务成本或协调成本。
13. 一旦已经建立 WIP 限额规则，就可以根据工作项类型来分配产能。
14. 根据工作项类型来设置横向泳道，并为每个泳道设置 WIP 限额。
15. 进行产能分配时，需要对看板系统接收的不同类型工作项进行请求分析确定各工作项类型的相对规模。
第11章 建立服务水平协议
1. 划分服务类别为优化客户满意度提供了一种便捷方法。
2. 须依据工作项的业务影响来设置其服务类别。
3. 须对服务类别进行明晰可视的标识，如采用不同颜色的卡片或在卡片墙上服划分不同的泳道等方法，来标识不同的服务类别。
4. 须针对每个服务类别定义一套管理规则。只有那些涉及较高风险的工作项，才需在其中包含诸如估算之类的高成本活动。
5. 必须对团队成员进行培训，确保他们理解各个服务类别以及相关规则。
6. 某些服务类别的规则定义中须包含目标前置时间。
7. 要监控目标前置时间的达成表现(通过“准时交付率”这个度量指标)。
8. 服务类别划分让自组织成为可能，它能给团队成员带来更多授权，并节省出更多的管理时间，使管理者可以更多专注于过程而非工作内容本身。
9. 应用服务类别，可以改变客户的心理。
10. 如果服务类别的方法应用得当，再加上有规律的交付节奏，即使有相当-部分工作项未能按目标前置时间交付，也很少会出现客户抱怨的情况。
11. 在看板系统中要根据每个服务类别配置相应的产能。
12. 分配给各个服务类别的产能比例，要与需求情况相匹配。
第12章 度量和管理报告
1. 使用累积流图对 WIP 进行跟踪，每日监控 WIP 限额。
2. 跟踪每个已处理完毕的工作项的前置时间，报告每种服务类别的平均前置时间和光谱分析结果。
3. 前置时间是展示业务敏捷性的一个信息指示器。
4. 对固定交付日期类工作项，要跟踪预估前置时间与实际前置时间的差异。
5. 可以将准时交付率作为展示可预测性的一个信息指示器。
6. 障碍阻塞了流动，影响了前置时间和准时交付率；可以通过一幅累积流图来报告阻塞问题和受阻工作项数量，并在该累积流图上叠加一张受阻在制品图。可以使用这幅图作为信息指示器，来展示组织识别问题与快速解决问题的能力。
7. 流动效率是指前置时间与分配的工程时间两者之比。它展示的是组织处理8新工作项的效率水平，可以将之作为表征业务敏捷性的第二种指示器。它也可以用于展示在不改变当前使用的工程方法前提下还有多大的改善空间。
8. 初始质量报告的是测试人员在看板系统范围内发现的缺陷数量，通过这个信息指示器，可以展示由于糟糕的初始质量所导致的产能浪费状况。
9. 破坏负载报告的是由于系统存在的一些问题所引致的工作项占比，通过这个信息指示器，可以展示一些产能浪费状况，这些产能本来可以用在开发新的增值特性上。
第13 章 使用两层系统扩展看板
1. 大型项目同样也应该遵循看板方法的核心原则。
2. 对于大型项目，WIP 限额、优先级排序节奏、交付节奏和服务类别也是同样适用的技术。
3. 大型项目一般拥有层次化需求;可以使用不同的工作项类型来表示不同层次的需求。
4. 一般而言，团队会在卡片墙上跟踪需求层次结构中顶上的两层，并在两个
层次上都设置WIP限额。
层次上都设置WIP限额。
5. 最高层次的需求一般是面向客户市场的需求，这些需求是最少价值单位，能够单独进行发布，推向市场。
6. 第二层次的需求通常以客户和用户为中心的方式来编写，并使用类似的方式对之进行分析，将这些需求分解为具备较细的粒度，而且它们的大小规模也比较类似。
7. 通过降低看板拉动系统中的变异性，第二层次的细粒度需求能够促进看板的流动性。
8. 两层卡片墙要求对其上跟踪的两层需求都进行可视化管理。
9 泳道已经成为展现需求层次结构和有利于对 WIP 进行限制的流行方法。
10. 粗粒度的 WIP 可以通过泳道个数来限制。
11. 如果需要，可以在每个泳道上为细粒度的需求设置 WIP 限额。
12. 每个泳道分配给一个小型的跨功能团队。
13. 可以通过在一个常规的工作项卡片上贴附小标签的方式，对共享资源进行可视化管理。
14. 可以通过在工作项卡片上贴附受阻问题便签(在示例中使用的是紫色)的方式来对共享资源的非即时可用性(non-instantavailability)进行可视化管理。
15. 为了全局控制，共享资源应该建立自己的看板系统。
16. 在项目组合中为共享资源建立的看板系统形成了一个网络，可以将之视为是针对软件开发自身的一种面向服务架构。
第14章 运营回顾
1. 运营回顾应该在整个组织范围内进行。
2. 运营回顾应该专注于客观数据士的星现和分析。
3. 每个部门都应在运营回顾会议上汇报各自的数据。
4. 演讲时要保持简短，通常应该汇报类似于第 12 章所述的各种度量数据和信息指示器。
5. 以财务信息开场，强调了软件工程这样的职能部门是更大业务的一部分，也表明良好的管理是重要的。
6. 每月召开一次运营回顾会是一个合适的节奏。太过频繁会占用太多的时间，加重数据采集和会议准备的负担。频率太低则会降低回顾会的价值，有悖回顾会的设计初衷。
7. 运营回顾会应当简短，通常以2小时为宜。
8. 运营回顾会要能够提供一种反馈循环机制，驱动全公司或者事业部进行持续改善。
9. 运营回顾会能向团队成员展示管理者带来的附加价值，让他们了解高效的管理者是如何工作的。
10. 有效的运营回顾会有助于在管理者与员工之间建立相互信任关系。
11. 外部利益不系人参与运营回顾会，有机会了解软件工程及 IT 团队是如何运作的，从而也能了解他们面临的问题与挑战。这有助于促进彼此间的信任与合作。
12. 除了晒成绩和展示团队的优点外，在运营回顾会上，同样也要对糟糕的数据与问题进行认真的分析讨论。
13. 在公司外部的场所召开运营回顾会，有助于参会者专注思考。
14. 在会议过程中提供食物，看起来能够提升参会者的参与积极性。
15. 高管参与运营回顾会，能够向员工传递出组织重视效能与持续改善的信息。
第15章 启动看板革命
1. 向组织导入看板方法至少可以实现 8 大目标。
2. 通过以导入阻力最小的方式进行过程改进，并以此来提升组织效能。
3. 确保进行高质量的发布/交付。
4. 通过控制在制品的数量来确保前置时间的可靠性。
5. 通过改善工作/生活之间的平衡，为团队成员创造更好的生活。
6. 根据产出来平衡输入的需求，从而为系统创造富余能力。
7. 提供一种简单的优先级排序机制，允许延迟决策(commitment delay)和开放式选择 (open options)。
8. 提供能够看到改善机会的透明机制，从而使组织向更具合作性、鼓励持续改善的文化转变。
9. 努力构建一个结果可预测、业务敏捷、管理良好的流程，打造软件工程研究所(SEI)所定义的高成熟度的组织。
10. 为了和其他利益干系人达成共识，务必要明确实施目标并清晰阐明导入看板方法的益处，这一点非常重要。
11. 遵循导入看板流程的12 步骤指南。
12. 看板使开发团队得以以一种新的模式与外部利益干系人和业务负责人进行谈判。这种谈判模式假设各方都期望建立长期合作关系，并愿意共同致力于提升整个系统的效能表现。
13. 邀请外部利益干系人一起参与建立看板系统基本要素的相关约定，使他们成为其中的合作者。
14. 有关 WIP 限额、目标前置时间、服务类划、优先级排序及交付等方面的基本约定代表着软件开发协作性博弈中的规则。
15. 让外部干系人成为这些博弈规则的共同制定者，这能促成之后的合作行为特别是当系统面临压力时更为需要。
第四部分 持续改进
第16章 三类改进机会
1. 在实施看板方法时，需要采用一些模型来识别改进机会。
2. 看板方法支持至少三种类型的持续改进方法: 约束管理(移除瓶颈)、减少&浪费、变异性管理 (SPC 和渊博知识体系)。
3. 看板方法能够用于识别瓶颈，完整实施约束理论的五步聚焦法。
4. 看板方法能够以可视化方式展示浪费的活动，有助于在软件系统、产品开发或者 IT 组织领域启动全面的精益变革。
5. 看板方法采纳了戴明博士的渊博知识体系和统计过程控制方法时所需要的仪表盘设施。它既可以用来驱动持续改善式的变革，也可以用来驱动六西格玛方法的变革。
第17章 瓶颈和非即时可用资源
1. 瓶颈约束和限制了工作的流动。
2. 有两类瓶颈:能为受瓶颈——无法完成更多的工作;菲即时可用瓶颈由于可用性的限制(但通常是可预测的)导致处理能力有限。
3. 可以使用约束理论的五步聚焦法来管理瓶颈。
4. 增加瓶颈能力的管理举措，称为“突破举措”
5. 一般来说，对能力受限资源采取的瓶颈突破举措，和对非即时可用资源采取的瓶颈突破举措是不同的。
6. 突破举措，可能涉及增加资源、采用自动化，或者改变策略使此前非即时可用资源转变为即时可用资源。
7. 突破举措，通常需要花费资金和时间来实施。通常认为，突破举措是在过程改进方面的战略性投资。
8. 通常情况下，过程瓶颈的效能表现，远低于其潜在能力，即其理论上的能力约束水平。
9. 通过挖掘和保护举措，瓶颈处的交付速率可以提高到其理论上可以达到的能力约束水平。
10. 通常情况下，采用保护举措需要在瓶颈前增加 WIP 缓冲区。对于能力受限资源或非即时可用资源，这么做都是有效的。
11. 挖掘举措通常涉及策略变更，以控制瓶颈资源的工作状况。
12. 可以将服务类别(class of services)作为一种瓶颈挖掘举措。
13. 服从举措，指的是为了能够达到充分挖掘或保护瓶颈资源的目的，在价值流中其他地方进行改变的举措。服从举措通常都表现为策略变更。
14. 挖掘、保护和服从举措一般都易于实施且成本较低，因为它们主要涉及的是策略变更。因此，通过充分挖掘瓶颈以最大限度地提高瓶颈的交付速率，可以视为是战术性的过程改进。
15. 尽管充分挖掘瓶颈能力具有战术特性，但是其中的收益可能是非常显著的，往往可以达到 2.5 倍的交付速率提升，同时前置时间还会随之下降，而且短期内也无需为此付出成本。
16. 在使用突破举措之前，首先应该考虑使用挖掘举措。
17. 实施一个战术性的瓶颈挖掘和服从举措计划时，可以从一个更长远的视角来规划战略性变革，以真正突破瓶颈约束。
第18章 精益的一种经济学模型
1. 浪费主要可以分为以下三种抽象类别:事务成本、协调成本和破坏负载。
2. 浪费是一种隐喻。
3. 浪费这一隐喻无法为所有人所接受，因为浪费常常也是必需的，尽管它们没有带来什么额外的增值。因此，我使用一种经济学成本模型来代替浪费这一隐喻。
4. 可以通过询问“如果可以，我们愿意更多地开展这项活动吗?”的方式来判别一项活动是否真的属于浪费。如果答案是否定的，那么这项活动就是某种形式的浪费。
5. 事务成本可以分为两种类型:初始准备活动和交付清理活动。
6. 协调成本指的是那些任务分配、计划安排等活动引起的开销，或者是那些为了使两人或更多人朝同一产出目标工作所需的协调工作引起的开销。
7. 破坏负载是一种新型的增值工作，但是其中的增值是由于交付了先前没有成功交付的价值，如先前软件中的缺陷、设计或实现上的不足，从而导致客户接纳度低、没有实现预期的关键功能、服务台呼入和服务请求攀升等情况。
8. 破坏负载占用了本可用于开发创新性新功能的产能，这些新功能中包含更多的客户价值，能够带来更多的营收回报。
9. 将想法更快速地转化为可向客户交付的可用代码，能够最大化潜在价值最小化浪费。
第19章 变异性的根源
1. 沃尔特·休哈特于 20 世纪 20 年代开始研究工业过程中的变异，w·爱德华兹·戴明、约瑟夫·杜兰和大卫·钱伯斯在 20 世纪中后期对该领域有了进一步发展。
2. 对变异的研究及其统计分析方法，是丰田生产方式(因此也是精益)和致力过程改进的六西格玛方法的共同核心。
3 .W·爱德华兹·戴明和约瑟夫·杜兰的工作成果启发了卡内基-梅隆大学软件工程研究所的工作及能力成熟度模型(现在称为能力成熟度模型集成，或CMMI)。
4. 休哈特将变异根源分为两类:一类变异来源于过程或系统的内部，一类变异来源于过程或系统的外部。
5. 内部变异也称为机会致因变异。
6. 外部变异也称为可归因变异。
7. 在软件开发生命周期的价值链里，存在许多机会致因变异的根源。典型的例子包括工作项规模、工作项类型、服务类别、不规则紊流和返工。
8. 要列出可归因变异根源，典型的例子包括需求模糊、加急请求、环境可用性、不规则紊流、市场因素、人员因素和来自对协调活动进行调度的挑战等。
9. 对于机会致因变异，可以通过改变定义软件开发生命周期和项目管理过程人的系列规则和策略来控制。
10. 对于可归因变异，可以通过利用问题管理和解决能力以及风险管理能力来应对。可以通过利用根因分析和消除能力来降低或消除可归因变异。
11. 与强大的事件驱动的风险管理结合，看板系统能够产出更好的经济效益。
12. 看板方法也提供了其他方法来管理风险，如按服务类别与工作项类型来设置 WIP 限额，使用风险属性来将工作分为不同类型或类别进行相应处理等。
13. 关于使用看板方法进行风险管理的相关策略措施，目前还正在研究中，在将来的一本书中将会包含该方面的主题。
第20章 问题管理和升级策略
1. 看板系统应该包含一个第一级别的工作顶、问题项，用来跟踪导致其他客户价值工作受阻的问题。
2. 在卡片墙上使用粉色(或红色)便签来可视化受阻问题，已经成为一种惯例做法。
3. 粉色的问题便签贴在受阻工作项的旁边。强大的问题管理和解决能力，对于维持流动而言是最基本的要素。
4. 受阻工作项和问题并非瓶颈。它们应该作为特别致因变异来管理，而不是作为产能受限资源或非即时可用资源来管理。
5. 应该将问题管理作为每日站立会议的主要焦点。
6. 很强的问题升级能力，是强大的问题管理能力的基本部分。
7. 应该清晰定义升级规则，写成文档，并让全体团队成员都了解这些规则。
8. 当参与到价值流中的所有部门都对升级规则达成富有协作性的共识时，升级规则就能发挥更好的作用。
9. 要使用电子化方式来跟踪问题。
10. 一些基于电子化数据的报告，能够帮助组织进行大型项目的日常问题管理。
11. 使用问题和受阻工作项的累积流图，可以呈现问题管理与解决和根因分析与解决能力的发展状况。
0 条评论
下一页
