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

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

 

 目前,是美国敏捷联盟认证的敏捷教练(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周,应该与交付节奏保持一致,否则对一个交付周期的过程看不完整。

posted on 2018-06-11 19:56  仗剑走天涯|  阅读(10762)  评论(2编辑  收藏  举报