2009-11-20 17:34:00 sunlen 阅读数 19592
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13683 人正在学习 去看看 张传波

 

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

 

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等工具进行统计,结果往往是花了很大的力气,图形的走势仍需是千奇百怪,无法正常知道开发。还不如在每天晨会的时候,花点时间了解大家的完成情况,就可以画出一个正常的燃尽图了。

 

 

2016-09-09 21:23:00 weixin_30947043 阅读数 48
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13683 人正在学习 去看看 张传波

  燃尽图是在项目完成之前,对需要完成的工作的一种可视化表示。燃尽图有一个Y轴(工作)和X轴(时间)。理想情况下,该图表是一个向下的曲线,随着剩余工作的完成,“烧尽”至零。燃尽图向项目组成员和企业主提供工作进展的一个公共视图。这个词常常用于敏捷开发(敏捷开发是指以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征)。

  功能:描述随着时间的推移而剩余的工作数量,可用于表示开发速度。

  要素:X轴:时间;Y轴:剩余工作量。

  示例:

    

 

    

 

    

      ————来源:燃尽图_搜狗百科

  

  燃尽图常见的几种情况:

  1.先鼓起后落下:原因是计划会以常常漏掉一些事情,所以开工后不但不燃尽,还发现了很多新的任务。

  2.先完美燃烧,然后突然停止燃烧:由于任务划分太粗,导致对工作量的错误估计,到最后发现余下时间难以完成。

  3.先缓慢燃烧,然后到快燃尽的时候剩下一堆没完成的任务,被推迟到下个周期:有些任务是次要的“可以不做的”,或者是被动地发现有些故事没有完成导致的。

  ……

 

  Kane Mar将燃尽图分为以下七种情况:
  1、Fakey-Fakey:表面完美而已。软件项目过于复杂以致于难以界定直观的目标。大多数情况下,这种图来自于充满了命令与控制的环境,在这种环境下,开放的交流变得难以进行。
  2、Late-Learner:燃尽图中会有一个顶峰。通常出现在沟通高效且正在学习Scrum的团队中。
  3、Middle-Learner:要比late-learner更加成熟。团队在Sprint的中期会探寻出大多数的任务与复杂性。
  4、Early-Learner:开始有一个顶峰,然后是平缓的衰退。团队认识到早期探寻的重要性,然后高效工作以实现目标。
  5、Plateau:团队在一开始取得了很大的进展,但却在Sprint的后半部分丧失了方向。
  6、Never-Never:燃尽图在Sprint的后期突然开始上扬并且不会再下降。需要尽快找到这些迟来的变化并进行自省。
  7、Scope-Increase:Sprint中的工作量突然增加。通常这表明团队在Sprint计划会议上没有完全认清工作范围。                            ————摘自:燃尽图_百度百科
 

  但是还有一些问题没办法反映出来:

  1. 有哪些故事正在做,还没有做,已经开工了但没完成;

  2. 最后剩下了哪些故事没完成;

  3. 有没有人不是一个一个完成故事,而是同时开工了很多故事。等等……

转载于:https://www.cnblogs.com/regretless/p/5858093.html

2013-01-03 14:29:26 caowenbin 阅读数 35457
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13683 人正在学习 去看看 张传波

        燃尽图(burn down chart)是在项目完成之前,对需要完成的工作的一种可视化表示。燃尽图有一个Y轴(工作)和X轴(时间)。理想情况下,该图表是一个向下的曲线,随着剩余工作的完成,“烧尽”至零。燃尽图向项目组成员和企业主提供工作进展的一个公共视图。(引自百度百科)

        一般燃尽图的样式如图所示。(图片来源《硝烟中的Scrum和XP》)

        由于燃尽图也在传达开发速度的信息,所以也有人称为速度图或速度曲线。但恰恰就是这个速度一词,触动了管理者的神经,把一个图当成了神,不仅必须要有,而且一定要准,要拿图说话。动辄就把“可视化管理”、“绩效管理”的大帽子扣到这张小小的燃尽图上。于是,一个团队日常的视图就这样成了管理者的控制生杀的工具。

        燃尽图可以用于表示开发速度,这没错。但是在分析燃尽图时还是要认识到这张图背后的一些事情。

        燃尽图描述的是随着时间的推移而剩余的工作数量。每个迭代都有很多待开发的Story,在敏捷开发中,工作量的评估是以Story为单位的,一个迭代Story的数量会影响到燃尽图的Y轴。如果Story的数量过少,绘制出来的燃尽图就会呈明显的折线形状,也会对速度和风险的判断带来影响。所以,曲线未必能真的代表剩余的工作数量。

        另外,Story的拆分粒度对燃尽图的影响很大。Story的拆分粒度越小则越能反映真实的状况。但也不是越小越好,如果将Story拆分到可以以人时为单位的工作量上,那么就会对团队的工作量估算准确度提出更高的要求,也会带来更多的角色交流成本。

        还有,多个迭代的燃尽图进行比较,并非一定能表明迭代间的变化。影响比较结果的因素有很多,比如Story拆分的粒度是否同一,团队成员是否有变化,时间周期是否一致等等,所以进行这种比较时要综合各种因素来得出结论。

        团队成员也会影响到燃尽图的描绘。当他们发现这张图还在用于绩效考核时,就会倾向于让曲线更漂亮而隐瞒真实的完成结果,或者对“完成”的标准打上折扣。也就是说,虽然燃尽图曲线到达了X轴,但实际上还有很多工作没有做,此时这种误导性就是一个陷阱了。

        所以个人认为,一个迭代的燃尽图没什么意义,持续迭代的燃尽图可以用于一些分析或数据积累,但它不是用于承载绩效考核等管理手段的工具。对于迭代周期较短、每个迭代内Story数不多、Story的粒度较大的敏捷团队,或者成员时常变化的团队,其实可以适当尝试放弃燃尽图。

——欢迎转载,请注明出处 http://blog.csdn.net/caowenbin ——

2012-03-15 14:43:29 cheny_com 阅读数 12882
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13683 人正在学习 去看看 张传波

这是火星人预览系列的第四篇(之一之二之三之四之五问答之六之七)。

之一:需求与故事结构

之二:编辑故事,产品管理,组织结构

之三:迭代,计划会,分配任务

之四:故事板,燃尽图,我的工作项

之五:常见问题问答

之六:我的空间,我的通知

之七:自定义字段

 

 

日常跟进截图

故事板:

燃尽图(具备钻取功能):

跟进表:

个人中心截图

个人中心是3月迭代的重点,所以未来会多很多功能。

我的通知:

我的工作项(新建和当前负责,可以筛选类型):

2018-07-27 09:53:14 lylmwt 阅读数 475
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13683 人正在学习 去看看 张传波

什么是燃尽图

燃尽图(burn down chart)是在项目完成之前,对需要完成的工作任务的一种可视化表示。理想情况下,该图表是一个向下的曲线,随着项目任务的逐渐完成“烧尽”至零。

燃尽图常常用于敏捷开发中,作为项目进展的一个指示器。

如何解读燃尽图

燃尽图是一个坐标图。呈现的是随着时间推移而剩余的工作量。

下面以项目管理工具中用户数量最多的 禅道中的燃尽图为例进行说明。

燃尽图的元素:

横坐标:sprint的工期(以天/日期标记)。

纵坐标:sprint项目中所有任务剩余工时的总和(以小时标记)。

计划线:理想情况下的任务进展线(上图中的灰色线),作为参考之用。

实际线:任务的实际进展线(上图中的蓝色线)。

燃尽图就是每天将项目中所有任务剩余工时的总和计算一下,形成坐标(图中的蓝色点),然后逐次把点连接起来,形成剩余工作量的趋势线。

燃尽图的解读规则:

(1)如果实际线在计划曲线以下,说明进展顺利,有比较大的概率按期完工;

(2)如果实际线在计划曲线以上,说明有比较大的概率延期,这是就需要关注进度了。

在实际sprint进程中,燃尽图的表现有多种形式,不同的呈现形式也反映了sprint中存在的不同问题。所以通过解读燃尽图可以及时发现问题,及时纠正,优化工作,按期完成任务。

燃尽图的类型解析:

1.理想型

 

 

解读:

任务准时完成,实际线围绕在计划线上下,波动不大。说明团队master对sprint的工作量评估准确,成员有序推进工作,按时完成交付。

改进:

sprint流程非常健康,基本不需改进。

 

2.优秀型

解读:

工作计划准时完成。实际线先起后降,说明前期工作推进缓慢,但在后期团队有能力根据预计的交付期调整进度,保证按时交付。

改进:

因为增加了工作量,或者对工时预计不准确导致sprint前期进度滞后,找到原因进行分析改进,团队master需要更准确的评估能力,同时考虑团队是否可以承担更大的工作量。

 

3.进度滞后型

解读:

未完成交付。实际线前期波动不大,团队按计划推进工作,但在后期进度变得缓慢,在预定交付日没有完成任务。

改进:

后期由于任务量加大导致团队进度缓慢,找到任务增加的原因,团队master应做好与producte owner的沟通工作,杜绝在sprint正常进程中加入新的工作任务。

 

4.进度超前型

解读:

任务超前完成。实际线一直低于计划线,说明工作计划不合理,任务量偏少,或工时估计过高。

改进:

团队master不能准确预估工作量,或对团队能力评估有较大偏差。应该进行反省,重新评估任务量,并对团队工作能力重新估计,适当增加任务量或减少人员投入。

 

5.任务不饱和型

解读:

工作计划准时完成。实际线低于计划线,说明团队工作量不饱和,或工时评估偏高。任务不饱和型与进度超前型同属于对工时的过高估计。

改进:

团队 mastert或许不了解团队的实际工作能力或对任务工时评估有误。如果说因为sprint进程中取消了某些任务导致进度提前完成,则需要制定更加精准的sprint的计划。

 

6.任务超量型

解读:

工作任务准时完成。实际线平稳高于计划线,说明团队工作量非常饱和,进度推进缓慢,但能准时完成交付。也说明团队经验丰富,工作能力强,可以在高强度工作状态下完成任务或者通过加班来完成超量任务。

改进:

团队master对任务量评估不准确,如果任务众多可以考虑按照优先级处理任务,或者将一些低优先级的任务挪到下一个sprint。

 

7.任务忽多忽少型

解读:

工作任务准时完成。实际线忽高忽低波动较大,说明任务量忽多忽少,最后团队能按时完成交付。也说明团队工作能力强,适应性强,可以灵活调整进度以完成交付。如果是经验不足的团队很可能无法完成交付。如果任务忽多忽少幅度大,也有可能是在sprint过程中不断增加或减少任务。

改进:

在sprint进程中经常增加任务导致燃尽图曲线波动较大,团队master应该做到相对准确的工时估计,避免在进程中不断增加任务影响正常sprint流程。

 

8.任务越做越多型

解读:

任务没有完成。实际线一直向上延伸说明任务量越来越大,工时越来越多。是非常不合理的状态。说明团队不能正确执行Scrum流程,没有按照计划推进工作,而是在不断增加任务。

改进:

由于团队master不断增加任务或需求变更等导致任务量加大,迭代失败。责任主要在于团队master对整个迭代的工作量把控不足或对成员的能力预估偏差。找到原因并严格按照sprint流程推进工作。

 

9.需求被砍型

解读:

工作计划提前完成。实际在前期正常波动,进而在某一天急转直下。说明在sprint后期由于某些原因导致了某些需求被砍掉,任务完成。

改进:

由于需求的砍掉或变更导致任务提前完成,这也是非常不健康的迭代过程。应加强与producte owner的沟通,尽量杜绝这类情况出现。

10.中途更新型

解读:

计划线开始在横轴位置,在sprint过程中上升,进而平稳下降。说明在开始一段时间内成员未更新燃尽图。

改进:

严格遵循sprint流程,团队master应该履行职责每日查看燃尽图,并督促成员更新燃尽图。

11.最后更新型

解读:

完成工作任务。实际线呈平行趋势,在交付日当天垂直转折。说明在sprint过程中成员没有进行剩余工时的更新,在截止日当天进行了完成操作。

改进:

团队成员没有按照scrum流程更新任务状态,团队master没有做好监督作用,也没有做到剩余工时的更新查看。团队master首先需要明确自身职责,及时追踪任务完成进度,带领团队成员按照scrum流程工作。

 

12.任务未做型

解读:

任务未完成。实际线呈平行状态,任务总工时没变,说明成员没有工作,或项目任务未启动。sprint完全失败。

改进:

团队不能正确理解scrum流程,严重缺乏意识,需要进行scrum流程操作培训。

13.摆设型

解读:

没有实际的任务趋势线。说明燃尽图沦为摆设,没有记录工时,没有监督。团队的执行情况不得而知。

改进:

需要进行scrum流程操作培训。

除了上述类型,其实燃尽图的呈现还有很多种形式,在这里不一一列举。

燃尽图对于sprint的流程具有非常直观的指示作用,是敏捷开发必不可少的元素。在主流的项目管理工具中,燃尽图可以自动生成自动更新,是非常方便好用的项目管理工具。

通过燃尽图了解项目进展,请参考http://www.zentao.net/book/zentaopmshelp/105.html

Scrum燃尽图

阅读数 361

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