越来越多的团队在开始使用敏捷、看板等工具来帮助解决实际问题。他们使用燃尽图、燃烧图等图形来度量项目的发布、迭代进度;作为识别工作流程中的瓶颈以及流程效率问题的有力手段——累积流图(CumulativeFlow Diagram, CFD)——也正逐渐放出光芒。
根据瓶颈法则(Law of the Bottleneck),瓶颈会在吞吐量最低的位置出现。通常情况,在这个最低位置之前会有一个队列,并且在那个环节之后环节的效率并不高。在实际生活中,这个位置就好比高速路上的收费站、高峰时段的立交桥或者机场的安检点一样。
下图是一个软件开发流程中连续周期内不同环节工作项数量统计图,并用不同颜色将这些环节区别开来。(图片来自网络)
注:右侧为左图中某一时刻所有工作项在各状态下的数量分布图
在这个图中,最下面的粽色是开发流程的终点,表示已经完成了的工作项数量。随着时间的推移,通常来说,它所占有的高度是越来越高的,也就是完成的工作项数量越来越多,不作为考察瓶颈的对象。现在观察一下,是否有一个区域在变窄,同时在流程中相对于这个环节之前的环节正在变宽(说明队列正在增长)——那个变窄的区域,就是瓶颈所在。
累积流图是一个实践工具,可以帮助我们看到WIP的状态、项目的步调、并且快速识别出交付时间存在的风险以及瓶颈。
如何处理瓶颈,可以参考《看板方法》一书。
Polarion 的Wiki可以作为一个很好的报表平台,可以在 Wiki上制作各种各样的报表。
由于Polarion内部使用Subversion作为她的存储机制,因此,可以获取自项目创建以来,任意时刻点的数据信息;其次,Polarion 的 Wiki集成了Apache Velocity技术,Polarion许多有用的工具类可以作为Velocity的变量提供,这样可以利用丰富的开放 API来获取数据;再次,Wiki集成了开源的HTML5/JavaScript Highchart 报表技术,可以通过定制的宏来生成Highchart图表。
按Highchart宏的要求读取指定时段内某些状态的工作项数量:
按Highchart宏的要求统计指定时段内各状态的记录数:
通过调用前面的两个宏,获取生成累积流图所需要的数据,然后调用 Highchart相关宏显示出来
下图就是从某个Polarion系统中获取数据生成的累积流图:
以上累积流图,是在 Polarion 中实时生成的。如果统计的数量较多,会增加服务器的负担。由于工作项的历史记录是不会发生变化的,因此,统计工作可以使用一个Polarion的调度作业来完成,利用服务器空闲时间(例如每天凌晨)来获取这些数据信息,并生成一个统计结果文件,在 Wiki中直接显示就可以了。如果需要看实时的数据,可以手工运行一次调度程序。
Polarion开放的API以及Wiki的功能,可以为企业灵活地制作各种各样的报表,按需要展示系统中真实的情况,累积流图只是其中一种展示方式。Polarion 2015版本还发布了LiveReport技术,LiveReport提供了各种用于报表开发的小部件,无须编程即可生成满足要求的报表,您还可以扩展定制出自己的小部件,形成不断丰富的小部件仓库,这对于形成软件过程度量工具库带来了丰富的想象空间!
微信扫一扫
关注该公众号