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

原始连接:http://baijiahao.baidu.com/s?id=1594434241891156737&wfr=spider&for=pc

转载自科技夜谭

本人专注于敏捷开发实践，在IT软件开发和项目管理方面有丰富工作经验。目前，是美国敏捷联盟认证的敏捷教练（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 周，应该与交付节奏保持一致，否则对一个交付周期的过程看不完整。

原始连接:http://baijiahao.baidu.com/s?id=1594434241891156737&wfr=spider&for=pc