累积流图 (CFD: Cumulative Flow Diagram)是一种很有效地度量分析方法,可以很好地反映工作项在每个流程节点的流动情况,观察到不同角色在交付过程中相互协作的情况,并可以很容易地分析出研发过程各个阶段在制品、交付周期、交付效率随时间变化的趋势。

之前一直没理清楚如何观察并使用,最近在查阅度量相关文章的时候,又看到了,就梳理并记录下来。

01

累积流图是如何生成的?团队需要根据自己的研发过程流程节点,记录某天每个节点上的数量,然后以日期为横坐标,卡片数量为纵坐标,生成如下图所示的图形,就是累积流图了。

在迭代中,SM 经常还会关注一个图:燃尽图。它是以图表展示随着时间的减少工作量的剩余情况。工作量一般以竖轴展示,时间一般以横轴展示。燃尽图对于预测何时完成工作很有用,但是它只有结果,没有过程,不利于问题分析。

02

那么,对于累积流图,我们需要关注一些什么呢?以上图为例,我们需要关注以下几点。

WIP: 看纵轴,从"需求已确认"到"代发布"之间的高度,代表了整个团队的在制品数量,这个数量越多,说明团队同时在处理的卡片越多,有可能在超负载工作。

平均开发周期:看横轴:从"开发中"到"已完成"之间的长度,代表了从开发启动到完成的周期时间。这个长度的变化,反映了团队交付能力的变化。

注:关于这两条线的起终点,不同团队的定义可能会不一样,可以根据实际情况做调整

吞吐率:Throughput(吞吐率)= WIP(在制品)/ Average Lead Time(平均周期时间)在累积图中,"完成"线的斜率就是吞吐率。通过观察"完成"线的斜率变化,就可以直观地看出团队的交付效率的变化。

迭代交付结果:卡片状态如果最终在迭代最后一天重合,说明所有卡片都交付了,如果出现断层,则说明迭代有未交付的内容,需要关注原因是什么。

03

理想很丰满,现实很骨感,美丽的曲线总是存在于想象中。在现实的团队中,不太可能出现完美的累积流图,那么,我们可以通过累积流图发现哪些问题呢?

如上图,在迭代的后期,卡片状态都没有变化了,那么就需要关注下团队在干什么,放假了?还是团队整体调走去其他项目。

如上图,开发完成的面积比较突出中,说明研发人员已完成卡发,但是测试的卡片一直没有明显的变化,说明测试团队遇到了困难,需要支持。

如上图,在某个时间节点,卡片的状态突然变化,大概有两种情况:要么团队成员没有养成按时移动卡片的习惯,要么是团队在 DeaDline 来临时被迫移动卡片,需要引起重视。

如上图:在最终发布的时候,已完成的数量少于需求数,意味着部分需求没有发布,是因为什么呢?临时决定,还是需求评估有问题?需要团队一起思考。

如上图,在迭代末期,需求数突然增加了,这有可能是为了响应业务的变化而进行紧急需求插入,也有可能是为了搭车上线,赶在发布窗口之前追加一些新的需求。敏捷思维让我们欣然接受需求的变更,但是我们也承认过度的变更会导致开发过程的摩擦。

04

对于累积流图,我们需从更长的时间周期来观察和分析问题。当状态的曲线发生变化时,应当以分析问题为主,它是用于管理流程和改善服务交付结果的重要工具。用累积流图观察一个团队的工作进展时,数值本身不能说明问题,但数值的变化趋势会给我们一些预警,告诉我们哪个环节可能碰到了问题或成为瓶颈。我们关注累积流图中每一种颜色区域的变化趋势(看是否有拓宽或增厚的趋势),来获取风险预警。若有此趋势时,我们需要到团队中去充分了解情况,识别真正的问题或潜在的风险并采取相应的应对措施。


↙↙↙阅读原文可查看相关链接,并与作者交流