敏捷开发燃尽图 - CSDN
  • 敏捷开发日常跟进系列之二 燃尽图(中)

    分享一下我老师大神的人工智能教程。零基础!通俗易懂!风趣幽默!还带黄段子!希望你也加入到我们人工智能的队伍中来!https://blog.csdn.net/jiangjunshow

                   

    这是敏捷开发日常跟进系列的第二篇(栏目目录)。

    迭代及燃尽图的目标

    燃尽图的目标是完成迭代的目标,迭代的目标是什么呢?

    1. 按产品经理的要求,交付计划会中计划的用户故事

    2. 尽量完成1

    之后还会看到,这个定义还有狭隘之处,在系列后面的文章中会提到。

    为什么燃尽图不能直接地达成这个目标?潜在的问题包括:

    1. 如果燃尽图按时完成,有可能是为了按时完成,同时牺牲了所有故事(重要和不重要的)的质量,换取了进度。

    2. 如果燃尽图未按时完成,有可能不是一个故事没有完成,而是所有故事都剩下点活没做完,导致所有故事都无法交付。

    3. 如果燃尽图未按时完成,没有完成的故事中,有可能包括了极其重要的一些。

    只从燃尽图的形态看,是无法提前识别这三者的,也就因此带来了很多的风险,到迭代的末尾让人大吃一惊。

    怎么办呢?

    “阶梯燃尽图”

    之前听过这个方法,但是刚才在网络上没有找到图片。

    方法就是在每个故事完成的时候才把整个故事突然剪掉,从而形成阶梯状。

    阶梯状燃烧图的缺点也很明显:刚开始的时候很难看到有燃尽,甚至那些向上拱起的弧形也被掩盖了,日后回顾时,一些细节也很难记起来。

    所以一种解决方案,是把普通燃尽图和阶梯燃尽图混合使用,就是同时画两条线。

    “跟进图”

    跟进图是一些大型团队的创造,由于团队巨大,所以不能指望在迭代的最后用2小时评审完所有工作,所以常常是做完一个评审一个,这就要给每个工作分配一个“跟进人”,他隶属产品部门,没事就盯着“跟进图”看看有没有自己关心的工作做完了。

    在为一家游戏公司提供咨询的时候,他们一款产品的团队人数高达88人(另一个甚至到了200人),墙上就用手绘制了一幅巨大的跟进图,每天更新动态,甚至直接在纸上画上小图标,每月画满了,就重新打印一张。

    下面这张,是火星人中的跟进图。

     

    图中绿色粗线,就是传统的燃尽图;

    每当一个故事完成,就会有一个蓝色的标记及完成故事的名字,从而提醒跟进人进行现场预评审;如果长期没有故事完成,燃烧图却还在燃烧,就肯定出现了之前说过的问题了。

    右下部分还有一个暗红色的细线,是“溢出时间”,就是超出预期的工作的时间,表明这段时间出现了新的任务;新任务出现的太早不好,因为一般在迭代前期都先完成最重要的故事,不应该引入新任务;但在后期随着最重要的故事完成、评审、因不满意而返工,团队会倾向于把最重要的任务更好地完成,而非草草地把所有故事都凑合完成,在产品研发中,这往往是更能提升产品价值的。

    一家叫做广联达的公司在实践中把溢出时间作为负数倒着画,称为“基线下沉”,就是说要去的地方不是0了,而是那个负数,是一个类似目的的很好的实践。

    我试了一下也不错,就是图表会变高,显示起来不方便,所以还是改了回来。

    这样的跟进图看起来已经很强大了,但是还有一些问题没有解决:

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

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

    3. 有没有人不是一个一个完成故事,而是同时开工了很多故事?(这个是最后很多故事都开工了但都差一点完成不了的主要原因)

    4. 如果有跟进人,谁负责跟进哪个?

    有些问题需要后面的故事板(看板)解决,有些则需要一个叫做“跟进表”的东西,之后我们说完故事板再回来详细说明。

               

    分享一下我老师大神的人工智能教程。零基础!通俗易懂!风趣幽默!还带黄段子!希望你也加入到我们人工智能的队伍中来!https://blog.csdn.net/jiangjunshow

    展开全文
  • 这个系列将涉及燃尽图(Burndown Chart)、故事板(看板)、每日立会等内容,描述在计划会之后,评审会之前,敏捷开发团队内部产出与产品经理和项目经理的各种活动。日常跟进中的某些内容比如团队工作模型、预估会议...

    这是敏捷开发日常跟进系列的第一篇(栏目目录)。

    这个系列将涉及燃尽图(Burndown Chart)、故事板(看板)、每日立会等内容,描述在计划会之后,评审会之前,敏捷开发团队内部产出与产品经理和项目经理的各种活动。

    日常跟进中的某些内容比如团队工作模型、预估会议、用户故事跟进等在之前的松结对编程、团队管理、用户故事、产品管理等系列中有所描述。

    在这个系列之前,还应该有一个敏捷计划系列,描述敏捷开发的从版本规划到计划会估算的详细内容,未来将会补上,当前可以参考2.29版的《火星人敏捷开发手册》,有5页与其相对应。

    燃尽图

    燃尽图Burdown Chart也叫燃烧图,是罕见的敏捷度量,以至于每当有人问起“敏捷中有度量吗”的时候,第一反应就是它。

    燃尽图的全称,应该是“总剩余时间的燃尽图”,就是本次迭代中,所有故事(或拆分的任务,以下仅称故事)的剩余时间总和,随日期的变化而逐日递减的图。

    图中左侧460是迭代开始的第一天,所有故事的未完成时间相加为460天,而在最右侧则表明在第17天,所有故事的剩余时间相加变为0,也就是所有故事都完成了。

    为什么总和会递减呢?因为每个组员每天都要汇报一件事情:当前正在做的故事,还剩余几天,如果昨天剩余3天,今天剩余2天,那么就为燃烧图贡献了1天的进度。

    由于可能出现“昨天剩余3天,又工作了一天后本以为会只剩下2天,结果感觉可能还要3天(甚至变成5天了!)”这种情况,所以燃尽图常常有一些起伏。

    燃尽图的“指纹”

    图中的燃尽图尽管有一些起伏,依然是属于比较完美的燃尽图。实际上每个团队完成迭代的过程差别很大,常见的情况包括:

    先鼓起后落下

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

    先完美燃烧,然后突然停止燃烧

    一种很常见的情况,如果任务划分太粗,比如长达10天,很容易“做了1天,剩9天;做了1天,剩8天;……到剩2~3天的时候,哎呀,好像搞不定了”。

    先缓慢燃烧,然后到快燃尽的时候剩下一堆没完成的任务,被推迟到下个迭代

    之前提到过敏捷开发的MoSCoW方法,有些故事是次要的“可以不做的”,所以这种燃烧图也很常见;但是常常有团队没有使用MoSCoW方法,只是被动地发现有些故事没有完成。

    ……

    为了改进这些不完美,有些团队设置了一些度量项来改进燃尽图的结果,比如“迭代按时燃尽的次数”“剩余故事占总故事的比例”……

    其实不用因为燃尽图的不完美而伤脑筋,在般若敏捷的“无住”中曾经提到,这些方法都非我们的目的,而只是一个中间的工具,因此为了完成我们的最终目的,这些工具和方法都可以灵活变通,而不要追求工具和度量数据本身的完美。

    但是,迭代的最终目的到底是什么呢?有哪些“灵活变通”可以应用在燃尽图中呢?且待下回分解。

    展开全文
  • 敏捷开发燃尽图

    2019-07-12 17:03:51
    燃尽图是在项目完成之前,对需要完成的工作的一种可视化表示。燃尽图有一个Y轴(工作)和X轴(时间)。理想情况下,该图表是一个向下的曲线,随着剩余工作的完成,“烧尽”至零。燃尽图向项目组成员和企业主提供工作...

      燃尽图是在项目完成之前,对需要完成的工作的一种可视化表示。燃尽图有一个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

    展开全文
  • 敏捷开发之“燃尽图之谜” 1 燃尽图的起点是迭代当天还是迭代前一天?... 12 用工时还是故事点来计算剩余工作量?... 23 只统计开发任务还是包括测试呢?... 34 测试Story就是不能关闭?... 45 中途加班如何...

     

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

     

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

     

     

    展开全文
  • 敏捷迭代燃尽图 敏捷实践,对于那些刚起步且知识不足的人,有时可能会作为临时软件开发和项目管理方法而出现。 真相大相径庭。 敏捷软件的12条原则之一是: “最佳的体系结构,要求和设计来自自组织团队,”但是...
  • 燃尽图的作用

    2019-05-08 15:35:04
    燃尽图(burn down chart)是在项目完成之前,对需要完成的工作的一种可视化表示。燃尽图有一个Y轴(工作)和X轴(时间)。理想情况下,该图表是一个向下的曲线,随着剩余工作的完成,“烧尽”至零。燃尽图向项目组...
  • 敏捷之伤——燃尽图

    2013-03-30 10:03:31
    燃尽图(burn down chart)是在项目完成之前,对需要完成的工作的一种可视化表示。燃尽图有一个Y轴(工作)和X轴(时间)。...(图片来源《硝烟中的Scrum和XP》) 由于燃尽图也在传达开发速度的信
  • 迭代及燃尽图的目标燃尽图的目标是完成迭代的目标,迭代的目标是什么呢?1. 按产品经理的要求,交付计划会中计划的用户故事2. 尽量完成1之后还会看到,这个定义还有狭隘之处,在系列后面的文章中会提到。为什么燃尽...
  • 敏捷开发日常跟进系列之一 燃尽图(上)
  • 在运用敏捷的公司中,...其中有一种弯曲的曲线,叫做:燃尽图,它在我们的项目中扮演着非常重要的角色,可以反映当前冲刺执行情况、进度及风险等。这也是每一位敏捷教练及团队成员都需要能“读懂”的图。那么问题...
  • 作者:TechExcel公司CEO兼首席软件架构师 周铁人 博士 在敏捷开发中最重要的原则之一就是使用燃尽图报表。基本上有两种类型的燃尽图报表;基于剩余时间的燃尽图,和基于剩余点数的燃尽图。基于剩余时间的燃尽图是一种...
  • 本场Chat主要介绍燃尽图的常见问题,如何通过图来解开项目背后的问题以及相应的解决方案。具体内容包括: 燃尽图画法及注意事项。 常见燃尽图错误事项。 燃尽图背后暴露的问题及解决措施。 圣略某IT项目燃尽图实例...
  • 2019独角兽企业重金招聘Python工程师标准>>> ...
  • Burn down chart翻译为燃尽图或燃烧图,很形象,是Scrum中展示项目进展的一个指示器。我一直认为用户故事、每日站立会议、燃尽图、sprint review、sprint retrospective真是越琢磨越有味道的好东西,也因此很喜欢...
  • 很多时候,我们感觉什么都没干一天就过去了,但对...燃尽图就是用来反映此类项目数据的工具,常用于敏捷软件开发中,如Scrum。它可以呈现剩余工作量和可用剩余时间,并通过可视化的图示表述繁复文字无法表述的意思。...
1 2 3 4 5 ... 20
收藏数 3,437
精华内容 1,374
热门标签
关键字:

敏捷开发燃尽图