燃尽图之辩

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

燃尽图的样例如下：

由于燃尽图是对于剩余时间的统计，所以在工作人数不变的情况下，我们其实可以通过该图推断出目前工作的大致进度与趋势，所以管理层就可以通过这个图实时把握住开发的进度并作出正确的决策，而且还可以预计风险，同时随之调整计划。所以燃尽图，无疑，对于管理层是具有非常大的吸引力的。

有许多人对燃尽图都充满了赞美之词，难道他就真的那么完美吗？下面来看一些不同的声音（来自网络）

由于燃尽图也在传达开发速度的信息，所以也有人称为速度图或速度曲线。但恰恰就是这个速度一词，触动了管理者的神经，把一个图当成了神，不仅必须要有，而且一定要准，要拿图说话。动辄就把“可视化管理”、“绩效管理”的大帽子扣到这张小小的燃尽图上。于是，一个团队日常的视图就这样成了管理者的控制生杀的工具。

        燃尽图可以用于表示开发速度，这没错。但是在分析燃尽图时还是要认识到这张图背后的一些事情。

        燃尽图描述的是随着时间的推移而剩余的工作数量。每个迭代都有很多待开发的Story，在敏捷开发中，工作量的评估是以Story为单位的，一个迭代Story的数量会影响到燃尽图的Y轴。如果Story的数量过少，绘制出来的燃尽图就会呈明显的折线形状，也会对速度和风险的判断带来影响。所以，曲线未必能真的代表剩余的工作数量。

        另外，Story的拆分粒度对燃尽图的影响很大。Story的拆分粒度越小则越能反映真实的状况。但也不是越小越好，如果将Story拆分到可以以人时为单位的工作量上，那么就会对团队的工作量估算准确度提出更高的要求，也会带来更多的角色交流成本。

        还有，多个迭代的燃尽图进行比较，并非一定能表明迭代间的变化。影响比较结果的因素有很多，比如Story拆分的粒度是否同一，团队成员是否有变化，时间周期是否一致等等，所以进行这种比较时要综合各种因素来得出结论。

        团队成员也会影响到燃尽图的描绘。当他们发现这张图还在用于绩效考核时，就会倾向于让曲线更漂亮而隐瞒真实的完成结果，或者对“完成”的标准打上折扣。也就是说，虽然燃尽图曲线到达了X轴，但实际上还有很多工作没有做，此时这种误导性就是一个陷阱了。

        所以个人认为，一个迭代的燃尽图没什么意义，持续迭代的燃尽图可以用于一些分析或数据积累，但它不是用于承载绩效考核等管理手段的工具。对于迭代周期较短、每个迭代内Story数不多、Story的粒度较大的敏捷团队，或者成员时常变化的团队，其实可以适当尝试放弃燃尽图。（http://blog.csdn.net/caowenbin/article/details/8461148）

当然，燃尽图真的这么厉害吗？其实也不一定，因为实际的开发过程中，总是会出现很多意想不到的情况，比如说某人突然请假了，或者有一个功能突然添加进来或者放弃了，或者说记录的工作时间不完整，没有包括测试的时间等等，这些都会影响到实际的数据，所以燃尽图要达到预期的效果，其实还是有很多需要考虑的东西的。

那到底怎么样的燃尽图才是好的燃尽图呢？只有解决了如下的问题以后，这个燃尽图才有其价值：

1. 记录正确的时间：燃尽图里对于每个Story或者Task的工作，需要记录真实的时间，比如一个Task有开发和测试的工作，那我们就需要把这两项工作都统计进去，这样子才能真实的反映这个Task的时间情况。
2. 对于工作的时间的预估需要尽量符合情况，这点对所有人要求都很高，因为预测数据的正确性决定了这个燃尽图预测的准备性，所以需要培养所有输入数据人员对于时间的估计能力，这个可能需要一个过程。
3. 对于中间有人缺席或者有新任务加进来的情况，燃尽图需要根据新的数据做相应的自动更新