敏捷开发之“燃尽图之谜”

 

敏捷开发之“燃尽图之谜”

 

1     燃尽图的起点是迭代当天还是迭代前一天?... 1

2     用工时还是故事点来计算剩余工作量?... 2

3     只统计开发任务还是包括测试呢?... 3

4     测试Story就是不能关闭?... 4

5     中途加班如何控制?... 5

6     进度变动怎么办?... 5

7     敏捷工具自动画燃尽图可信吗?... 6

 

我们在进行敏捷开发的时候,一般都要画燃尽图,在我们理想的思维里面,燃尽图很明白易懂的,而实际使用的时候,你慢慢发现不是这么一回事,这究竟是怎么回事呢?

1         燃尽图的起点是迭代当天还是迭代前一天?

画的燃尽图的起点是迭代开始当天,还是迭代前一天呢?终点是迭代结束当天,还是迭代结束的下一天呢?我们通过敏捷管理工具JIRA观察,发现JIRA工具将启动设置为迭代开始当天,而结束点设置为结束的下一天。如下,迭代周期为20091020号到20091116号,而燃尽图的起点设置成了1020号,结束点设置成了1117号。

燃尽图

由于JIRA是一个自动统计工具,所以这样画没有问题,但如果是我们手工画燃尽图呢?一般来说,我们画燃尽图,有两个时间点,一个是在早上,一般是干活之前,一个是在晚上,或下班前。我比如说在21号早上(或20号晚上),我们一般的习惯是会标志上20号的那个点上,而不是标志在21号上,否则可能让人觉得奇怪,为什么21号还没有过,就开始给它画上点呢?所以,应该说,手工画图,更合理的方式是设置起点为迭代开始的前一天,终点为迭代结束那天。

2         用工时还是故事点来计算剩余工作量?

JIRA工具提供两种燃尽图,其实就是纵轴计算单位的不同,一种是用工时来统计,也就是工作量的小时数;一种是用issue来统计,也就是还剩下多少个故事。

我们细心分析,就会发现这两种统计方式都是存在问题的。用工时来统计,这是我们一般常用的方法,但工时准确吗?根据我开发这么多年的经验,一般在开发初期估算出来的工时,不是一般的不准确,而是很不准确,开发人员一般带有很严重的乐观倾向,总觉得做某个事情很easy,两三天就搞定,结果一周还没搞定,加上敏捷开发需要测试和问题修改等,结果工时是严重的不准确。另外,工时的统计量过分细化,很难精确量化,比如说,昨天剩余900小时的工作量,今天5个人,每个人干了8小时,那今天就剩下860小时的工作量了?你如果这个统计,那好,你的图形基本是和符合燃尽图的虚线了,你却发现,工时用完了,还有大量的工作量没有完成了。比较合理的做法,是我们每天再来统计剩余工作的工作量,如果是用工时,那光统计工时都很耗工作量了,而且问题是,如何统计呢?这能靠开发人员嘴上说说,然后管理员一顿狂计算。从这点来说,人天还好一点,只是工时仍然是一个不准确的值而已。

issue来统计,你会发现更离谱,因为每个issue的工作量不一样,相差还挺大,而且,一般来说,issue都是比较粗粒度的,如果按照issue来统计,你会发现一连很多天,可能都是一条横着的线。

所以我建议采用故事点做为纵轴,所以故事点,是一个虚拟的基准单位,是用来做相对统计的,比如说,我估计一个迭代中大概有30个故事点的工作量,那这30个故事点大概是多少人天的工作量呢?对不起,不知道,但我可以在迭代前给你一个大概估算的值,比如说,我估算了1个故事点大概是4人天,那30个故事点就是120人天的工作量了。好了,在迭代二,假设4个人开发了一周,也就是花了20人天的工作量,照理说应该完成5个故事点的工作量,结果发现只完成了3个故事点的工作量,那好,我马上修正每个故事点工作量的估值,我们初步定成6人天,那么30个故事点就变成180人天了。

故事点的大小要计算合适,我建议是以半天到一天(不是一人天)做为大概的估算点,比如说,4个人开发,那一个故事点大约包含48人天的工作量,那么我们每天画图能够平均往下画1~2个故事点,太多了觉得统计麻烦,太少了觉得每天都没有变化。

3         只统计开发任务还是包括测试呢?

敏捷开发其实是以故事为单位的,它的一个完成过程是包含了设计、开发、测试、返工的,那么我们画的燃尽图是应该包含这4部分,还是只有开发呢?你可能会脱口而出,认为肯定是包含4部分的,而实际使用中,你可能发觉并不是这么一回事。

下面是著名的《硝烟中的SCRUM and XP》一书中提到的处理迭代关系的一种方法,

它的意思大概指:我们在迭代一完成后,即进行迭代二的开发,迭代二中间优先处理迭代一发现的Bug

测试在迭代中的位置

 

仔细观察上面的过程,上图的红色部分,其实是迭代一的测试和返工部分。这其实是在告诉我们,迭代一的真正结束时间,其实是1.01那个点,而不是1.00,而我们如果以1.00做为结束点的话,那么必然是到最后结束点的时候,我们的燃尽图是不闭合的。如果你硬性将设计、开发、测试、返工都画到燃尽图中,那么比如画出的燃尽图,必然往上偏离参考线,那么以这个做为调整工作量的参考,还有意义吗?

然后在看最后一个迭代,它跟上图的迭代一不一样,它除了需要处理上一个迭代的Bug之外,还需要处理本迭代的所有Bug,因为已经没有迭代可以继续处理Bug了。

所以,比较合理的方案,我觉得应该是这样的,迭代一去掉上面红色部分的工作量;迭代二则加上红色部分工作量,去掉划到迭代三的工作量;最后一个迭代只加上上个迭代测试返工部分的工作量。

这里还有一个问题,就是设计的工作量,设计工作并不是有开发人员完成的,而是由设计人员(架构师、分析师等)在迭代开始之前就完成了的,我们把这个迭代开始前进行的设计工作叫做迭代0。如果是这种方式的话,我们在迭代中就不应该统计设计时间。

这里还有问题,迭代一的时候,前期开发人员在做设计开发工作,测试人员投入就少,后期随着故事一个一个被开发出来,测试投入的工作量就大了,那么其实迭代一的图形,理论上的参考线应该不是一条直线,而是一条微微向上突的曲线才对。

 

4         测试Story就是不能关闭?

上面说了这么多,但说到测试,头就大了。对于开发,我们可以估算今天开发了1/5,明天开发了2/5,到了周末,功能开发出来了。而对于测试呢,一切数据均是虚幻,你不知道测试情况如何,测试出来的问题单少,可能是版本的质量好,也可能是测试不充分,它很难找到一个衡量测试效果的方法。另外,敏捷开发是按照故事来进行的,对测试来说,如何保证这个测试的充分?比如说,预计某个故事需要测试1周,那好,开发完成了,将故事移交给测试人员测试了一周了,没有发现问题了,那么是不是这个故事就可以关闭了呢?我假设关闭了故事点,那后续这个故事还能不能测试呢?很可能这一周中,测试人员就对这个故事没怎么测试,然后你满心欢喜,以为质量很好,哪知道,等转SDV测试后,却发现测试部开始大量提交这个故事的问题单了。

另外,一般认为不能对测试逼得太紧,太紧了,很可能会导致测试不充分。

那么,是任由故事迟迟不关闭,一直处于测试状态吗?还有啊,测试发现问题,需要开发人员返工,然后测试又进行测试,这个周期经常很长,导致故事点经常是处于“测试中”。

我觉得,其实这相当于一个长尾理论,前面的测试工作很集中,而后面则拖着一个长长的尾巴,我们可以定一个范围,比如说测试完成了90%,则转入关闭状态,这样就可以把后面的尾巴砍断了。如果对这个尾巴还不放心,我们还可以设置一种状态,比如说叫“测试验证状态”或“后续测试状态”,主要测试工作完成后,就可以进入这个状态了。

另外,测试工作总是跟随在开发后面的,开发完成一个故事后,测试才能真正对功能进行测试,这就导致测试的工作是无法平均分配的,有时无东西可测,有时一大堆测试任务。针对这种情况,首先是开发的计划需要做得比较合理一点,尽量不要把所有故事都在同个时间完成;另外,测试人员最好能够动态调节,把测试人员分为两部分,一部分是纯粹的测试人员,一部分则是由开发人员承担,在测试任务比较空闲时,开发人员做开发人员,在测试任务比较忙时,部分开发人员则承担起测试的任务。

 

5         中途加班如何控制?

因为燃尽图是一开始就画出了时间点,所以如果出现中途加班的情况,那是没有办法,当天的燃尽图就不用画了。

6         进度变动怎么办?

一般的说法,敏捷开发的进度是固定的,是不能变动的,但是在中国,啥事都可能发生。如果进度变了,我们可能有下面几种方法来解决:

1、  重新那张纸来画刻度。

2、  原先的刻度就不是画上去的,而是拿着橡皮筋别上去的,现在重新移一下

3、  弃用燃尽图

 

7         敏捷工具自动画燃尽图可信吗?

JIRA这样的工具,都是能够自动画出燃尽图的,不过嘛,我觉得,这样的燃尽图根本是没有作用的,理由如下:

1、  燃尽图需要每位员工的很忠实的记录工作日志,少记、不记都将影响到燃尽图的效果

2、  工作日志是写在每个故事上面的,这样就会少记很多工时,比如说,8个小时中,有6个小时是处理某个故事的,有2个小时是处理邮件、接电话等,我们在故事写上真实的时间,往往比我们真实的会少。

3、  燃尽图中途增加本来已经计划过的故事,结果的图形会往上走。

 

最重要的一点,就是燃尽图本来就是比较容易统计的一个指标,按照JIRA等工具进行统计,结果往往是花了很大的力气,图形的走势仍需是千奇百怪,无法正常知道开发。还不如在每天晨会的时候,花点时间了解大家的完成情况,就可以画出一个正常的燃尽图了。

 

 

阅读更多

扫码向博主提问

阿源

非学,无以致疑;非问,无以广识
  • 擅长领域:
  • Java
  • 敏捷开发
  • 大数据
  • 项目管理
  • 系统架构
去开通我的Chat快问
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页