迭代速率与燃尽预测

本地处理

速率的作用不是给团队打分，而是把不确定性换成区间。只报一个平均值是在骗人：六次迭代完成 21、18、24、19、23、20，平均 20.8 看起来稳，但标准差已有 2.4，剩余待办多的时候这个波动会放大成好几个迭代的差异。

最近各迭代完成的点数（逗号或换行分隔，从旧到新）

每个迭代天数

剩余待办点数

团队人数

起始日期

速率为什么要看区间而不是均值

团队速率（velocity）是「一个迭代内真正完成、且满足完成定义的待办点数之和」。它最大的价值不是衡量绩效，而是把交付预测从点估计变成区间估计。

拿六次迭代的数据算一下：均值、样本标准差。经验法则是，用均值 + 1 个标准差作为乐观速率，均值 − 1 个标准差作为保守速率。剩余待办除以这三个速率，就得到乐观、期望、保守三档迭代数。

判断速率是否「稳定」看变异系数，也就是标准差除以均值：

变异系数	含义	预测该怎么做
小于 15%	速率很稳，团队节奏一致	可以用均值对外承诺
15% 到 30%	正常波动区间	对外用保守速率，对内用均值
大于 30%	波动偏大，均值不可信	先查根因：需求切分粒度是否差异过大、是否频繁中断、是否有未完成的半成品堆积

把速率当 KPI。一旦速率影响绩效，点数估算就会膨胀，历史数据也随之失去对比意义。
迭代中途拒绝变化，却在迭代末强行塞入新任务。这会让未完成项跨迭代堆积，速率被人为拉低。
用线性外推估算加人效果。人数与吞吐量的关系不是线性的：n 个人的沟通通道有 n×(n−1)/2 条，5 个人 10 条，10 个人 45 条。这就是布鲁克斯定律说的「向进度落后的项目增加人手，只会让它更落后」的机制。

燃尽图的纵轴是剩余点数，横轴是时间。理想线是从总量线性下降到零的直线，实际线是每天真实剩余量。两种典型形态值得警惕：

本工具按迭代粒度绘制燃尽，能看出交付节奏是否匀速；如果每一次的下降都集中在迭代最后，就该检查完成定义是否过严或任务切分是否过大。

取最近几个迭代完成的故事点平均值（通常 3-5 个迭代）；只看单个迭代波动大，移动平均更能反映团队的稳定产出。

理想线与实际线对比：实际线持续在理想线之上说明进度落后；突然上升常代表范围扩大（新增需求），需要及时确认是否调整计划。

用速率均值推算是期望值，实际要留出波动区间；团队人员变动、假期与依赖外部交付都会显著影响速率，预测应给出区间而非单点承诺。