这是敏捷开发日常跟进系列的第一篇。
这个系列将涉及燃尽图（Burndown Chart）、故事板（看板）、每日立会等内容，描述在计划会之后，评审会之前，敏捷开发团队内部产出与产品经理和项目经理的各种活动。
日常跟进中的某些内容比如团队工作模型、预估会议、用户故事跟进等在之前的松结对编程、团队管理、用户故事、产品管理等系列中有所描述。
在这个系列之前，还应该有一个敏捷计划系列，描述敏捷开发的从版本规划到计划会估算的详细内容，未来将会补上，当前可以参考2.29版的《火星人敏捷开发手册》，有5页与其相对应。
燃尽图
燃尽图Burdown Chart也叫燃烧图，是罕见的敏捷度量，以至于每当有人问起“敏捷中有度量吗”的时候，第一反应就是它。
燃尽图的全称，应该是“总剩余时间的燃尽图”，就是本次迭代中，所有故事（或拆分的任务，以下仅称故事）的剩余时间总和，随日期的变化而逐日递减的图。
图中左侧460是迭代开始的第一天，所有故事的未完成时间相加为460天，而在最右侧则表明在第17天，所有故事的剩余时间相加变为0，也就是所有故事都完成了。
为什么总和会递减呢？因为每个组员每天都要汇报一件事情：当前正在做的故事，还剩余几天，如果昨天剩余3天，今天剩余2天，那么就为燃烧图贡献了1天的进度。
由于可能出现“昨天剩余3天，又工作了一天后本以为会只剩下2天，结果感觉可能还要3天（甚至变成5天了！）”这种情况，所以燃尽图常常有一些起伏。
燃尽图的“指纹”
图中的燃尽图尽管有一些起伏，依然是属于比较完美的燃尽图。实际上每个团队完成迭代的过程差别很大，常见的情况包括：
先鼓起后落下
原因是计划会以常常漏掉一些事情，所以开工后不但不燃尽，还发现了很多新的任务。
先完美燃烧，然后突然停止燃烧
一种很常见的情况，如果任务划分太粗，比如长达10天，很容易“做了1天，剩9天；做了1天，剩8天；……到剩2～3天的时候，哎呀，好像搞不定了”。
先缓慢燃烧，然后到快燃尽的时候剩下一堆没完成的任务，被推迟到下个迭代
之前提到过敏捷开发的MoSCoW方法，有些故事是次要的“可以不做的”，所以这种燃烧图也很常见；但是常常有团队没有使用MoSCoW方法，只是被动地发现有些故事没有完成。
……
为了改进这些不完美，有些团队设置了一些度量项来改进燃尽图的结果，比如“迭代按时燃尽的次数”“剩余故事占总故事的比例”……
其实不用因为燃尽图的不完美而伤脑筋，在般若敏捷的“无住”中曾经提到，这些方法都非我们的目的，而只是一个中间的工具，因此为了完成我们的最终目的，这些工具和方法都可以灵活变通，而不要追求工具和度量数据本身的完美。
但是，迭代的最终目的到底是什么呢？有哪些“灵活变通”可以应用在燃尽图中呢？且待下回分解。
作者：陈勇
本专栏经作者授权开设，专栏文章未经许可不得转载
