【week2】燃尽图

     燃尽图（burn down chart）是在项目完成之前，对需要完成的工作的一种可视化表示。燃尽图有一个Y轴（工作）和X轴（时间）。理想情况下，该图表是一个向下的曲线，随着剩余工作的完成，“烧尽”至零。燃尽图向项目组成员和企业主提供工作进展的一个公共视图。这个词常常用于敏捷编程。---来自百度百科

    功能：表示随着时间推移，剩余工作量随之减少的可视化表示工具。

    要素：X轴表示时间，Y轴表示工作剩余量，如下图所示

   在团队进行进行敏捷开发时，成员每天更新Sprint待办事项中完成任务所需时间，根据这些更新，团队某成员合计得出团队的总时间数，将这些数据放入燃尽图。燃尽图显示每日工作量的估算，直至团队完成任务。理想情况下，该曲线轨道在最后一天应该与x轴相交。有时候曲线走势看起来不错，但是实际上并不全是如此，这就是产品开发需要面对的现实。重要的是它体现了团队相对于目标的进展情况，并不是以前花费了多少时间，而是仍剩余多少工作量即团队距离目标还有多远。如果曲线在Sprint末期不是趋于零，那么开发团队就要适时调整，如缩小工作范围或者找到可以高效工作的方法，同时保持稳步前进。

燃尽图事例：

团队：总计16人。其中包括开发9人，测试4人，管理3人。根据所开发的软件系统特点，将全员分成5个小组，分别是管理组，开发组A, 开发组B，开发组C，测试组。

Sprint 周期：以2周为一个sprint迭代。从7月10日到9月17日，累计执行了5个Sprint。

Sprint_1分析：

1. 团队成员开始第一个Sprint，对于工作任务的分解掌握的不纯熟，对自身的工作生产效率不清楚。所以导致7月13日工作任务的进一步细化分解，导致实际曲线要高于计划曲线。

2.虽然，7月12日到7月18日，实际曲线高于计划曲线，但是实际曲线的趋势与计划曲线相吻合，说明团队成员的生产速率是恒定的。

3.7月19日，实际曲线回落，开发组将迭代版本提交给测试进行迭代系统测试导致。

4.最后工时仍然存在，表征成员工时预估存在问题。

5.本次sprint回顾会议上，团队成员认为“开发与测试结合紧密，版本能够及时发布与测试”

Sprint_2分析：

1. 7月25日到7月29日，趋势基本正常。

2. 7月30日，实际曲线上扬，经分析发现仍然存在任务分解的颗粒度不够问题，成员发现任务越做需要的工时越多。深层次的原因是任务在一开始分解时，由于需求，设计等原因，导致任务工时预估与实际存在较大偏差。

3. 本次sprint回顾会议上，团队成员认为“团队工作时间把握更准确”，但是“任务颗粒度需要适当，目标要明确，不存在跨迭代。任务分解需要改进”

 

Sprint_3分析：

1. 整体趋势正常，但是真实的原因是外界涌入了大量新的任务，影响了时间盒，为了保证版本交付，原来规划的一些任务进行了搁置。

2.本次sprint回顾会议上，团队成员认为“项目内部临时增加的任务较多”，需要“sprint内的任务bug需要修改；sprint外的BUG工时较多时，需要评估，考虑建立新任务”；“项目外临时任务经常加入SPRINT”。

 

Sprint_4分析：

1.8月24日，由于PB里面已领取的用户故事条目发生需求变更，导致预估工时大幅提升。

2. 本次sprint回顾会议上，团队成员认为“需求描述需要明确到位，需求上的细节变更要沟通及时，”“PB本身不够清晰，需要在sprint之前进行细节上的细化，团队每一个成员都会参与需求的分析和细化，时间与sprint并行；团队成员对需求的明确结果应一致”

Spring_5分析：

1.9月14日以后没有记录，要求团队内部应该做好记录人员的冗余设置。

2.本次sprint回顾会议上，团队成员认为“验收测试期间经常有开发小版本更新”，希望“验收期间需要更新小版本的话，是否更新及更新后的回归测试范围需要团队评审”。

   

 

  

燃尽图事例摘自漫天清凉的博客http://blog.sina.com.cn/s/blog_6bbd0d7101016ak2.html