“燃尽图”--保持项目可视性
“燃尽图解释与表示方法”
燃尽图，在Wiki上面没有单独的解释，只有在Scrum上面对其有基本的解释，燃尽图
燃尽图（burn down chart）是一个公开展示的图表，显示当前冲刺中未完成的任务数目，或在冲刺订单上未完成的订单项的数目。不要把燃尽图与挣值图相混淆。
A burn down chart could be flat for most of the period covered by a sprint and yet the project could still be on schedule.
我找寻了几张燃尽图，比较具有代表性意义：
手工燃尽图
详尽“燃尽图”
中国原创的说法：燃尽图（burn down chart）是在项目完成之前，对需要完成的工作的一种可视化表示。燃尽图有一个Y轴（工作）和X轴（时间）。理想情况下，该图表是一个向下的曲线，随着剩余工作的完成，“烧尽”至零。
燃尽图有多种表示方法与意义，每一个公司，每一个项目可能都不同，公司可以根据需要定制自己燃尽图，甚至进行特别的修饰与修改，但无论如何表示与修改，燃尽图具有一个共同的特点：就是可视性
“为什么需要燃尽图”?
上面展示的燃尽图的表示方法与意义，我们可以看到很多公司在实行敏捷过程都使用了这个燃尽图，显然这个燃尽图有它存在的合理与意义，在讨论这个意义之前，我们需要回答几个问题:
1.“燃尽图”到底谁会关注？
2.“燃尽图”需要谁去填写？
3.“燃尽图”应该如何填写？
上面这三个问题留给读者先去思考，随着后面章节讲述，上面三个问题会得一解决，读者可以带着以上三个看这篇文章，希望在读完文章之后，读者会自己答复以上三个问题。
“燃尽图”展示了一种新的管理工作报告，他向管理者与利益相关展示了目前产品BackLog完成情况与整体进度，管理层与利益相关者可以很容易地通过燃尽图了解实时的进度以及细节，管理层更能够实时把握产品的进度并做出正确的决策，并且预计风险，同时随时调整计划。
传统的项目报告一般是固定，系统的，向管理者展示了项目的进展，完成百分比，以及遇到的问题，需要解决与补救的方法，而实际上在开发过程当中，又会有不断的需求加进来，这种传统的项目报告无法应对这种需求，导致往往项目执行者将项目的失败都归咎于需求的增加与变化，并且责备管理层不能做出正确决策。
如何去向应对变化以及让管理层与利益相关者做出相对比较正确的决策，就需要项目执行者向管理层与利益相关者展示项目细节，其必须具备可视性，可信性，可估量，充分展示项目执行的细节，而燃尽图可以解决这样的问题。
“什么样的燃尽图可以达到效果”
在文章开始，我们已经解释了燃尽图，并给出表示方法，可惜我们不是寻找一个包装得很好看的图表，而是寻找一种方法去解决项目当中的问题，燃尽图可以帮我们解决问题，它是一种方法，必须达到某种效果，如果甘特图也可以帮到我们，我们同样也会利用。因此我们在乎的它产生的效益与成果。
那么我们应该先想好燃尽图应该具有什么样的效果？或者说如何解决传统
项目当中无法解决的问题？
前面讲到传统项目的报告往往比较迟纯，不能够及时调整，并且一旦需求一变，项目失败的机率就会增加，往往管理者决策的时候已经无法补救，另外管理者很难看清他投资的效果。因此我们可以要求燃尽图必须具备以下几种效果：
1) 具备可视性，直观展示项目进度与BackLog完成情况
2) 具备风险预估，提醒管理层与利益相关者目前完成情况，瓶颈出在哪
里？
3) 具备可估量，直观显示当前项目需要的时间
“如何绘制燃尽图”
燃尽图必须与整个项目的进展紧密相关，敏捷当中整个项目围绕着整个Sprint Backlog，因此燃尽图必须也体现着Sprint Backlog完成进展。设计燃尽图必须围绕着Sprint Backlog。
本章重点解释燃尽图，对Sprint BackLog作一下简单的介绍。
关于Sprint BackLog（冲刺订单）的介绍：
Wiki当中的解释：冲刺订单（sprint backlog）是大大细化了的文档，包含团队如何实现下一个冲刺的需求的信息。任务被分解为以小时为单位，没有任务可以超过16个小时。如果一个任务超过16个小时，那么它就应该被进一步分解。冲刺订单上的任务不会被分派，而是由团队成员签名认领他们喜爱的任务。
一般情况下，Sprint BackLog是一张表格，里面详细列出本轮迭代要实现的Story故障以及Task，并对每一个Task估算都团队成员估算过了，并且在迭代开始之前，已经决定哪些Story准备开发，从Sprint backlog基本上可以计算出总的工作量和需要人的人力。以下是例图
因此，绘制燃尽图需要先得到整个SprintBackLog的周期，总工作量，并且得到理论计划的燃尽曲线，以便与实际的燃尽图像成正比。
为了能够体现Story与Task完成情况下，一般情况下，会在燃尽图上面作细节描述，比如会在完成点上面写明是某个Story完成或者延迟。而这种添加了细节了燃尽图一般不宜手工绘制，而是通过工具软件制作。如
大多数情况下，公司一般会通过一个软件将Sprint BackLog与燃尽图挂钩，并让团队成员填写，有些情况下，甚至要求团队填写实际的工作时间在上面，这样可以得出团队在项目上面投入实际时间，团队成员毕竟不可能一天工作时间完全投入在当中。因此实际的情况往往理想情况有偏差，也有可能团队成员因为估算时间过于悲观，导致任务提前完成。
“经验与教训”
在一个不成熟的团队当中，在实际操作中燃尽图填写与实际反应的情况往往偏差很大，原因有很多种，而往往这样，燃尽图可能达不到预期的效果，团队成员会对其实际意义失去信心，管理层更是，这是双方面的问题，甚至可能是引导错误的问题。
下面提出几点问题让大家去思考，有些是实际操作当中遇到的，有些是网上搜集到的。
1无法正确的填写燃尽图
在敏捷施行之初，这个问题较为严重，首先是谁去填写这个燃尽图的问题，我们知道燃尽图无法反应出任何一个人的情况，领导团队的人往往也无法明确真实的完成情况，而仅凭成员的讲解与说明得出结论，因此源头在于团队成员没有完全把握工作完成情况与估计。这在初期时比较明显，甚至对于新员工来说。
因此我认为这个问题不可避免，但我们要做的让所有成员能够认真对待Task 的完成情况，并且进行反思，树立自己的对任务的完成情况估计的信心，学会预计风险，特别是对于团队核心成员来说，这样可以让管理层对整个团队树立信息，认为成员反馈的信息是正确，并且会正视对待看到的燃尽图，这样的燃尽图才真正有意义的。
2只统计开发工作量还是测试工作量
在一个开发团队当中可能包括一个测试人员，并且开发本身有自己的测试工作量，因此燃尽图统计的应该是所有成员所有工作的工作量与完成情况，甚至有临时的Task，因此图表随时在变化，而往往这些造成某些任务无人认领的情况，因此在做Sprint backlog之时这些都应该认真考虑与完全考虑，并且填入工作量。
3中途加班与进度变动如何控制
燃尽图是一开始就画出了时间点，所以如果出现中途加班的情况，那是没有办法，当天的燃尽图可以不用画了，我们可以将此作为后续迭代回顾会议当中讨论议题。
