如何评估迭代范围变更对交付的影响

评估迭代范围变更对交付的影响，需要把“影响”拆成三个可比口径：目标口径看变更是否挤占本迭代承诺目标，容量口径看新增与移出工作量对可用人力的净占用，交付口径看变更后完成项与承诺项的比值及延期天数。统计时间窗固定为迭代开始至评审日，工作量单位统一为人天或故事点，每次变更的增删与原因都要留痕，指标才可复算。

要点总览（TL;DR）

• 把范围变更对交付的影响拆成目标、容量、交付三个口径分别度量，避免用单一指标下结论。
• 统计时间窗固定为迭代开始到迭代评审日，工作量单位统一为人天或故事点，并写明换算假设。
• 核心公式：范围变更率＝迭代内变更工作量÷迭代开始时承诺工作量；容量占用率＝净新增工作量÷迭代可用人力；承诺达成率＝按期完成承诺项÷承诺项总数。
• 变更记录保留日期、类型、原估算、变更后估算、原因、提出人，并留存承诺基线快照，保证分子分母可复算。
• 分母为零时指标标记为不适用，跨迭代未完成项重新评估，阈值结合团队历史基线确定。

评估目标：要回答交付的哪几个问题

评估对象是单个迭代运行过程中发生的范围变更，结论用于迭代复盘和下轮承诺调整，不用于绩效追责。把“影响大小”这种笼统判断拆开，才能得到可验证的结论。一次评估至少要回答以下三类问题。

• 目标影响：本迭代开始时承诺的目标，有多少因范围变更被推迟、替换或放弃？变更后的迭代目标是否仍然成立？
• 容量影响：新增工作量与移出工作量的净差，占用了多少可用人力？团队是否需要加班、压缩测试或借用外部支持来消化？
• 交付影响：承诺项中按期完成的比例是多少？未按期完成的项延期了几天？延期集中在哪些环节？

三类问题对应不同的判断依据：目标影响看承诺项的去向，容量影响看工作量与人力的对比，交付影响看完成时间与承诺时间的差距。只回答其中一类，容易得出片面结论。例如范围变更率很低但交付仍然延期，问题可能出在估算偏差或依赖阻塞上，需要结合容量与交付口径进一步定位。

评估结论的用途要提前说清：复盘会上据此讨论下轮承诺留多少缓冲、变更走什么审批路径、哪些类型的变更是可以提前预见的。把评估结果直接对应到个人考核，会诱导团队少记录变更或事后修改估算，反而破坏数据可信度。

指标与范围：选哪些指标、统计边界怎么定

指标集合以四个核心指标为主，配合统计边界使用。边界不统一，同一迭代两个人算出的结果会不同，因此时间窗、纳入对象和单位需要在评估前写清楚。

指标	定义	分子	分母	单位
范围变更率	迭代内变更工作量占承诺工作量的比例	迭代内新增、移出、改估算的变更工作量绝对值之和	迭代开始时承诺工作量	百分比
容量占用率	净新增工作量对可用人力的占用程度	新增工作量减移出工作量（净新增）	迭代可用人力	百分比
承诺达成率	承诺项中按期完成的比例	按期完成的承诺项数	承诺项总数	百分比
变更后延期天数	受变更影响的项实际完成晚于原承诺的天数	实际完成日减原承诺完成日	不适用	天

统计时间窗：从迭代开始日（承诺基线确定时点）到迭代评审日。评审日之后发生的变更不计入本次评估，避免统计口径随复盘时间漂移。

纳入对象：本迭代承诺项，以及迭代内新增或移出的工作项。其他迭代的项、长期待办池中的需求不纳入，即使它们在迭代期间被讨论过。

工作量单位：全迭代统一使用人天或故事点，二选一，不混用。若团队同时存在两种估算习惯，需要写明换算假设，例如“1 故事点按团队历史均值折算为 0.8 人天”，并在评估说明中标注该假设，便于他人复算时替换。

范围变更率与容量占用率回答的问题不同：前者衡量变更相对承诺规模的比重，后者衡量变更相对团队实际可投入人力的压力。一个迭代承诺量很大时，变更率可能不高但容量占用率已经很高，两个指标要一起看。

数据口径与证据：变更记录要留哪些字段

指标能否复算，取决于变更记录是否完整。每条变更至少保留以下字段，缺字段的记录在汇总时单独标注，不用推测值填补。

字段	说明	用途
变更日期	变更被确认的日期	判断是否落在统计时间窗内
变更类型	新增、移出、改估算	区分范围变更与估算修正
原估算	变更前的工作量	计算变更量
变更后估算	变更后的工作量	计算变更量
原因	需求方插入、缺陷修复、依赖调整等	复盘时归类分析
提出人	发起变更的角色	追溯变更来源

承诺基线快照：迭代开始时，把承诺项清单、各项估算和总工作量保存为一份快照，作为分母来源。快照一旦确定不再修改，后续变更只追加记录。没有快照，分母会随工作项被编辑而变化，指标失去可比性。

估算变更与范围变更分开记录：范围变更是工作内容的增删，估算变更是对同一内容工作量的修正。两者都会改变工作量数字，但含义不同。把估算修正混入范围变更，会让变更率虚高；把范围变更记为估算修正，则会低估变更影响。记录时按类型字段区分，汇总时分别统计。

缺失数据的处理原则：没有记录的变更不推断、不补录为“零变更”。汇总时在评估说明中列出缺失项及影响范围，例如“第 3 项变更缺少原估算，未计入变更率分子”。缺失较多时，指标结论应标注为参考值，不作为下轮承诺调整的唯一依据。

在 ONES 中，迭代计划阶段产品负责人可将需求规划至对应迭代，并与团队就完成项与验收标准达成一致，设计、研发、测试人员用子任务拆分需求；迭代过程中团队通过敏捷看板管理任务状态，系统自动记录资源投入、工作项滞留时间等过程数据。这些工作项与迭代视图可以承载承诺项清单和变更记录，为基线快照和变更字段提供留存位置。若团队需要更严格的需求基线与变更追溯，ONES ALM 方案围绕需求、基线、版本和变更建立统一管理对象，支撑变更影响分析与交付结果回溯，适用于有基线管理要求的场景。

计算与评估步骤：从原始记录到影响结论

计算按固定顺序执行，每一步的产物作为下一步的输入，保证结果可复算。

1. 取基线：调出迭代开始时的承诺基线快照，得到承诺项清单、各项估算和承诺工作量合计。
2. 汇总变更：按统计时间窗筛选变更记录，按类型分别汇总新增、移出、改估算的工作量，并计算净新增。
3. 计算指标：代入下列公式，逐项记录分子、分母和单位。
4. 对照解读：把四个指标与团队历史基线对照，结合变更原因分类，形成影响结论和下轮调整建议。

核心公式：

• 范围变更率 ＝ 迭代内变更工作量 ÷ 迭代开始时承诺工作量 × 100%
• 容量占用率 ＝ 净新增工作量 ÷ 迭代可用人力 × 100%
• 承诺达成率 ＝ 按期完成承诺项数 ÷ 承诺项总数 × 100%
• 延期天数 ＝ 实际完成日 － 原承诺完成日

分母为零或承诺为空时的处理：承诺工作量为零、承诺项总数为零或可用人力为零时，对应指标标记为“不适用”，不填零。零值会被读成“没有影响”，与实际情况相反。若迭代中途启动、没有正式承诺基线，可改用迭代内首次计划确认的清单作为替代分母，并在说明中注明替代口径。

净新增为负时的处理：移出工作量大于新增时，容量占用率为负值，表示本迭代实际释放了容量。此时仍按公式计算并保留负号，解读时说明是范围收缩，不与“无变更”混为一谈。

例子：一个两周边迭代的完整算例

以下为演示情景，数字用于说明计算过程，不代表任何团队的实际数据。

某团队两周边迭代，可用人力合计 40 人天。迭代开始时承诺 8 个工作项，合计 32 人天。迭代期间记录到以下变更：

变更项	类型	原估算（人天）	变更后估算（人天）	变更量（人天）
需求 A 增加导出格式	新增	0	4	+4
需求 B 移出至下轮	移出	5	0	-5
需求 C 补充验收场景	改估算	3	5	+2
需求 D 技术方案调整	改估算	6	4	-2

第一步，汇总变更。变更工作量绝对值之和为 4＋5＋2＋2＝13 人天；净新增为 4－5＋2－2＝－1 人天。

第二步，计算范围变更率。13 ÷ 32 × 100% ≈ 40.6%。变更规模相对承诺量偏大，主要来自新增导出格式和需求 C 的验收场景补充。

第三步，计算容量占用率。净新增 －1 ÷ 40 × 100% ＝ －2.5%。净新增为负，说明移出与估算下调抵消了新增，本迭代容量压力略有释放。若只看范围变更率 40.6%，会误判为容量紧张，两个指标组合才能还原实际情况。

第四步，计算承诺达成率。假设 8 个承诺项中按期完成 6 项，承诺达成率为 6 ÷ 8 × 100% ＝ 75%。未完成的 2 项中，1 项因新增导出格式挤占时间延期 3 天，另 1 项因外部依赖未就绪延期 5 天。延期天数按项分别记录，不取平均掩盖差异。

第五步，组合解读。本迭代范围变更率较高，但净新增接近零，容量并未被显著挤占；承诺达成率 75%，延期原因一项与变更相关、一项与依赖相关。结论应指向：变更审批环节需要评估新增项对承诺项的挤占，依赖管理需要提前确认外部就绪时间。若只看范围变更率就要求团队下轮减少承诺量，可能过度反应。

数据缺失情形：若需求 A 的变更记录缺少原估算，则该条不计入变更量分子，范围变更率改为 9 ÷ 32 × 100% ≈ 28.1%，并在说明中标注“1 项变更因缺少原估算未计入”。分母为零的情形，例如某迭代没有正式承诺清单，则承诺达成率标记为不适用，改用首次计划确认清单作为替代分母并注明。

解读与限制：指标能说明什么、不能说明什么

指标描述的是变更与交付之间的事实关系，不能直接推出因果结论。范围变更率高，可能伴随交付延期，也可能因为团队及时移出低优先级项而按期交付；范围变更率低，交付仍可能延期，原因在估算偏差、依赖阻塞或人员变动。解读时需要把变更原因分类与交付结果对照，再下判断。

估算偏差要单独标注。改估算类变更同时影响分子和分母：分母是承诺时的估算，分子包含估算修正量。若团队普遍低估，范围变更率会被抬高，但真实的范围增删可能很少。评估时把改估算类变更单列一行，与新增、移出分开呈现，避免把估算问题误读为范围失控。

跨迭代未完成项重新评估。本迭代未完成的项进入下轮时，应重新估算并重新纳入下轮承诺，不默认按原估算自动结转。自动结转会让下轮分母虚增，也会掩盖本轮的交付缺口。重新评估后，本轮承诺达成率按下轮实际完成情况回填时，需注明回填口径。

小样本迭代看趋势。单个两周边迭代的承诺项通常只有几项到十几项，一项变更就能让变更率跳动十几个百分点。单点数值不足以判断团队状态，宜连续观察三到五个迭代的走势，再讨论是否需要调整承诺方式或变更流程。

不设通用达标线。范围变更率多少算高、承诺达成率多少算好，取决于团队业务性质、需求稳定性和历史基线。阈值应由团队用自身历史数据确定，例如取过去若干迭代的中位数作为参考线，并在复盘中说明阈值来源。直接套用外部通用标准，容易产生与业务实际不符的结论。

评估结论落到行动上，通常是三件事：下轮承诺时预留多少缓冲、哪类变更需要提前评审、哪些依赖需要在迭代开始前确认。把这些调整写进下轮计划，并在下个迭代用同一口径复算，才能验证调整是否有效。

常见问题

迭代中途才启动、没有正式承诺基线，还能评估范围变更影响吗？

可以，但要换一个分母。用迭代内首次计划确认的清单作为替代基线，把当时确认的工作项和估算作为承诺工作量，并在评估说明中注明这是替代口径。替代口径与正式基线不完全等价：首次计划确认的时间晚于迭代开始，可能已经漏掉早期变更。因此结论里要写清替代口径的起点日期，跨迭代对比时保持同一口径，不要与有正式基线的迭代直接比较数值。

改估算算不算范围变更，应该计入变更率吗？

改估算与范围变更含义不同，建议分开记录、分别统计。范围变更是工作内容的增删，改估算是对同一内容工作量的修正。把两者合并计入变更率，会让指标同时反映范围波动和估算偏差，难以判断问题出在哪。实操上可以在变更记录里用类型字段区分新增、移出、改估算，汇总时把改估算单列一行。如果团队普遍低估，改估算量会偏大，这时更值得讨论的是估算方法，而不是变更审批流程。

范围变更率多少算高，需要设一个达标线吗？

不建议直接套用外部通用标准。范围变更率的高低与业务性质、需求稳定性、迭代长度都有关，同一个数值在不同团队含义不同。更稳妥的做法是用团队自身历史数据确定参考线，例如取过去若干迭代的中位数，并在复盘中说明参考线的来源和样本范围。单个两周边迭代的承诺项通常只有几项到十几项，一项变更就能让变更率跳动十几个百分点，宜连续观察三到五个迭代的走势再讨论是否调整承诺方式。

本迭代未完成的工作项，下轮直接结转会影响评估结果吗？

会。未完成项默认按原估算自动结转，会让下轮的承诺工作量虚增，也会掩盖本轮的交付缺口。建议下轮重新估算并重新纳入承诺，本轮承诺达成率按实际完成情况记录，需要回填时注明回填口径。这样本轮的数据反映真实交付结果，下轮的分母也来自重新确认的承诺，两个迭代的指标才可比。重新评估时还可以顺带检查未完成原因，区分是变更挤占、依赖阻塞还是估算偏差。

评估结论除了复盘，还能用来调整哪些具体动作？

结论通常落到三件事：下轮承诺时预留多少缓冲、哪类变更需要提前评审、哪些外部依赖要在迭代开始前确认。例如算例中范围变更率偏高但净新增接近零，说明变更规模大而容量压力被移出项抵消，调整重点在变更审批环节评估新增项对承诺项的挤占；若延期主要来自外部依赖，则重点放在迭代开始前确认依赖就绪时间。把这些调整写进下轮计划，下个迭代用同一口径复算，才能验证调整是否有效。