迭代燃尽图把“还剩多少工作”画成一条随时间下降的线，难点在于每个数字怎么填、每天什么时候更新、线偏离时怎么判断。本文用一次假设的两周迭代，给出一张填好的每日剩余工作量表和对应的理想线、实际线，逐项说明数据来源与读图逻辑。示例数据仅用于演示方法，不代表真实项目成效。填写与更新环节可借助ONES Project的迭代工作项与燃尽图记录剩余工作量。
要点总览（TL;DR）
- 示例以一次假设的两周迭代为情景：6人团队、8个工作项、总工作量80工时，逐日记录剩余工作量并对照理想燃尽线。
- 填写要点是统一口径、固定更新时点：总工作量来自迭代规划，剩余工作量由工作项负责人在每日站会后报数，范围变更时先调整总工作量再重画理想线。
- 读图先看总工作量是否变过，再看差距是持续扩大还是短期波动，最后落到具体工作项找原因；示例中的两次偏离分别对应依赖阻塞和范围变更。
- 迭代结束时未完成的工作需重新评估优先级、拆分和估算后再决定去向，不默认结转到下一迭代。
- 示例数值为演示用途，不构成基准值；燃尽图适合作为进度跟进与回顾复盘的参考信号，不宜单独作为绩效评价依据。
示例目标：这张燃尽图要回答什么
先交代示例情景。假设一个6人研发团队，迭代周期为两周共10个工作日，迭代内纳入8个工作项，总估算为80工时。团队规模、工作项数量、工时数值都是为演示设定的，不对应任何真实项目。选择工时而非故事点，是因为工时在每日更新时更容易拆分到“剩余多少小时”，便于展示填写过程。
这张示例燃尽图要演示三件事：
- 数据来源：总工作量从哪来，每日剩余工作量由谁、依据什么填写。
- 每日更新：更新时点放在哪里，更新后实际线如何变化。
- 读图判断：实际线高于或低于理想线时，分别对应哪些可能原因，应做什么动作。
示例与真实项目的区别需要明确：示例中的偏离事件是为讲解而设计的，真实迭代的偏离往往更零散；示例的数值不构成任何基准值，不同团队、不同工作项拆分粒度下的剩余工作量没有可比性。读者应把本文当作填写格式和读图方法的参照，而非进度标准。
完整示例：一次两周迭代的燃尽图数据
迭代范围与口径如下：迭代共10个工作日，总工作量80工时，按每日剩余工作量记录。理想燃尽线从第0天的80工时线性下降到第10天的0，每日理论下降8工时。实际线按每天站会后更新的剩余工作量绘制。
| 工作日 | 当日事件 | 剩余工作量（工时） | 理想剩余（工时） | 实际与理想差 |
|---|---|---|---|---|
| 第0天（计划） | 迭代规划完成，总工作量80 | 80 | 80 | 0 |
| 第1天 | 正常推进 | 72 | 72 | 0 |
| 第2天 | 正常推进 | 65 | 64 | +1 |
| 第3天 | 一个工作项发现依赖阻塞 | 60 | 56 | +4 |
| 第4天 | 阻塞未解除，投入排查 | 56 | 48 | +8 |
| 第5天 | 阻塞解除，恢复推进 | 44 | 40 | +4 |
| 第6天 | 新增一个紧急缺陷工作项，+6工时 | 42 | 32 | +10 |
| 第7天 | 集中处理新增项 | 30 | 24 | +6 |
| 第8天 | 正常推进 | 18 | 16 | +2 |
| 第9天 | 正常推进 | 8 | 8 | 0 |
| 第10天 | 迭代结束，剩余2工时未完成 | 2 | 0 | +2 |
把表中“剩余工作量”连成实际线、“理想剩余”连成理想线，可以看到两次明显偏离：
- 第一次偏离（第3—5天）：一个工作项遇到外部依赖阻塞，实际线连续高于理想线，第4天差距达到8工时。阻塞解除后差距收窄，说明这是短期阻塞而非整体估算失真。
- 第二次偏离（第6—7天）：迭代中途新增一个紧急缺陷工作项，总工作量从80调整为86，实际线出现一次上抬。这次偏离对应范围变更，而非执行变慢。
迭代结束时剩余2工时未完成。示例的处理方式是：在回顾会上重新评估这2工时对应的工作项，判断是拆分不够细、估算偏低还是被新增项挤占，再决定放入下一迭代还是退回需求池，不默认自动结转。
逐项解释：每个字段和每条线怎么来的
下面按字段解释取值依据、更新时点和读图判断，便于对照上表逐行核对。
| 字段/线条 | 取值依据 | 更新时点 | 读图判断 |
|---|---|---|---|
| 总工作量 | 迭代规划时对纳入工作项的估算之和，示例为80工时 | 规划会确定；范围变更时同步调整 | 总工作量变化说明范围变了，需与实际线一起看 |
| 剩余工作量 | 各工作项“原估算减去已完成部分”之和，由任务负责人报数 | 每日站会后统一更新一次 | 连续多日下降缓慢，提示阻塞或拆分过粗 |
| 理想燃尽线 | 总工作量除以迭代天数得到每日下降量，从起点连到终点 | 规划时画定；范围变更后重画 | 斜率代表计划节奏，是参照线而非考核线 |
| 实际燃尽线 | 按每日更新后的剩余工作量逐点连接 | 与剩余工作量同步更新 | 与理想线的差距和走势共同说明问题类型 |
实际线偏离理想线时，常见原因可分四类：一是范围变更，总工作量本身变了，线会上抬；二是估算偏差，前期估低导致下降偏慢；三是阻塞与依赖，工作项卡住无法推进；四是人员变动或投入被抽调，可用工时减少。判断顺序建议先看总工作量是否变过，再看差距是持续扩大还是短期波动，最后落到具体工作项上找原因。
未完成工作的处理需要单独说明：迭代结束时剩余的工作量不应直接搬到下一迭代充数，而应重新评估优先级、重新拆分、重新估算。示例中剩余2工时的工作项，在回顾会上被拆成更小的任务并重新估时，才决定去向。这样下一迭代的燃尽图起点才是可信的。
在工具层面，ONES Project适配迭代管理场景，支持规划迭代，并提供看板、燃尽图等工具实时掌控当前进度，同时支持任务工时统计。团队可以把每日站会后确认的剩余工作量记录到对应工作项上，让燃尽图随工作项状态和工时数据更新，减少手工汇总。燃尽图的具体数据口径与更新配置以实际使用版本为准。
可迁移规律：换一个迭代怎么照样填
把上面的做法抽象成规则，换迭代长度或换团队时可以照着调整。
- 迭代长度变化时调整口径：一周迭代的理想线每日下降量为总工作量除以5，两周除以10。迭代越短，单日波动对线的形状影响越大，读图时应更关注趋势而非单点。
- 范围变更时同步更新总工作量：新增或移除工作项后，先调整总工作量并重画理想线，再更新当日剩余工作量。只改实际线不改总工作量，会让两条线失去可比性。
- 明确更新责任人与时点：由各工作项负责人在每日站会后报剩余工时，由迭代负责人或 Scrum Master 统一汇总更新，每天固定一次。更新时点不固定，线的拐点就失去解释力。
- 读图时问三个问题：总工作量变过吗？差距是持续扩大还是短期波动？差距对应到哪几个具体工作项？三个问题依次回答，基本能定位偏离性质。
团队规模和工作项拆分粒度不同，填法也要相应调整。工作项拆得粗，单日剩余工作量的跳变会很大，建议拆到一天左右能完成的程度再估算；团队人数多、并行工作项多时，汇总口径要统一到同一单位，避免工时和故事点混用。ONES的敏捷看板可用于站会中对齐任务状态与风险，燃尽图则作为进度参考信号，两者配合能让每日更新有据可查。
适用边界：示例不能直接照搬的地方
示例的数值和偏离情节都是假设，不能当作基准值去对比自己团队的曲线。不同团队的总工作量、拆分粒度、可用工时差异很大，同样的曲线形状可能对应完全不同的原因，照搬数值判断进度容易误判。
燃尽图适合作为迭代进度跟进和回顾复盘的参考信号，不适合单独作为绩效评价依据。一条线受范围变更、阻塞、人员投入等多种因素影响，脱离工作项明细和上下文解读，容易把外部原因算到个人头上。ONES的资料也把燃尽图定位为评估研发效率和复盘进度、质量、成本偏差的参考数据之一，需与工时日志、持续集成报告等一起看。
本文聚焦燃尽图的填写与读图，敏捷框架概念的系统介绍、产品 Backlog 与需求池管理方法属于相邻主题，不在本文展开。读者若需要规划迭代范围、管理需求优先级，应另找对应方法资料。示例中的更新频率、口径选择也需结合团队实际约定，本文给出的是一种可操作的填法，而非统一要求。
常见问题
迭代燃尽图按故事点还是按工时填？
两种口径都可以，关键是同一迭代内保持一致，并与团队估算习惯匹配。按工时填，剩余工作量能拆到“还剩多少小时”，每日更新时更容易报数；按故事点填，单日变化通常更平缓，适合工作项拆分较粗的团队。示例选工时是为了展示逐日填写过程。混用两种单位会让总工作量和实际线失去可比性，读图判断也会失真。
迭代中途新增需求，燃尽图应该怎么改？
先调整总工作量，再重画理想燃尽线，然后更新当日剩余工作量。只改实际线不改总工作量，两条线就不在同一口径上，后面的差距无法解释。示例中第6天新增一个紧急缺陷工作项、总工作量从80调整为86，实际线出现一次上抬，这次偏离对应的是范围变更而非执行变慢。是否接受这次范围变更，应在迭代内明确记录，便于回顾会复盘。
实际线连续几天高于理想线，先查什么？
建议按顺序排查：先确认总工作量是否变过，排除范围变更；再看差距是持续扩大还是短期波动；最后落到具体工作项上找原因。常见原因包括估算偏低、外部依赖阻塞、人员投入被抽调。示例中第3—5天的偏离由依赖阻塞引起，阻塞解除后差距收窄；如果差距持续扩大且找不到单一阻塞点，通常提示前期估算整体偏低，需要在回顾会上调整估算方法。
迭代结束时没做完的工作，可以直接放到下一迭代吗？
建议重新评估后再决定，不默认结转。未完成的工作项需要重新确认优先级、重新拆分、重新估算，再判断是放入下一迭代还是退回需求池。直接搬运会让下一迭代的燃尽图起点不可信，也容易掩盖估算偏差。示例中剩余2工时的工作项在回顾会上被拆成更小的任务并重新估时，才确定去向。
燃尽图能不能用来评价团队或个人的绩效？
不适合单独作为绩效评价依据。一条曲线受范围变更、依赖阻塞、人员投入等多种因素影响，脱离工作项明细和上下文解读，容易把外部原因归到个人。更合适的用法是把它作为迭代进度跟进和回顾复盘的参考信号，与工时日志、持续集成报告等数据一起看，在回顾会上讨论偏差原因和改进动作。
