软件项目管理——燃尽图

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

clipboard

燃尽图用来观察项目过程中完成的实际工作量与剩余时间的关系。燃尽图的纵轴可以是整个项目的剩余的任务，也可以是个人剩余的全部任务。

燃尽图实例分析
本项目采用燃尽图（Sprint Burn-down chart）对迭代进展进行监控及趋势分析，各燃尽图根据Sprint backlog每日的更新数据由EXCEL自动绘制。

燃尽图横坐标：工期。

燃尽图纵坐标：sprint 内工作任务的总承诺工时。

计划曲线：假定成员工作生产率恒定情况下的进展曲线。

实际曲线：实际进展曲线。

Spring_1分析：

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

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

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

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

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

Spring_2分析：

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

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

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

Spring_3分析：

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

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

Spring_4分析：

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

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

几幅燃尽图只是实际敏捷开发项目中节选的几个SPRINT燃尽图，关于后续的敏捷实践记录

转载于:https://www.cnblogs.com/linliaimeili/p/5860453.html