真实案例来理解累积流图的真正含义

真实案例来理解累积流图的真正含义

 

 目前，是美国敏捷联盟认证的敏捷教练（CSM），致力于推动国内的敏捷实践与宣传。

累积流图（CFD: Cumulative Flow Diagram)是看板方法里的核心度量，可以很好地反映工作项在每个流程环节的流动问题。但遗憾的是，由于这个度量图表比较抽象，导致很多团队想用又不会用。 

原理

想知道怎么用，首先要理解怎么画出来的：

团队在每天站会的时候，记录看板系统的各个流程阶段在制品数量，每个流程阶段用不同颜色绘制，每天连续记录，就绘出了小河弯弯的累积流图。

举例，某团队今天站会上的看板如下：

首先绘制横轴和纵轴：

横轴：时间

纵轴：工作项数量

然后数看板上的工作项数量即可：

今天在“完成”列上有2个工作项，因此在横轴为今天、纵轴为2的位置打个绿色的点，表示累计共完成了2个工作项。为简单起见，绿线我们称为“完成线”；

测试列有2个工作项，完成列与测试列共计4个工作项。于是，在横轴为今天、纵轴为4的位置打个蓝色的点，表示累计共进入测试环节4个工作项，包括正在测试和测试完成的所有工作项。蓝线我们称为“进入测试线”；

开发列（包括开发进行中和开发完成列）共3个在制品，开发列、测试列与完成列合计共7个工作项。于是，在横轴为今天、纵轴为7的位置打个红色的点，表示累计共进入开发环节7个工作项，包括正在开发、开发完成、测试中、 测试完成的所有工作项。红线我们称为“进入开发线”；

Backlog列有7个在制品，Backlog列、开发列、测试列与完成列合计共14个工作项。于是，在横轴为今天、纵轴为14的位置打个橙黄色的点，表示累计共进入Backlog列14个工作项，包括当前在Backlog中、正在开发、开发完成、测试中、 测试完成的所有工作项。橙黄色线我们称为“进入Backlog线”。

每天持续打点，就形成如下图一样的累积流图：

如何分析

知道了怎么画，你就知道了含义。两条线之间的垂直高度代表该流程阶段有多少在制品。比如：“进入开发线”与“进入测试线”之间的高度是3，代表开发环节当前有3个在制品。

累积流图还能分析到什么呢？

分析在制品（Work In Progress，以下简称WIP）

看纵轴：从“进入开发线”到“完成线”之间的高度，代表了整个看板的在制品数量，因此，这个高度的变化，反映了看板上在制品变化。

如果某个流程阶段的垂直高度较高，可能暗示了研发流程在该处有瓶颈或超负载工作等问题，需注意分析解决。

2. 平均周期时间（Lead Time）

看横轴：从“进入开发线”到“完成线”之间的长度，代表了从开发启动到完成的周期时间。这个长度的变化，反映了团队交付能力的变化。

如果某个流程阶段的水平长度较长，说明该流程环节的周期时间长，而往往是由于该环节的在制品堆积造成。

3. 吞吐率(Throughput)

按照排队理论（Little’s Law）：

Throughput（吞吐率） = WIP（在制品） / Average Lead Time（平均周期时间）

在累积图中，“完成”线的斜率就是吞吐率。通过观察“完成”线的斜率变化，就可以直观地看出团队的交付效率的变化。

4. 需求范围的变化

“进入Backlog线”的高度反应了所有Backlog的工作项的数量。这条线变高说明有新的需求进入了Backlog；平的时候表示这段时间Backlog里没有进新需求；这条线变低，说明需求从Backlog里删除。

5. 预测交付日期

将“完成线”按照当前的斜率画出其延长线，与“进入Backlog”线的交点，就是按照当前的吞吐率交付现有Backlog范围的预计日期。这个预测随着Backlog范围的变化、以及吞吐率的变化而变化。

美丽的，向小溪流动一样的累积流图是罕见的。真实世界里的累积流图都是丑陋的。这就是人生。

下面举几个案例

案例1：在制品持续堆积

解析：

图中“进入开发线”与“进入测试线”之间的高度，以及“进入测试线”和“完成线”之间的高度都在持续增长，说明开发环节、和测试环节的在制品在持续堆积。为什么出现这样的现象呢？需要结合看团队的看板，并且与团队一起分析才能知道原因。但是肯定一点：团队没有设置在制品限制，任由在制品持续堆积。

案例2：批次性交付

解析：

图中，“完成线”呈阶梯式上升，像爬楼梯一样。可以判断出这个团队采取了固定的发布节奏，每到发布的时候，累积流图就上了一层楼梯，发布之前，“完成线”是平的。

然后，观察“进入Backlog线”，也是呈现台阶状，而且与“完成线”上台阶的节奏一致。可见该团队的Backlog填充节奏与交付节奏保持高度一致。

再次，观察“进入测试线”与“完成线”之间的高度越来越高，但是我们无法判断出是由于“测试进行”列的在制品堆积，还是由于测试完成后发布工作碰到了问题，导致测试完了不能发布所造成。因此，需要在看板上将测试环节、发布环节细化，才能判断出问题所在。

案例3：集体停滞

解析：

上图中，在很长一段时间内，“进入开发线”、“进入测试线”、和“完成线”都是平的，可见这段时间内没有任何工作项流入开发，也没有任何工作项完成。怎么会这样呢？

常见的原因有以下几种可能性：

1. 这段时间是法定假日

2. 团队整体调走去其他项目

3. 运维有故障，团队所有人去帮助运维解决故障

到底什么原因，需要引导团队分析。

案例5：某个环节无法启动

解析：

图中“完成线”与“进入测试线”在一段时间内是平的，由于“进入测试线”比“进入完成”线先平了一段时间，所以貌似是由于测试无法开始，导致无法完成。可以判断出，测试环节遇到了阻碍导致测试工作无法开始。

同时，“进入开发线”持续攀升。由此可以判断出，开发人员在测试环节遇到阻碍的时候，没有去帮助解除阻碍，反而继续拉动工作项开发，导致开发环节的在制品持续堆积。

案例6：吞吐率不稳定

解析：

上图中，“进入开发线”的斜率稳定，而“完成线”与“进入测试”线的斜率陡然上升。可见，开发和测试的吞吐率突然大幅度提升。要记住：团队的效率不会忽然上升，一定发生了重大变化。

常见的可能性是：

1. 团队忘记了更新看板。某一天，忽然想起来了，于是大量卡片完成。

2. 团队刚接受了需求拆分的培训，开始尝试将大需求拆小，导致交付的数量上升。

3. 团队迫于管理层的进度压力，拼命赶工，一段时间内集中完成大量需求。这样做一定是有副作用的，过一段时间，团队的吞吐率不仅会下降，反而会花更多的时间修改前段时间赶工埋下的雷。

案例7：Scrumban团队

解析：

图中，从原点到结束，所有线”汇集到一点，这说明：在最后一天，团队的看板上是空的。此外，“进入Backlog”线是平的，即：在这段时间内，没有新需求进入到Backlog里。这是典型的Scrum团队的特征。

此外，仔细观察可以发现，在前半段时间，开发环节的在制品持续堆积，而测试环节的在制品较少；而后，测试环节的在制品开始多起来，而开发环节的在制品开始减少。可见这个Scrum 团队需要改进Sprint周期的工作流，避免小批量开发，让工作平衡流动。

案例8：中途抛弃需求

解析：

正常的情况下，所有的线都是向上走的。如果有线向下走，一定是有工作项抛弃的情况。图中，除了“进入完成线”，每条线都向下走，而向下的高度相同，可见是测试列抛弃了工作项，从而“进入开发线”和“进入完成线”都同时向下走。

这种情况团队要回顾：为什么工作项在启动研发后抛弃？这种浪费如何避免？

最后

团队的累积流图千差万别，上面介绍了几个典型例子，并不能涵盖所有场景。总之记下两个操作要点：

累积流图是团队交付过程的回放，抓住累积流图的几个点，引导团队回顾发生了什么，从而改进价值的流动过程。

累积流图在站会结束后更新，在交付评审（回顾）会议上分析。累积流图的分析周期不能短于1周，应该与交付节奏保持一致，否则对一个交付周期的过程看不完整。