×

微信扫一扫,快捷登录!

标签: 暂无标签


一. 累积流图


产品开发过程的度量图表中,累积流图最为强大和有效,它直观易懂,却包含大量的实用信息。
1.1 累积流图的含义

累积流图反映各个阶段累积处理的需求数量,以及它们随时间的变化趋势,它的横坐标为日期,纵坐标为各阶段累积完成的需求数目。

累积流图

上图看板系统包含从就绪到上线的6个阶段。相应的,累积流图从左到右6条线分别是这些阶段累积完成的需求数目。例如,最左边的上边线是累积就绪(已经计划)需求的数目,其后依次是累积开始开发、开发完成、开始测试、测试完成和上线需求的累积数量。

图中,特定颜色的区域表示不同的阶段,深色区域是工作阶段,如:深红色的是实现中的需求,深蓝色的是验证中需求;浅色区域表示等待阶段,如:浅红色的是等待实现(已就绪,但尚未开始实现)的需求,浅蓝色的是等待验证的需求,浅绿色的是等待上线的需求。
1.2 解读累积流图并从中发现改进机会

累积流图反映团队整体的交付过程。从中看到的不仅是孤立的数据指标,更重要的是一个动态和系统的整体。下面,让我们来解读累积流图的信息密码。
1.2.1 从累积流图中解读在制品、前置时间和交付速率的数据

从累积流图中分析在制品数量、前置时间和交付速率

从累积流图中我们可以看到三个关于流动的重要指标:

1)在制品数目。在制品数目指正在处理的需求的数目,也就是所有开始但还没有完成的需求的数目。如:上图中4月15日这一天,累积就绪的需求有61个,累积上线的需求是8个。在制品数量 = 61- 8 = 53(个),它们已经计划,但还没有交付,分布在过程中的各个阶段。

2)平均前置时间。前置时间是精益度量中的一个核心指标,指需求交付之前,从开始到结束所经历的时间。上图中,到3月26日这一天累积计划了40个需求,而到5月15日这一天累积交付40个需求。假设需求符合先入先出(先计划的先交付)的规律,那么第40个需求的前置时间(交付周期)就是 5月15日 - 3月26日=50(天)。之所以要在前置时间之前加上“平均”,是因为并非所有的需求都是先进先出。

3)交付速率。交付速率指单位时间内交付需求的数目。上图中,从3月30号到5月15号,6周时间交付需求数目从8个增加到53个,共交付45个需求,交付速率 = 45 / 6 = 7.5 (个/周)。最下方表示交付的这根线的斜率,就是交付速率。

在制品数量、前置时间、交付速率是衡量价值流动的三个重要指标。累积流图既反映了它们的静态值,也反映了它们的动态变化趋势。比如上图的右上角时间比较靠后时,在制品数目降低了,前置时间也变短,而交付速率则有所上升。团队既可以比较两个不同时间段的指标,也可以考察一段时间之内指标数据的变化趋势。


通过累积流图理解利特尔法则

累积流图还直观呈现了在制品数量、前置时间、交付速率三者之间的关系。它们可以简单的表示为:“前置时间 = 在制品 / 交付速率”,这也被称为“利特尔法则“[1]。如上图所示,我们看到当交付速率不变时,降低在制品数量,将同比例的缩短前置时间。

累积流图也可以特定阶段

以上的三个指标,还可以针对单个阶段或部分阶段来衡量。上图中,我们标记了实现阶段的相关指标,包括实现中的在制品、平均周期时间和完成速率;同时,图中还标记了把上线阶段去除后的这三个指标,它来自实际的应用场景:团队暂时还无法改变定期发布上线的模式时,关注能掌控阶段,对改进的实际指导意义更大。
1.2.2 用累积流图分析团队协作和交付模式,并发现改进机会

累积流图同时具备整体性和动态性,它既反映了团队整体的协作模式,端到端的动态交付过程,同时还反映了交付模式和交付能力的变化趋势。我们可以从累积流图中,分析团队的协作和交付模式,并发现改进机会。

从累积流图中发现协作模式

让我们看具体实例。从上面的累积流图中,我们可以看出:

1)团队的计划模式。最上方的淡红色区域(就绪戏曲)的上沿呈阶梯状,反映了团队需求计划的模式。开始时阶梯较宽,团队每两周做一次计划——选择一批需求进入就绪队列,等待开发;后期团队改成了每周一次计划——选择更小批量的需求,进入就绪队列,图中的阶梯变小,这一变化也带来了正面的结果,在制品数量变低,前置时间缩短。

2)需求转测试的模式。蓝色区域(测试中)的上沿线反映的是需求转测试的模式,它一开始呈现明显的阶梯状,反映需求是批量移交测试的。这带来的问题是,开发完成的需求,要等待较长时间才开始测试,导致更多在制品,并延长了前置时间。后期,团队移交模式改成小批量即时移交后,图中明显看到了,在制品数量的减少和前置时间的缩短。

3)需求发布模式。绿色区域的上沿线反映需求发布(上线)模式,它呈现阶梯状,反映需求是定期上线的。开始时是每月发布一次,需求等待上线时间较长,后进化为每两周一次上线,等待时间随之缩短。

从累积流图中分析问题和瓶颈

再看一个例子,上图能够帮我们分析团队的主要瓶颈和问题。我们看到,3月25号左右,团队一次计划了很多需求,并同时开始实现,在制品积压在实现阶段,直到4月25日左右才集中完成。批量开始,批量完成,这是典型的小瀑布开发模式,往往带来赶工和质量问题。

我们再看后期,图中我们明显看到蓝色的区域在扩散,表示测试阶段的需求出现积压,不能即时交付,成为瓶颈,团队应该进一步分析背后的原因。
累积流图记录和呈现了团队协作和价值交付模式,从中我们还可以分析出更多或更深层次的问题,指引团队改进,和衡量改进效果,它应该成为每一个精益敏捷开发团队的改进分析工具。

二. 控制图

控制图也是一个常用的综合性度量,它是一个散点图,每交付一个需求,标记一个点,横坐标是该需求的交付日期,纵坐标是该需求的前置时间。控制图常用于反映一个过程是否处于受控范围,因此被称为控制图,在这里它反映需求交付的状况,如:前置时间的波动情况和趋势。上一篇已经介绍过控制图的单独使用,这里再看一下它与其它图表的结合运用。

控制图与其它图表的综合应用

上图是三个度量图表的组合,最上面的是控制图,中间是简化了的只包含开始和结束的累积流图;最下面的是在制品数量随时间变化的曲线。综合这几幅图,可以做更深刻的分析。让我们一起解读。

从图表中,我们看到了明显的迭代开发模式。控制图中需求的交付明显按迭代分群;累积流图中,计划和交付也都呈现出周期性;而在制品数量在迭代开始时最高,在迭代结束时趋向于0。这三幅图相互印证,更全面地反映了迭代交付的状况。

我们看到,在迭代结束时往往有很多需求集中交付,这意味着赶工,相比更均匀的交付,会引起更多的潜在质量问题,从累积流图中也可以看到类似的信息。

我们还看到很多呈45度线排列的点(在图中用红色虚线做了标记),这些都是在迭代初期集中开始的需求,每晚一天结束则前置时间长一天,所以呈45度排列。再针对性地看累积流图,的确大部分需求都在初期共同开始了,而在制品数量趋势图告诉我们,在制品最高超过20个,团队应该思考,”我们应该让所有的需求一起开始吗?可以更好的控制在制品吗?“。

集合这些图表,我们还可以看到更多的信息。比如,图中红色圈内的需求,它们在迭代前期交付,但前置时间特别长,那是上一个迭代遗留的需求,在累积流图和在制品趋势图中也能看到这一信息。再如,最后两个迭代,团队开始刻意控制在制品,在制品数量降低到10以下,四十五度线也消失了,交付变得更加均匀,前置时间也明显缩短。

上面只是一个例子,现实中开发模式多种多样,综合这些反映价值流动的图表,可以分析和发现更多的模式、问题和改进机会。

三. 前置时间分布图


前置时间分布图
前置时间分布图是另一个常见的精益度量图表。如上图所示,它是一个柱状图,用以统计一段时间内,前置时间的分布状况,横坐标是前置时间(天数),纵坐标是前置时间为该值的需求的个数。前置时间分布图信息量相对较少,但它有两个独特作用。

一方面,它为团队的对外承诺,提供了客观依据。团队可以根据过去实际交付的前置时间分布,做出客观可靠的承诺——承诺后的需求多长时间可以交付。

前置时间分布图,为改进提供了方向性指导

另一方面,前置时间分布为团队的改进方向提供了依据。如上图所示,前置时间分布形成曲线,从这一视角,团队的改进可以分为:1)截尾:减少前置时间特别长的异常点。这通常需要团队提高风险管理的水平,并即时有效地发现和处理问题;2)瘦身:减小前置时间分布的方差,让前置时间更加集中和稳定。这通常需要更好的需求拆分、沟通以及更好的团队协作和风险应对; 3)左移:减小前置时间的均值。这通常需要更好的控制并行和批量,并改进协作、技术能力和基础设施以加快交付速率。

从前置时间分布中可以识别改进方向,但它信息量相对较少,相对控制图它压缩了时间维度。具体的问题的分析,则可以回到控制图和累积流图等信息更丰富的度量工具。

总结

以上我们介绍了看板方法中的度量反馈体系,与其它方法或框架中的度量不同,看板方法的度量体系以端到端的价值流动为核心,它内嵌于价值流动当中,即时和系统地反映了团队整体交付过程,为团队的系统改进提供了重要的反馈。


原创:何勉

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?立即注册

x




上一篇:你对软件测试知多少?
下一篇:精益看板方法从理论到实战之发布规划会议
monicazhang

写了 2297 篇文章,拥有财富 12859,被 21 人关注

您需要登录后才可以回帖 登录 | 立即注册
B Color Link Quote Code Smilies

成为第一个吐槽的人

Powered by IT 运维管理
返回顶部