评估迭代范围变更对交付的影响，关键是把每次变更折算成对迭代目标、团队容量和对外承诺的三类影响，并用同一口径记录与复算。做法是先锁定迭代基线，再逐条登记变更的类型、规模、时间点和原因，计算范围变更率、容量占用变化、目标覆盖变化与交付偏差，最后结合变更发生的时间窗解释结果。单次变更率高低不能直接判定交付好坏，需要区分新增、替换、删除三类变更，并处理分母为零和跨迭代不可比的情况。
要点总览（TL;DR）
- 评估迭代范围变更对交付的影响，先把变更折算成三类影响：迭代目标是否仍可达成、团队容量是否被挤占、对外交付承诺是否偏移，三类分开判断。
- 范围变更率用“统计窗口内变更规模合计 ÷ 基线承诺规模”计算，分母取迭代启动时锁定的承诺范围；新增、替换、删除三类变更分别登记，替换类记录被替换项，避免重复计数。
- 评估按五步执行：锁定基线与容量、逐条登记归类变更、计算变更率与容量占用、比对目标覆盖与承诺偏移、按变更发生时间窗分段解释。
- 基线承诺规模为零时不计算变更率，改用绝对规模变化描述；跨迭代比较前先统一估算单位、迭代长度和统计窗口，不一致时只做趋势观察。
- 变更率反映范围波动的幅度和结构，适合用于迭代回顾中的改进讨论；单次数值高低不能直接判定交付好坏，也不宜作为绩效排名依据。
评估目标：范围变更要回答哪三个交付问题
范围变更对交付的影响，可以拆成三个可以分别判断的问题。评估时先明确这三个问题，后续指标和取数才有落点。
第一，迭代目标是否仍可达成。迭代启动时会约定一组要完成的需求及其验收标准。变更发生后，要看原目标中仍被保留、被替换和被删除的部分各占多少，判断迭代结束时能否交付原定目标。判断口径是目标层面的覆盖情况，而非单个需求是否完成。
第二，团队容量是否被挤占。新增或扩大的工作会占用原本分配给其他事项的工时。判断口径是变更带来的规模增量与迭代可用容量的比例关系，以及被挤占的是哪些工作。容量被挤占不一定导致目标失败，但会改变完成顺序和风险分布。
第三，对外交付承诺是否发生偏移。如果迭代成果对业务方、客户或其他团队有明确承诺，需要单独记录承诺项是否被新增、删除或替换，以及承诺的交付时间是否变化。承诺偏移与内部目标调整是两件事，应分开统计。
评估时点分两类。迭代进行中的评估用于判断当前风险并决定是否调整计划，关注的是剩余容量与剩余目标的匹配程度；迭代结束时的评估用于复盘，关注的是变更总量、变更时间分布与实际交付结果之间的关系。两类评估使用同一套指标口径，但解释重点不同。
指标与范围：变更率、容量占用与目标覆盖
指标定义需要固定公式、分母、单位和统计时间窗，否则不同迭代之间无法比较。下表给出建议口径，团队可以根据估算习惯调整单位，但同一迭代内应保持一致。
| 指标 | 公式 | 分母 | 单位 | 统计时间窗 |
|---|---|---|---|---|
| 范围变更率 | 统计窗口内变更规模合计 ÷ 基线承诺规模 | 迭代启动时锁定的承诺范围规模 | 百分比 | 迭代启动至统计日，或整个迭代 |
| 新增变更占比 | 新增项规模合计 ÷ 变更规模合计 | 变更规模合计 | 百分比 | 同上 |
| 替换变更占比 | 替换项规模合计 ÷ 变更规模合计 | 变更规模合计 | 百分比 | 同上 |
| 删除变更占比 | 删除项规模合计 ÷ 变更规模合计 | 变更规模合计 | 百分比 | 同上 |
| 容量占用变化 | 变更后承诺规模 − 基线承诺规模 | 不适用，用绝对差值 | 人天或故事点 | 迭代启动至统计日 |
| 目标覆盖变化 | 变更后仍服务于原迭代目标的工作项规模 ÷ 基线目标规模 | 基线目标规模 | 百分比 | 迭代结束时 |
| 承诺偏移项数 | 对外承诺项中被新增、删除或替换的数量 | 不适用，用绝对数量 | 项 | 迭代结束时 |
三类变更需要分别登记。新增是基线之外加入的工作；替换是用一项工作换掉另一项，登记时需同时记录被替换项，计算规模时只计净变化，避免同一工作被重复计数；删除是从承诺范围中移除的工作，规模按基线估算值记录。只统计变更总量而不区分类型，会把“等量替换”误读为“范围膨胀”。
容量占用变化建议使用与基线相同的估算单位。基线用故事点，变更也用故事点；基线用人天，变更也用人天。需要跨单位换算时，在方法说明中固定换算规则并注明适用迭代，避免同一迭代内混用两种口径。目标覆盖变化在迭代结束时计算更有意义，因为迭代中目标可能仍在调整；承诺偏移则应在每次承诺变更发生时即时记录。
数据口径与证据：变更记录需要哪些字段
要让结果可复算，每条变更都需要留下可核验的记录。建议至少登记以下字段：变更类型（新增、替换、删除）、变更对象（工作项标识）、规模估算值及单位、提出时间、生效时间、变更原因、提出人、影响的原目标或承诺项。替换类变更还需记录被替换项及其规模。
基线快照需要单独留存。迭代启动、承诺范围确定时，保存一份当时的工作项清单和规模合计，作为后续所有计算的分母来源。快照应包含工作项标识、规模、所属目标和是否属于对外承诺，之后不再修改。没有基线快照，变更率就失去稳定的分母，只能退化为描述性统计。
规模估算口径要一致。同一迭代内，变更项的估算应由同一角色按同一标准给出，或沿用基线估算时的规则。估算变更（例如原估 3 点后改为 5 点）应作为一次变更登记，记录变更前后数值，而非直接覆盖原值。
缺失值需要明确处理规则。变更项缺少规模估算时，可以先按同类工作的中位数暂估并标记为估算值，在复算时替换为正式估算；无法估算的变更单独列出，不计入变更率分子，但在结论中说明其存在。提出时间或生效时间缺失的记录，按登记时间归入统计窗口，并标注时间不完整。
定性证据同样需要留存。迭代计划会议和变更评审的会议记录、承诺变更的沟通记录、业务方确认信息，都是解释指标的依据。定量指标说明变化幅度，评审记录说明变化是否经过约定流程，两者结合才能判断变更管理的实际状态。
计算与评估步骤：从基线到影响结论
评估按固定顺序执行，每一步的产物是下一步的输入。
- 锁定迭代基线与容量。在迭代启动时保存承诺范围清单、规模合计、目标清单和对外承诺项，同时记录团队可用容量（人天或故事点）。产物是一份不再修改的基线快照。
- 逐条登记并归类变更。每次变更发生时，按上一节的字段登记，标注新增、替换或删除，替换类同时记录被替换项。产物是变更记录清单。
- 计算变更率与容量占用。用变更规模合计除以基线承诺规模得到范围变更率，按类型拆分占比；用变更后承诺规模减去基线承诺规模得到容量占用变化。产物是指标计算结果。
- 比对目标覆盖与承诺偏移。核对原迭代目标中仍被保留的工作项规模占比，列出对外承诺项中被新增、删除或替换的条目。产物是目标与承诺层面的影响判断。
- 按变更发生时间窗分段解释。把变更按发生时间分为迭代前期、中期和临近结束三段，分别看各段的变更规模与类型。临近结束的新增变更对交付的挤压通常更明显，解释结论时需结合时间点，而非只看总量。
异常情况按以下规则处理。基线承诺规模为零时，变更率没有意义，改用绝对规模变化和变更项数描述，并在结论中注明分母为零。跨迭代比较前，先确认估算单位、迭代长度和统计窗口一致；不一致时只做趋势描述，不做数值排名。迭代中统计时，分母仍用基线承诺规模，不用当前剩余规模，否则变更率会随进度自然放大。未完成工作在迭代结束时重新评估并重新规划，不默认结转到下一迭代后继续计入原迭代的完成情况。
示例：一个两周迭代的变更影响复算
以下为演示情景，用于说明公式代入方式，数值不代表任何真实团队。
某团队的两周迭代在启动时锁定基线：承诺范围 40 故事点，包含 6 个需求，其中 2 个是对外承诺项；团队可用容量为 60 人天，按历史速率折算约对应 40 故事点。迭代期间发生三次变更：第 3 天新增一个需求，估 5 点；第 6 天用一个新的 8 点需求替换原有一个 5 点需求；第 9 天删除一个 3 点需求。
| 变更 | 类型 | 规模（故事点） | 发生时间 | 净变化 |
|---|---|---|---|---|
| 变更一 | 新增 | 5 | 第 3 天 | +5 |
| 变更二 | 替换 | 新增 8，被替换 5 | 第 6 天 | +3 |
| 变更三 | 删除 | 3 | 第 9 天 | −3 |
变更规模合计按净变化计算为 5 + 3 − 3 = 5 点，范围变更率为 5 ÷ 40 = 12.5%。若按变更涉及的总规模计算则为 5 + 8 + 3 = 16 点，这个数字反映变更活动量，不反映范围净膨胀，两个口径应分别说明用途。容量占用变化为变更后承诺规模 45 点减基线 40 点，即增加 5 点，约占基线容量的 12.5%。
目标覆盖方面，假设被删除的 3 点需求属于原迭代目标，被替换的 5 点需求也属于原目标，则原目标中仍保留的规模为 40 − 3 − 5 = 32 点，目标覆盖变化为 32 ÷ 40 = 80%。承诺偏移方面，若三次变更均未涉及那 2 个对外承诺项，承诺偏移项数为 0；若替换涉及其中一个承诺项，则承诺偏移项数为 1，需单独说明替换后的交付内容和时间是否重新确认。
时间窗解释：第 3 天的新增发生在迭代前期，团队尚有调整空间；第 6 天的替换处于中期，需要重新安排设计和测试顺序；第 9 天的删除临近结束，释放的容量未必能转化为其他工作的提前完成。结论可以表述为：该迭代范围净增 5 点，变更率 12.5%，原目标覆盖降至 80%，对外承诺未变；交付风险主要来自中期替换带来的返工和末期容量释放不充分。这一结论说明变更与交付压力相关，不能单独证明变更导致了延期，延期与否还需结合实际完成情况和阻塞记录判断。
解读与限制：哪些结论能下、哪些不能下
变更率高低与交付质量之间没有固定的对应关系。变更率低可能说明范围稳定，也可能说明变更没有被如实登记；变更率高可能带来交付压力，也可能对应业务优先级被及时纠正。指标能说明范围波动的幅度和结构，不能单独证明交付结果的好坏，更不能作为因果结论。
变更发生的时间点显著影响解释。同样规模的变更，发生在迭代前期和临近结束，对交付的挤压程度不同。评估时应把时间窗作为解释变量，避免只用迭代总量下结论。迭代中评估与迭代结束评估的结论也可能不同，前者用于决策，后者用于复盘，两者不宜混用。
跨迭代、跨团队比较需要谨慎。估算单位不同、迭代长度不同、统计窗口不同、团队对“变更”的登记习惯不同，都会让数值失去可比性。确需比较时，先统一口径并说明差异，只做趋势观察，不做排名。分母为零的迭代不计算变更率，改用绝对规模描述。
未完成工作应在迭代结束时重新评估，判断是继续、拆分还是取消，并重新纳入后续规划。把未完成工作默认结转到下一迭代，会让原迭代的交付偏差被掩盖，也会让下一迭代的基线失真。
指标适合用于迭代回顾中的改进讨论，帮助团队识别变更集中在哪个阶段、哪类变更最常发生、承诺变更是否经过约定流程。把变更率直接作为个人或团队的绩效排名依据，容易诱导少登记或延迟登记，反而破坏数据质量。
在工具承载上，基线快照、变更记录和容量数据需要留存在同一处，才能按上述口径复算。ONES Project 支持需求管理、任务管理、缺陷管理和迭代管理等场景，产品负责人可将待办需求规划至对应迭代并在计划会议上评审，团队可用子任务拆分需求、通过敏捷看板跟进状态，燃尽图、工时日志等报表可用于迭代回顾时复盘进度与成本偏差。将变更登记为独立工作项或带类型标记的记录，并保留迭代启动时的范围清单，就能让变更率、容量占用和目标覆盖的计算有稳定的数据来源。具体字段配置和报表形式需按团队实际使用的版本核验。
常见问题
迭代进行中评估和迭代结束后复盘，指标口径要一样吗？
建议使用同一套指标定义，但解释重点不同。迭代进行中评估时，分母仍用迭代启动时锁定的基线承诺规模，不用当前剩余规模，否则变更率会随进度自然放大；此时关注剩余容量与剩余目标的匹配程度，用于判断是否需要调整计划。迭代结束时评估关注变更总量、变更时间分布与实际交付结果之间的关系，用于复盘。两类评估的结论不宜混用，迭代中的风险判断不能直接当作最终交付结论。
替换类变更在计算变更率时，规模按新增项算还是按净变化算？
建议同时保留两个口径并说明用途。按净变化计算（新增项规模减去被替换项规模）反映范围净膨胀，适合与基线承诺规模对比得出范围变更率；按变更涉及的总规模计算反映变更活动量，适合观察团队在迭代中处理了多少变更。只登记替换后的新工作项、不记录被替换项，会把等量替换误读为范围膨胀，因此替换类变更必须同时记录被替换项及其规模。
变更项缺少规模估算时，还能计入变更率吗？
可以处理，但要留下标记。缺少估算的变更可先按同类工作的中位数暂估，并标记为估算值，复算时替换为正式估算；完全无法估算的变更单独列出，不计入变更率分子，但在结论中说明其存在和数量。提出时间或生效时间缺失的记录，按登记时间归入统计窗口并标注时间不完整。这样处理能保持分母稳定，也让读者知道结果中包含多少估算成分。
基线承诺规模为零的迭代，怎么描述范围变更？
分母为零时变更率没有意义，改用绝对规模变化和变更项数描述，例如“迭代期间新增 3 项、合计 8 点，删除 1 项、合计 2 点，净增 6 点”，并在结论中注明分母为零、未计算变更率。这类迭代通常出现在探索性或维护性工作中，承诺范围本身难以预先量化，用绝对值和类型结构描述比强行计算比率更准确。
评估结果能不能直接用来评价团队或个人的交付表现？
不建议。变更率高低与交付质量之间没有固定对应关系：变更率低可能说明范围稳定，也可能说明变更没有被如实登记；变更率高可能带来交付压力，也可能对应业务优先级被及时纠正。把变更率作为绩效排名依据，容易诱导少登记或延迟登记，反而破坏数据质量。更合适的用法是在迭代回顾中识别变更集中在哪个阶段、哪类变更最常发生、承诺变更是否经过约定流程，据此讨论改进动作。
