敏捷开发的燃尽图怎么画_敏捷开发燃尽图 - CSDN
  • 白话SCRUM 之四:燃尽图

    千次阅读 2017-11-02 10:23:08
    Burn down chart翻译为燃尽图或燃烧,很形象,是Scrum中展示项目进展的一个指示器。我一直认为用户故事、每日站立会议、燃尽图、sprint review、sprint retrospective真是越琢磨越有味道的好东西,也因此很喜欢...

        Burn down chart翻译为燃尽图或燃烧图,很形象,是Scrum中展示项目进展的一个指示器。我一直认为用户故事、每日站立会议、燃尽图、sprint review、sprint retrospective真是越琢磨越有味道的好东西,也因此很喜欢scrum这种方法,这些实践简单有效、经典!

        燃尽图的样例如下:

     

        横坐标为工作日期,纵坐标估计剩余的工作量,每个点代表了在那一天估计剩余的工作量,通过折线依次连接起所有的点形成为估计剩余工作量的趋势线。另外还有一条控制线,为最初的估计工作量到结束日期的连线,一般用不同的颜色画上边的两根线。

        对此图的研判规则如下:

           (1)如果趋势线在控制线以下,说明进展顺利,有比较大的概率按期或提前完工;

           (2)如果趋势线在控制线以上,说明有比较大的概率延期,此时需要关注进度了。

        注意,趋势线并非一直下行,也有可能上行,即发生了错误的估计或遗漏的任务时,估计剩余的工作量也有可能在某天上升了。

        每天开完15分钟站立会议后,由scrum master根据进展更新燃尽图。第1个点是项目最初的工作量估计值,第2个点是第最初的估计工作量减去第1天已经完成的任务的工作量,依次类推计算后续的点。任务完成的标志是什么呢?准则如下:

          (1)开发人员检测:所有的单元测试用例都通过;

          (2)Product owner检测:Product owner通过了所有的功能测试;

        燃尽图最好是张贴在白板上,让每个人项目组成员抬头就能看见,这样给大家一个明确的视觉效果,每个人随时都能看到我们离目标有多远。

        燃尽图可以每天画,表示完成某个迭代的进展趋势,也可以某次迭代结束的时候画,表示完成整个项目的进展趋势,此时横坐标就是迭代的顺序号。

        燃尽图和传统项目管理理论中的挣值图比较起来更加简单、直观,这种设计深得管理的精髓!度量的精髓!真是让人佩服!

    展开全文
  • 敏捷开发之“燃尽图之谜”

    万次阅读 2009-11-20 17:38:00
    敏捷开发之“燃尽图之谜” 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条原则之一是: “最佳的体系结构,要求和设计来自自组织团队,”但是...

    敏捷迭代燃尽图

    敏捷实践,对于那些刚起步且知识不足的人,有时可能会作为临时软件开发和项目管理方法而出现。 真相大相径庭。

    敏捷软件12条原则之一是: “最佳的体系结构,要求和设计来自自组织团队,”但是大多数采用敏捷实践的组织(包括scrum和看板)强制执行一些重要的流程严格性和要求。 例如,许多组织实施敏捷计划实践,包括故事点估计体系结构标准和发布管理准则,以改善业务影响,应用程序版本的质量和可靠性。

    [了解您的企业如何在敏捷开发中脱颖而出 | 将您的敏捷职业提升到新的水平: 如何提高您的Scrum Master技能 | 不确定“敏捷”的真正含义是什么? InfoWorld 解释了敏捷方法 | 通过InfoWorld的App Dev Report新闻通讯了解编程方面的热门话题。 ]

    大多数团队选择使用诸如Jira Software或Azure DevOps之类的敏捷工具来管理积压,冲刺和敏捷团队之间的协作。 这些工具的主要目的是集中管理敏捷团队成员和多个敏捷团队之间的需求,冲刺状态,工作流和协作。 但是,组织使用这些工具的严谨程度越高,这些工具越能帮助领导者和团队识别问题,向利益相关者报告状况并改善其执行力。

    最常用的现成报告之一是燃尽报告。 由于敏捷实践使产品所有者可以根据客户的反馈来重新安排积压的优先次序,因此传统报告(如甘特图)无法捕捉到敏捷执行的流动性。 燃尽图的基础是它说明完成的工作,添加到合并范围的新工作以及其他合并范围更改。 燃尽图可以快速了解团队如何朝着自己的目标迈进。

    阅读基本的冲刺燃尽图

    燃尽图通常在x轴上有时间,而在y轴上有估计。 许多团队估计故事点 ,但是许多敏捷工具可以按故事数或小时数估计来绘制燃尽图。 对于本文,我假设使用的是故事点。

    冲刺燃尽报告将绘制时间间隔范围内的故事点数。 团队完成故事后,图表将显示他们如何“消化”故事列表和其他类型的工作(Jira中的问题,Azure DevOps中的工作项类型),直到工作完成或冲刺结束。 当团队完成提交给冲刺的工作时,绘制的线与x轴相交,表示一切都已完成。

    冲刺燃尽是最容易概念化的。 在冲刺的第一天,团队将提交一些故事以及故事点的总数。 如果您查看当天的燃尽图,您会在y轴上看到一个点,代表团队在冲刺第零天所承诺的点数。

    当故事被标记为完成时,冲刺燃尽显示剩余的点数要完成。

    在实践中如何使用冲刺燃尽? 健康的燃尽显示线性且理想的指数曲线下降到零。 如果曲线在冲刺的早期阶段具有平坦的斜率,则可能表明存在障碍或大量工作正在进行中,并且冲刺可能处于危险之中。 如果对代码完整的故事执行大量测试,并且直到冲刺的最后几天才开始测试工作,那么扁平化或缓慢倾斜的燃尽可能会成问题。

    快速减少sprint消耗通常是一件好事,但它可能表明该团队的承诺不足或仅选择承担sprint中较小的故事。

    史诗般的燃尽追踪业务和技术驱动因素的进展

    Sprint消耗对于跟踪短期执行情况非常有用,并有助于团队成功履行Sprint承诺。 为了更好地跟踪长期目标的进度,史诗和发行版的精简版提供了所需的可见性。

    当团队定义了一些长期的工作,例如实施主要的最终用户功能,技术债务策略,性能改进或流程改进时,史诗般的燃尽效果最佳。 要利用史诗般的燃尽,积压的订单应具有:

    • 5至15个史诗级影片,将持续至少几个月,并需要完成6个或更多的冲刺。
    • 在史诗之下卷起的功能,故事和故事存根 ,代表着在史诗上执行的高级计划。
    • 高级估算,理想情况下是针对史诗级以下累积的每个故事或故事存根的故事点。

    一旦这些就绪,史诗般的燃尽便会绘制出该计划的变更图表。 它的x轴表示冲刺,而y轴表示分配给史诗的故事和故事存根的总估计。 Jira Software的史诗般的燃尽图中 ,您会看到一个条形图,其中一种颜色表示在sprint中完成的故事,另一种颜色显示添加的故事点。 当将新故事或故事存根添加到史诗中或估计更改时,故事点会增加。

    使用史诗般的燃尽图有几种方法:

    • 它说明了根据计划完成功能和故事的速度。 当计划准确且团队速度一致时,它可以提供史诗工作完成时的指示器。
    • 大多数敏捷计划尚不完整,团队会根据最终用户的反馈,发现技术复杂性并解决在旅途中引入的技术债务来添加,更改和删除故事。 史诗式的燃尽然后根据积压的增长量与逐个冲刺完成的数量来指示该史诗的计划有多远。
    • 史诗般的燃尽还有助于跨多个sprint进行基准测试,并评估一个史诗与其他史诗之间完成了多少计划和交付工作。

    版本燃尽通知团队是否发布会影响日期和范围

    通过持续集成,持续测试和持续交付使交付管道完全自动化的高级团队可能不需要发布摘要。 经常部署的团队应该跟踪与发行版相关的功能和故事,但是发行版燃尽并不是很有用,因为它经常按冲刺来跟踪进度。

    对于遵循发布管理惯例并标准化多冲刺发布的其他团队,发布燃尽可能是产品所有者和团队最重要的工具。

    发布燃尽与史诗燃尽相似,除了跟踪分配给史诗的功能,故事和故事存根以外,发布燃尽显示分配给发布的内容。 然后,轴和条与史诗般的燃尽相同。

    因此,使用发行版燃尽的团队可以跟踪发行的范围和时间表。 步入正轨的团队将看到燃尽线向下倾斜到x轴,且倾斜度与团队的速度一致。 可能偏离轨道的发行版可能比完成的发行版具有较小的斜率,或者描述了添加的故事点更多(当向发行版添加更多范围时)。

    Jira Software可帮助您实现这些预测。 假设团队已经在该项目上进行了至少三个冲刺,那么Jira Software将计算团队的平均速度,并基于该速度来预测发布的最终冲刺。

    冲刺,史诗和发布的燃尽为团队提供了一些易于使用的工具,以实现目标。 当团队对范围有共同的了解,就优先事项达成共识,提前计划几个冲刺并在待办事项中适当地标记故事时,燃尽的故事就说明了计划和执行是否符合目标。 如果不是这样,则它们是一种数据驱动的工具,可以引发有关可能需要进行哪些调整的讨论。

    翻译自: https://www.infoworld.com/article/3453357/3-agile-burndown-reports-and-how-to-use-them.html

    敏捷迭代燃尽图

    展开全文
  • 用Excel做敏捷项目中的燃尽图

    万次阅读 2013-08-14 00:21:52
    用Excel做的,呵呵,喜欢的可以下载:

    用Excel做的模板,呵呵,喜欢的可以下载:

     http://vdisk.weibo.com/s/d1D1FAHDafBb


    展开全文
  • 敏捷开发日常跟进系列之二 燃尽图(中)
  • 敏捷开发日常跟进系列之二:燃尽图(中)

    万次阅读 多人点赞 2012-04-30 11:30:24
    这是敏捷开发日常跟进系列的第二篇(栏目目录)。迭代及燃尽图的目标燃尽图的目标是完成迭代的目标,迭代的目标是什么呢?1. 按产品经理的要求,交付计划会中计划的用户故事2. 尽量完成1之后还会看到,这个定义还有...
  • 迭代燃尽图画法小议

    千次阅读 2016-08-06 21:29:11
    在早期的Scrum培训中,燃尽图的典型画法如下: 1,在Sprintd的第一天,识别所有任务的工作量,常常使用理想工时作为单位,缩写是IMD,全文是ideal man day,这样得到燃尽图的第1个点 2,以后每天跟踪各个任务未...
  • 在运用敏捷的公司中,...其中有一种弯曲的曲线,叫做:燃尽图,它在我们的项目中扮演着非常重要的角色,可以反映当前冲刺执行情况、进度及风险等。这也是每一位敏捷教练及团队成员都需要能“读懂”的。那么问题...
  • 很多时候,我们感觉什么都没干一天就过去了,但对领导者来说,事情最好已经提前做完了,而且是越快越好。聪明的管理者知道,“时间”是需要花大功夫去把控的...燃尽图就是用来反映此类项目数据的工具,常用于敏捷软...
  • 早先读研的时候也课程有关敏捷开发主题的,我想大部分从程序员起家的IT从业者都不会彻底抛弃软件开发和设计工作的,或者说您所从事的工作之内容或多或少都会与开发设计工作有关系, 无意间看到了下面的博文,所以...
  • SCRUM-燃尽图

    千次阅读 2012-10-17 09:23:34
    敏捷开发之“燃尽图之谜” 敏捷开发之“燃尽图之谜”   1  燃尽图的起点是迭代当天还是迭代前一天? 2  用工时还是故事点来计算剩余工作量? 3  ...
  • 燃尽图

    千次阅读 2013-03-23 21:01:40
    燃尽图,英文名称是Burndown Chart,所以中文翻译成“燃尽”,这个翻译比较符合字面意思,那它实际为什么叫燃尽图呢?       燃尽图是对于工作完成情况以及趋势的一个可视化表示,在正常的迭代中,必然会随着...
  • 在运用敏捷的公司中,...其中有一种弯曲的曲线,叫做:燃尽图,它在我们的项目中扮演着非常重要的角色,可以反映当前冲刺执行情况、进度及风险等。这也是每一位敏捷教练及团队成员都需要能“读懂”的。那么问题...
1 2 3 4 5 ... 20
收藏数 589
精华内容 235
关键字:

敏捷开发的燃尽图怎么画