5 流效率分析
流效率就是在交付管道中，工作项处于活跃工作状态的时间（无阻塞地工作）与总交付时间（活跃工作时间 等待时间）的比率。经验表明，很多企业的流效率只有不到 10%，也就意味着需求在交付管道中有大量时间都处于停滞、阻塞、等待的状态。
我们结合 DevOps 平台中的看板工具，将待评审、就绪（待开发）、待测试、待发布等阶段的属性设置为”等待”，而需求沟通、需求评审、方案设计、开发、测试、发布等阶段的属性设置为”活跃”，这样就可以得到研发过程的基础数据，对流效率指标进行计算。
下图给出了我在一个部门落地流效率度量和分析时的一些实施细节，通过对指定范围内团队的看板进行统一配置，明确各个阶段的准入准出，规范各个团队的操作规范，就可以得到流效率的度量数据。然后，我们通过对在制品数量进行控制、推进小批量交付和一系列最佳实践的引入，优化了研发阶段的等待时间，让流效率获得了一定的提升。
在这里有个问题需要特别注意，就是数据准确性的问题。如果依据看板工具进行各个研发阶段耗时的统计，那么我们就要考虑看板中的工作项状态与实际工作状态如何保持一致的问题。当然，办法还是有的。比如，我们可以依靠规范的宣贯和执行的监控，确保数据相对准确（例如至少在每日站会的时候确保工作项状态及时更新），但更为有效的办法是通过自动化的手段，在工作项与代码关联后，研发人员后续的一系列基于代码的提交、合并、提测、上线等动作可以自动联动更新工作项的状态，关于这部分的内容我们将在下一章中展开说明。
6 流负载分析
流负载是在交付管道中已经开始、尚未完成的工作项的数量，也就是我们经常说的在制品数量。流负载是一个关键的先导性指标，流负载过高一定会导致后续的交付效率下降、交付周期变长，所以识别到这类问题就要进行及时干预。
下图给出了我在一个团队中落地流负载度量和分析时的一个案例，可以看到产研团队流负载比上个统计周期提升了 43%，而相同周期内的产研交付周期环比提升了近 20%。从实际统计数据来看，这两个指标之间存在关联关系，流负载的升高影响了交付周期的上浮。但这两个指标之间并没有像公式一样存在那种精确的数学关系，这是因为影响交付周期的因素本来就很多，我们无法像在实验室中一样屏蔽掉所有其他因素的影响，而只观察这两个指标之间的关系。另外，流负载的升高对于交付周期的上浮存在延迟反馈，积压的需求可能并没有在当前统计周期内完成，也就并没有进入到交付周期的数据统计范围内。但是，我们已经能足够清晰地看到趋势，两个指标之间存在强相关。
看到了问题以后，我们可以使用上文中提到的在制品下钻方法进行具体工作项的排查。我们也可以使用被称为”个人研发日历”的视图进行查看。在下图中可以看到，位于最下面的开发人员在 3 月 15 日~3 月 21 日这周的并行任务非常多，而且都是贯穿整周时间的工作安排。这种大量并行，频繁打断和上下文切换的工作方式，也是研发过程中一种典型的浪费—任务切换浪费。我们应当进一步优化研发计划，控制并行的在制品，让流动变得更顺畅。
