在上文的下钻分析一节中，我介绍了按阶段下钻的方法，可以把交付周期按照交付管道中不同节点，分解到每个阶段的耗时情况。但这种方法实际统计的是一段周期内的平均值，而平均值无法体现出按时间变化的趋势，只能用于事后分析，无法在过程中进行干预。接下来，让我们来细化和解决这一问题。
累积流图（CFD: Cumulative Flow Diagram)是一种很有效的度量分析方法，可以很好地反映工作项在每个流程节点的流动情况，观察到不同角色在交付过程中相互协作的情况，并可以很容易地分析出研发过程各个阶段在制品、交付周期、交付效率随时间变化的趋势。
累积流图的 X 轴是日期，通常使用天数作为刻度，Y 轴的是工作项数量。那么 Y 轴从研发过程第一个状态（如“分析”）到最后一个状态（如“完成”）之间的高度，就代表了在制品的数量，高度越高说明在制品堆积越多。X 轴从研发过程第一个状态（如“分析”）到最后一个状态（如“完成”）之间的长度，则代表了从开发启动到完成的周期时间，这个长度越长说明周期时间越长，而这往往是由于在制品堆积造成的。根据利特尔法则，Throughput（吞吐量） = WIP（在制品） / Average Lead Time（平均前置时间）。在累积流图中，“完成”线的斜率就是吞吐量。通过观察“完成”线的斜率变化，就可以直观地看出团队的交付效率的变化。
在理解了以上分析方法后，我们就可以把工作项每个阶段的流动情况，按照时间维度绘制出来累积流图，来识别当前交付的进展、瓶颈、问题和需要进一步探查的内容。
下图给出了研发效能度量平台绘制的四张典型的累积流图。我们来逐个分析一下：
- 在左上角的累积流图中，我们发现代表”测试中”的红色区域随着时间推移，面积持续扩大，而且这个区域的高度和长度都在快速增长。这说明”测试中”这个状态的在制品堆积变得越来越严重，并且交付周期也在变得越来越长。我们初步可以判定”测试中”阶段可能是当前交付管道中的瓶颈所在。但这个时候还不能武断地认为就一定是测试资源或者测试产能的问题，还可能有各种其他情况。比如，开发提测质量很差导致大量缺陷产生，工作项虽然处于测试中状态但实际是在等待开发修复缺陷。或者是由于不同系统之间的依赖，已完成的部分不具备可独立测试性，需要等待其他系统就绪后才能开展测试等。但无论如何，我们已经找到了瓶颈点所在及其发展趋势，接下来的问题就是如何干预、优化和提升了。
- 在右上角的累积流图中，我们发现代表了开发、测试、上线的多个阶段、不同颜色的区域都发生了”塌陷”，而工作项总量却保持稳定。这说明可能是多个阶段的状态发生了回退，比如某些需求虽然开发、测试完成，并且最终上线了，但是业务在线上验收的时候发现存在重大问题，或与原始需求目标存在较大差异，要求需求下线并重新进行设计和开发。这是一种严重的返工行为，我们知道这代表着巨大的研发资源浪费。这就是我们为什么要从源头把控好需求的质量，加强对需求的理解，明确需求验收条件的原因。如果是需求存在质量或歧义的问题，可能导致数倍于需求分析工作量的研发和测试工作量产生，这种杠杆作用会让本来就很稀缺的研发资源的有效产出进一步降低。研发效能不仅与效率有关，还关乎到有效性。
- 在左下角的累积流图中，我们发现代表”开发中”的黄色区域随着时间推移，其高度保持水平，这说明”开发中”这个状态已经陷入了停滞。但代表”测试中”的绿色区域还在持续增长，说明并不是所有工作都停滞了。我们需要进一步探查发生这种情况的原因，由于并不是所有工作都停滞了，我们可以排除放长假的影响。所以，很有可能是开发过程中遇到了重大的技术架构问题，导致开发工作无法继续开展，或者由于出现了突发的紧急状况，需要调拨大量开发人员去进行救火，导致当前开发工作停滞。停滞作为流动的对立面，我们应当及时识别出这种情况，尽快处理。
