累积流图 (CFD: Cumulative Flow Diagram）是一种很有效地度量分析方法，可以很好地反映工作项在每个流程节点的流动情况，观察到不同角色在交付过程中相互协作的情况，并可以很容易地分析出研发过程各个阶段在制品、交付周期、交付效率随时间变化的趋势。
之前一直没理清楚如何观察并使用，最近在查阅度量相关文章的时候，又看到了，就梳理并记录下来。
累积流图是如何生成的？团队需要根据自己的研发过程流程节点，记录某天每个节点上的数量，然后以日期为横坐标，卡片数量为纵坐标，生成如下图所示的图形，就是累积流图了。
在迭代中，SM 经常还会关注一个图：燃尽图。它是以图表展示随着时间的减少工作量的剩余情况。工作量一般以竖轴展示，时间一般以横轴展示。燃尽图对于预测何时完成工作很有用，但是它只有结果，没有过程，不利于问题分析。
那么，对于累积流图，我们需要关注一些什么呢？以上图为例，我们需要关注以下几点。
WIP: 看纵轴,从"需求已确认"到"代发布"之间的高度，代表了整个团队的在制品数量，这个数量越多，说明团队同时在处理的卡片越多，有可能在超负载工作。
平均开发周期：看横轴：从"开发中"到"已完成"之间的长度，代表了从开发启动到完成的周期时间。这个长度的变化，反映了团队交付能力的变化。
注：关于这两条线的起终点，不同团队的定义可能会不一样，可以根据实际情况做调整。
吞吐率：Throughput（吞吐率）= WIP（在制品）/ Average Lead Time（平均周期时间）在累积图中,"完成"线的斜率就是吞吐率。通过观察"完成"线的斜率变化，就可以直观地看出团队的交付效率的变化。
迭代交付结果：卡片状态如果最终在迭代最后一天重合，说明所有卡片都交付了，如果出现断层，则说明迭代有未交付的内容，需要关注原因是什么。
理想很丰满，现实很骨感，美丽的曲线总是存在于想象中。在现实的团队中，不太可能出现完美的累积流图，那么，我们可以通过累积流图发现哪些问题呢？
如上图，在迭代的后期，卡片状态都没有变化了，那么就需要关注下团队在干什么，放假了？还是团队整体调走去其他项目。
如上图，开发完成的面积比较突出中，说明研发人员已完成卡发，但是测试的卡片一直没有明显的变化，说明测试团队遇到了困难，需要支持。
如上图，在某个时间节点，卡片的状态突然变化，大概有两种情况：要么团队成员没有养成按时移动卡片的习惯，要么是团队在 DeaDline 来临时被迫移动卡片，需要引起重视。
如上图：在最终发布的时候，已完成的数量少于需求数，意味着部分需求没有发布，是因为什么呢？临时决定，还是需求评估有问题？需要团队一起思考。
如上图，在迭代末期，需求数突然增加了，这有可能是为了响应业务的变化而进行紧急需求插入，也有可能是为了搭车上线，赶在发布窗口之前追加一些新的需求。敏捷思维让我们欣然接受需求的变更，但是我们也承认过度的变更会导致开发过程的摩擦。
对于累积流图，我们需从更长的时间周期来观察和分析问题。当状态的曲线发生变化时，应当以分析问题为主，它是用于管理流程和改善服务交付结果的重要工具。用累积流图观察一个团队的工作进展时，数值本身不能说明问题，但数值的变化趋势会给我们一些预警，告诉我们哪个环节可能碰到了问题或成为瓶颈。我们关注累积流图中每一种颜色区域的变化趋势（看是否有拓宽或增厚的趋势），来获取风险预警。若有此趋势时，我们需要到团队中去充分了解情况，识别真正的问题或潜在的风险并采取相应的应对措施。
