迭代范围变更影响分析建议围绕三条线选指标：目标线看迭代目标完成率与目标变更次数；容量线看新增工作量占比、容量占用率与变更后剩余容量；交付线看范围变更率、变更引入的返工量、迭代承诺达成率和变更后交付周期偏差。每个指标都要固定分子、分母、时间窗和单位，并区分计划内变更与插入式变更。指标用于解释影响、触发重新评估，不能单独当作团队绩效结论。
要点总览（TL;DR）
- 迭代范围变更影响分析围绕三条线选指标：目标线看迭代目标完成率与目标变更次数，容量线看新增工作量占比、容量占用率与变更后剩余容量，交付线看范围变更率、变更引入返工量、承诺达成率与交付周期偏差。
- 每个指标都要固定分子、分母、单位、时间窗和零分母处理规则，同一迭代内工作量单位统一为人天或故事点，口径变更需留痕，跨迭代只比较口径一致的区间。
- 计算按四步推进：锁定迭代基线与变更记录、按口径计算三类指标、对照基线判断影响等级、输出影响结论与处置建议，判断规则应在迭代开始前约定。
- 指标描述影响程度，不衡量变更价值，也不直接证明决策对错；横向比较需先固定口径，未完成工作应逐项重新评估，不默认自动结转。
评估目标：范围变更要回答哪三个问题
范围变更发生时，团队真正需要判断的是三件事：迭代目标是否仍然可达、团队容量是否被挤占、交付承诺是否需要重排。这三个问题分别对应目标线、容量线和交付线，指标选择应围绕它们展开，避免收集了一堆数据却回答不了任何一个问题。
目标线关注的是“做完这些事，原定目标还成立吗”。一次变更可能让原目标变得更容易达成，也可能让原目标被稀释。容量线关注的是“人和时间够不够”，新增工作会直接占用迭代内的可用工时。交付线关注的是“对外承诺是否需要调整”，包括承诺给业务方的功能、上线时间和验收标准。
变更类型需要先分类再评估。替换型变更指用新内容替换原计划内容，总工作量可能变化不大，但目标方向改变；新增型变更是在原范围之上增加工作，直接消耗剩余容量；删减型变更释放容量，但可能影响目标完整性。三类变更对三条线的影响方向不同，混在一起统计会掩盖真实影响。
评估时点也分两种。变更发生时做前置评估，目的是判断是否接受变更、是否需要同步调整目标或承诺；迭代结束时做复盘评估，目的是积累变更规律、校准后续排期。前置评估偏重容量和承诺，复盘评估偏重目标达成与返工情况。两种时点使用同一套指标，但解读重点不同。
指标与范围：三类指标及统计边界
指标清单按三条评估线组织，每个指标只回答一个判断问题。下表给出指标名称、定义、所属评估线和统计粒度，作为后续口径定义的输入。
| 指标 | 定义 | 评估线 | 统计粒度 |
|---|---|---|---|
| 迭代目标完成率 | 迭代结束时达成的目标条目数 ÷ 迭代开始时确认的目标条目数 | 目标线 | 按迭代 |
| 目标变更次数 | 迭代周期内对迭代目标条目进行增、删、改的次数 | 目标线 | 按迭代、按变更单 |
| 新增工作量占比 | 变更引入的新增工作量 ÷ 迭代基线承诺工作量 | 容量线 | 按迭代、按变更单 |
| 容量占用率 | 迭代内已分配工作量 ÷ 团队可用容量 | 容量线 | 按迭代 |
| 变更后剩余容量 | 团队可用容量 − 已分配工作量（含变更后） | 容量线 | 按迭代 |
| 范围变更率 | 变更涉及的工作量 ÷ 迭代基线承诺工作量 | 交付线 | 按迭代、按变更单 |
| 变更引入返工量 | 因范围变更导致已完成的、需重做或调整的工作量 | 交付线 | 按变更单、按工作项类型 |
| 迭代承诺达成率 | 按承诺交付的条目数 ÷ 迭代承诺条目数 | 交付线 | 按迭代 |
| 交付周期偏差 | 变更后实际交付时间 − 原计划交付时间 | 交付线 | 按迭代、按交付项 |
统计范围要提前约定。按迭代统计适合看整体影响和趋势；按变更单统计适合追溯单次变更的责任与代价；按工作项类型统计适合识别哪类需求最容易引发范围波动。三种粒度可以并存，但同一份报告内应说明使用的是哪一种，避免把不同粒度的数字放在一起比较。
每个指标都有它不度量的内容。范围变更率不衡量变更的价值，目标变更次数不说明变更是否合理，返工量不区分返工原因是需求变化还是质量问题。指标的作用是描述影响程度，判断变更该不该做需要结合业务价值和决策背景另行讨论。
数据口径：分子、分母、时间窗与缺失值
指标要可复算，必须把公式写死。下表逐项给出分子、分母、单位、时间窗和缺失值处理规则，团队可以直接照此建表取数。
| 指标 | 分子 | 分母 | 单位 | 时间窗 | 缺失值/零分母处理 |
|---|---|---|---|---|---|
| 迭代目标完成率 | 达成的目标条目数 | 迭代开始时确认的目标条目数 | 百分比 | 迭代起止日 | 无目标条目时标注“不适用”，不计为0% |
| 目标变更次数 | 目标条目增删改次数 | 不适用（计数） | 次 | 迭代起止日 | 无变更记0次 |
| 新增工作量占比 | 变更引入的新增工作量 | 迭代基线承诺工作量 | 百分比 | 迭代起止日 | 基线工作量为0时标注“不适用” |
| 容量占用率 | 已分配工作量 | 团队可用容量 | 百分比 | 迭代起止日 | 可用容量为0时标注“数据缺失”并说明原因 |
| 变更后剩余容量 | 不适用（差值） | 不适用 | 人天或故事点 | 变更确认时点 | 容量数据缺失时标注“待补” |
| 范围变更率 | 变更涉及的工作量 | 迭代基线承诺工作量 | 百分比 | 迭代起止日 | 基线为0时标注“不适用” |
| 变更引入返工量 | 需重做或调整的已完成工作量 | 不适用（求和） | 人天或故事点 | 变更确认至迭代结束 | 无返工记0，数据未记录标注“未采集” |
| 迭代承诺达成率 | 按承诺交付的条目数 | 迭代承诺条目数 | 百分比 | 迭代起止日 | 无承诺条目时标注“不适用” |
| 交付周期偏差 | 不适用（差值） | 不适用 | 天 | 原计划交付日至实际交付日 | 未交付时标注“未完成”，不按0天计 |
工作量单位必须统一。同一个迭代内，要么全部用人天，要么全部用故事点，不能一部分工作项用人天、另一部分用故事点再相加。如果团队历史数据单位不一致，应在统计前完成换算并记录换算系数，换算系数本身也要写入口径说明。
分母为零是常见情况，处理规则要事先写清楚。迭代没有承诺项时，承诺达成率没有意义，应标注“不适用”而不是记0%，否则会拉低团队的历史均值。可用容量因请假、借调等原因无法准确统计时，应标注“数据缺失”并记录缺失原因，而不是用估算值填充后当作精确数据使用。
口径变更需要留痕。指标公式、统计范围或单位发生调整时，记录变更日期、变更内容和影响范围。跨迭代对比时，只比较口径一致的区间；口径变更前后的数据要么分别展示，要么在报告中注明不可直接比较。缺失值的处理方式同样要记录，便于后续复核时区分“真的为0”和“没有采集到”。
计算与评估步骤：从取数到形成判断
指标计算按四步推进，每一步都有明确的输入和输出，保证结论可追溯。
第一步，锁定迭代基线与变更记录。基线包括迭代开始时确认的目标条目、承诺工作量、团队可用容量和计划交付时间。变更记录包括每次变更的类型（替换、新增、删减）、涉及工作项、工作量估算、确认时间和确认人。基线一旦锁定，后续计算都以它为准，避免用迭代结束时的范围反推基线导致影响被低估。
第二步，按口径计算三类指标。目标线计算目标完成率和目标变更次数；容量线计算新增工作量占比、容量占用率和变更后剩余容量；交付线计算范围变更率、返工量、承诺达成率和交付周期偏差。计算时逐项核对分子分母来源，分母为零的按口径表标注，不强行计算。
第三步，对照基线判断影响等级。可以设定三档判断规则：目标条目仍可全部达成且剩余容量为正，判为低影响，按原计划执行；目标条目需要删减或替换才能完成，或剩余容量接近零，判为中影响，触发目标重议；承诺交付项无法按期完成，或返工量超过新增工作量的一定比例，判为高影响，触发承诺重排。判断规则由团队在迭代开始前约定，不在变更发生时临时调整。
第四步，输出影响结论与处置建议。结论要写明哪条线受到影响、影响程度如何、依据是哪几个指标值。处置建议包括重排优先级、拆分工作项、将部分内容移出当前迭代、调整对外承诺时间等。处置动作要落到具体工作项和责任人，并在迭代记录中留存，便于复盘时对照。
在取数环节，ONES 的迭代与工作项数据可以作为计算输入：工作项的变更记录、迭代内的任务分配和工作量字段，能够支撑基线锁定与变更追溯；迭代结束后，这些记录也可直接用于复盘对照。工具承载的是数据留存和口径落地，影响等级的判断规则仍需团队事先约定。
例子：一次迭代中途插入需求的完整测算
以下为演示情景，数值为假设，用于说明计算过程，不代表任何真实团队的数据。
假设某迭代周期为两周，团队可用容量为 100 人天。迭代开始时确认 6 个目标条目，承诺工作量 80 人天，计划在第 10 个工作日交付。迭代进行到第 4 天时，业务方插入一个新增需求，估算工作量 15 人天，属于新增型变更；同时有一个原计划条目被替换，原条目 10 人天，替换后为 8 人天。
先算容量线。新增工作量占比 = 15 ÷ 80 = 18.75%。替换型变更净减少 2 人天，变更后总分配工作量 = 80 + 15 − 2 = 93 人天。容量占用率 = 93 ÷ 100 = 93%。变更后剩余容量 = 100 − 93 = 7 人天。剩余容量为正但偏紧，缓冲空间明显收窄。
再算交付线。范围变更率 = （15 + 10）÷ 80 = 31.25%，这里分子取变更涉及的工作量绝对值，替换前后的条目都计入变更范围。假设替换导致一个已完成 3 人天的模块需要调整，变更引入返工量为 3 人天。若按原计划执行，承诺条目中有 1 项预计无法按期完成，承诺达成率预计为 5 ÷ 6 ≈ 83.3%，交付周期偏差预计为 2 天。
目标线方面，6 个目标条目中 1 项被替换、1 项面临延期，目标变更次数为 2 次。按事先约定的判断规则，剩余容量仅 7 人天且承诺达成率低于 100%，判为中高影响，需要重议目标并重排承诺。
处置动作可以包括：将面临延期的承诺项拆分为必须交付和可延后两部分，必须交付部分优先占用剩余容量；与业务方确认插入需求的交付时间是否可以放到下一迭代；对返工模块安排结对处理以压缩调整时间。示例中的容量、工作量和判断阈值均为假设，实际使用时需替换为团队自己的基线数据和约定规则，不能直接套用这里的数值结论。
解读与限制：指标能说明什么、不能说明什么
范围变更率高不必然意味着管理失控。变更可能来自市场机会、合规要求或客户反馈，这些变更本身有业务价值。解读时应结合变更来源和变更带来的收益，区分“被动救火式变更”和“主动响应式变更”，再判断是否需要改进需求准入或排期机制。
指标反映的是影响程度，不直接证明变更决策的对错。一次高影响变更如果带来了关键客户签约，从业务角度看可能是正确决策；一次低影响变更如果反复发生，也可能说明需求梳理不够充分。指标提供的是影响的事实描述，决策评价需要结合目标、成本和收益综合判断。
不同迭代、不同团队之间的数据可比性有限。团队规模、工作项拆分粒度、估算习惯都会影响指标值。横向比较前应先固定口径，确认分子分母、单位、时间窗一致，并说明各自的数据完整度。口径不一致的数据放在一起排名，容易得出误导性结论。
未完成的工作需要重新评估，不默认自动结转到下一迭代。范围变更后未完成的工作项，应在迭代结束时逐项确认是否仍有价值、工作量估算是否仍然准确、优先级是否变化，再决定是进入下一迭代、回到待办列表还是关闭。把未完成项直接带入下一迭代，会让下一迭代的基线失真，也会让范围变更的影响被隐藏。
指标适合作为迭代复盘和改进的输入，不适合单独作为团队绩效结论。使用时应同时呈现目标、容量、交付三条线的数据，并附上变更背景和处置记录，让读者能够理解数字背后的具体情境。
常见问题
迭代中途插入需求时，前置评估应该先看哪几个指标？
前置评估的重点是容量和承诺，建议优先看三个指标：新增工作量占比（变更引入的新增工作量 ÷ 迭代基线承诺工作量）、变更后剩余容量（团队可用容量 − 含变更后的已分配工作量）、交付周期偏差的预计值。这三个指标能快速回答“容量还剩多少、原承诺是否要动”。目标完成率这类结果指标更适合迭代结束时复盘使用，前置阶段只能给出预计值，应标注为预估而非实测。
替换型变更和新增型变更要不要分开统计？
建议分开统计。替换型变更的总工作量可能变化不大，但目标方向改变；新增型变更直接消耗剩余容量；删减型变更释放容量但可能影响目标完整性。三类变更对目标、容量、交付三条线的影响方向不同，混在一起算范围变更率会互相抵消，掩盖真实影响。可以在范围变更率之外，按变更类型分别记录变更单数量和工作量，复盘时再合并看趋势。
团队没有历史基线数据，指标还能算吗？
可以算，但需要先补基线。基线至少包括迭代开始时确认的目标条目、承诺工作量、团队可用容量和计划交付时间，这些数据在迭代启动时记录一次即可。如果历史迭代没有留存基线，建议从当前迭代开始建立记录，历史数据只做定性回顾，不与新口径数据混算。分母为零或基线缺失时，按口径表标注“不适用”或“数据缺失”，不要用估算值填充后当作精确数据参与均值计算。
范围变更率高，是否说明需求管理有问题？
不能直接下这个结论。变更可能来自市场机会、合规要求或客户反馈，本身有业务价值。解读时应结合变更来源和收益，区分被动救火式变更与主动响应式变更，再判断是否需要改进需求准入或排期机制。同时要看变更引入的返工量和承诺达成率：如果变更频繁但返工少、承诺基本达成，说明团队吸收变更的能力较强；如果变更频繁且返工量持续偏高，才更值得检查需求梳理和估算环节。
变更后未完成的工作，直接带到下一迭代会有什么问题？
直接结转会让下一迭代的基线失真，也会把本次范围变更的影响隐藏起来。建议在迭代结束时逐项确认：该工作项是否仍有价值、工作量估算是否仍然准确、优先级是否变化，再决定进入下一迭代、回到待办列表还是关闭。确认过程和结论要留记录，这样下一迭代的承诺工作量和容量占用才有可靠起点，复盘时也能追溯哪些未完成项来自范围变更。
