这是敏捷开发日常跟进系列的第二篇（栏目目录）。
迭代及燃尽图的目标
燃尽图的目标是完成迭代的目标，迭代的目标是什么呢？
1. 按产品经理的要求，交付计划会中计划的用户故事
2. 尽量完成1
之后还会看到，这个定义还有狭隘之处，在系列后面的文章中会提到。
为什么燃尽图不能直接地达成这个目标？潜在的问题包括：
1. 如果燃尽图按时完成，有可能是为了按时完成，同时牺牲了所有故事（重要和不重要的）的质量，换取了进度。
2. 如果燃尽图未按时完成，有可能不是一个故事没有完成，而是所有故事都剩下点活没做完，导致所有故事都无法交付。
3. 如果燃尽图未按时完成，没有完成的故事中，有可能包括了极其重要的一些。
只从燃尽图的形态看，是无法提前识别这三者的，也就因此带来了很多的风险，到迭代的末尾让人大吃一惊。
怎么办呢？
“阶梯燃尽图”
之前听过这个方法，但是刚才在网络上没有找到图片。
方法就是在每个故事完成的时候才把整个故事突然剪掉，从而形成阶梯状。
阶梯状燃烧图的缺点也很明显：刚开始的时候很难看到有燃尽，甚至那些向上拱起的弧形也被掩盖了，日后回顾时，一些细节也很难记起来。
所以一种解决方案，是把普通燃尽图和阶梯燃尽图混合使用，就是同时画两条线。
“跟进图”
跟进图是一些大型团队的创造，由于团队巨大，所以不能指望在迭代的最后用2小时评审完所有工作，所以常常是做完一个评审一个，这就要给每个工作分配一个“跟进人”，他隶属产品部门，没事就盯着“跟进图”看看有没有自己关心的工作做完了。
在为一家游戏公司提供咨询的时候，他们一款产品的团队人数高达88人（另一个甚至到了200人），墙上就用手绘制了一幅巨大的跟进图，每天更新动态，甚至直接在纸上画上小图标，每月画满了，就重新打印一张。
下面这张，是火星人中的跟进图。
图中绿色粗线，就是传统的燃尽图；
每当一个故事完成，就会有一个蓝色的标记及完成故事的名字，从而提醒跟进人进行现场预评审；如果长期没有故事完成，燃烧图却还在燃烧，就肯定出现了之前说过的问题了。
右下部分还有一个暗红色的细线，是“溢出时间”，就是超出预期的工作的时间，表明这段时间出现了新的任务；新任务出现的太早不好，因为一般在迭代前期都先完成最重要的故事，不应该引入新任务；但在后期随着最重要的故事完成、评审、因不满意而返工，团队会倾向于把最重要的任务更好地完成，而非草草地把所有故事都凑合完成，在产品研发中，这往往是更能提升产品价值的。
一家叫做广联达的公司在实践中把溢出时间作为负数倒着画，称为“基线下沉”，就是说要去的地方不是0了，而是那个负数，是一个类似目的的很好的实践。
我试了一下也不错，就是图表会变高，显示起来不方便，所以还是改了回来。
这样的跟进图看起来已经很强大了，但是还有一些问题没有解决：
1. 有哪些故事正在做，还没有做，已经开工了但没完成……？
2. 最后剩下了哪些故事没完成？
3. 有没有人不是一个一个完成故事，而是同时开工了很多故事？（这个是最后很多故事都开工了但都差一点完成不了的主要原因）
4. 如果有跟进人，谁负责跟进哪个？
有些问题需要后面的故事板（看板）解决，有些则需要一个叫做“跟进表”的东西，之后我们说完故事板再回来详细说明。
