zoukankan      html  css  js  c++  java
  • 真实案例来理解累积流图的真正含义

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

     

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

  • 相关阅读:
    python 去除字符串两端字符串
    python 找到列表中满足某些条件的元素
    python join函数
    Ambiguous mapping. Cannot map "***Controller" been method解决办法
    uflo2安装与配置
    uflo2概述
    Mybatis-plus中的常用注解
    Spring Cloud Eureka配置文件详解 (还没细看)
    idea安装lombok
    PowerDesigner最基础的使用方法入门学习(一)
  • 原文地址:https://www.cnblogs.com/chenliangcl/p/9168932.html
Copyright © 2011-2022 走看看