迭代燃尽图画法小议

在早期的Scrum培训中，燃尽图的典型画法如下：
1，在Sprintd的第一天，识别所有任务的工作量，常常使用理想工作人天作为单位，缩写是IMD，全文是ideal man day，这样得到燃尽图的第1个点
2，以后每天跟踪各个任务未完成的工作量，早期的工具不多，常用Excel来跟踪，并利用Excel来绘制燃尽图。跟踪部分形状如下：

利用Excel绘制得到的燃尽图如下：

为方便讨论，将此画法在本文称之为A画法。
假设一个团队有7个人，选择2周10个工作日作为一个迭代周期，那么一个迭代可以提供的总工作量是 70个人日，大概约可以处理50 IMD，如果把任务一一对应到用户故事，那么平均一个任务的工作量约是3 IMD，那么这个迭代有约16个任务。

在后来的发展中，出现了多种燃尽图画法，常见的有：
B画法，以工时为单位，即是燃烧工时，burn hours
由于IMD的最小颗粒度一般是0.5IMD，对应4工时，IMD不能支持更细颗粒度的工时，而工时作为单位，颗粒度可以到最小0.5工时，因此工时作为单位就能表现更小颗粒度的任务。
同样假设一个团队有7个人，选择2周10个工作日作为一个迭代周期，那么一个迭代可以提供的总工作量是 70个人日，560个工时，如果识别用户故事下的不同任务，平均任务工作量是8工时的话，那么有70个任务；如果平均任务工作流是4工时的话，那么有140个任务。
假设每个任务的识别和估算需要2分钟，140个任务的识别和估算就是需要280分钟。此画法的好处是便于跟踪，完成的任务剩余工作量为0，这很清晰，每天的进展反映清晰。
C画法，仍然以工时为单位，把任务估算与故事点挂钩
由于这样的识别非常耗时，一个折衷的做法是根据故事的故事点数直接估算任务工作量，比如故事点在扑克游戏中得到是3，根据历史数据，每个故事点约需要1.8工时，那么这个故事对应的任务估算工作量就是5.4工时。C画法与A画法存在相同的问题，任务一般不能在一天之内做完，因此需要对开始了但没有完成的任务进行剩余工作量的估算，这样的估算一般难以准确。
D画法，以故事点为单位，即是燃烧故事点，burn story points
燃烧故事点的好处是直接以工作对象为度量，与交付直接相关，但其弊端是当故事没有完成时，故事点是不燃烧的，故事点为单位的燃尽图在前期往往下降缓慢，头几天甚至多数情况下是平的，因而利用故事点燃尽图不能直观的预测能否按期完成所有故事。

随着看板在敏捷迭代当中的使用，比如ScrumBan、Kanban，用户故事的状态不再只有”to do”,”in progress”,”done”，常见的状态有开发，测试，状态内又能分成 doing，done，结合经典的挣值分析，迭代燃尽图有了一个新的画法，在本文称为E画法：
E画法，以故事点为单位，根据状态的完成度比例来得到为完成的故事点
1，采用故事点作为单位，给不同状态设置不同的完成度百分比，比如 开发 doing 对应 15%， 开发 done 对应 40%， 测试ing 70%， 测试 done 90%, done 100%
2，当某个故事点为5的故事进入到开发done时，其剩余故事点计为3（计算式：5*（100%-40%））

这个方法的原理是状态代表了故事开发进度的挣值，对比D画法，能够在过程中显示进展，无需等待最后完成的时候，对比C画法，状态代表的挣值比每天都人工估算剩余工作量更加客观；对比B画法，识别和估算的时间可以大大节省，在计划会议上不再需要时间来识别和估算任务。

对于B画法，虽然形式上是敏捷开发的形式，但在内容上却是与传统的MPP日跟踪在颗粒度上是一致，让团队成员识别4小时颗粒度左右的任务，对比项目经理识别4小时颗粒度左右的任务，所费时间可能更久，在原来Excel的情况下，往往是专人跟踪剩余工时，对比项目经理跟踪MPP，所费工作量相当，在新的工具下，每个人每天跟踪自己任务的剩余工作量，对比Project团队版自行跟踪自己任务，也是非常相似的。