迭代范围变更申请模板由两张表组成：一张变更申请表，记录变更内容、提出人、原因和期望完成时间；一份影响评估记录，记录变更对迭代目标、进度、工作量、质量与依赖的影响，以及评审结论和未完成工作的处理方式。它适用于迭代进行中收到新增、删减、替换或延期请求的场景，帮助团队在评审前把信息收齐，避免会上反复追问。
要点总览（TL;DR）
- 模板由变更申请表和影响评估记录两张表组成，通过变更编号关联，申请表由提出人填写，评估记录由评估人组织填写。
- 变更内容、变更原因、所属迭代、提出人和影响评估结论为必填项；删减和替换类申请还需填写可替代或可延后项。
- 影响评估覆盖迭代目标、进度、工作量、质量与返工风险、依赖五个维度，评审结论固定为接受、有条件接受、拒绝、延至下迭代四种取值。
- 未完成工作应逐项写明重新评估后的处理方式，移出后重新估算，避免直接顺延造成排期虚高。
- 模板按评审会实际讨论内容增删字段，统一入口存放并记录修订版本，在迭代回顾会上定期检查是否仍匹配流程。
可复制空白模板：变更申请表与影响评估记录
下面两张表可以直接复制到文档或表格工具中使用。申请表由提出人填写，影响评估记录由评估人组织填写，两部分通过变更编号关联。表格中的灰色提示文字是填写说明，正式使用时替换为实际内容。
表一：迭代范围变更申请表
| 字段 | 填写内容 |
|---|---|
| 变更编号 | （按团队规则生成，如 ITER-2024-03-CR01） |
| 提出日期 | （YYYY-MM-DD） |
| 提出人 | （姓名／角色） |
| 所属迭代 | （迭代名称与起止日期） |
| 变更类型 | （新增／删减／替换／延期，可多选并说明） |
| 变更内容 | （具体到功能点、范围边界和验收口径） |
| 变更原因 | （业务背景、触发事件、不做的后果） |
| 期望完成时间 | （日期或迭代节点） |
| 紧急程度 | （高／中／低，附判断理由） |
| 初步影响判断 | （提出人对工作量、进度、依赖的初步估计） |
| 申请人签字 | （姓名与日期） |
表二：影响评估记录
| 字段 | 填写内容 |
|---|---|
| 关联变更编号 | （与申请表一致） |
| 评估人 | （姓名／角色，可多人） |
| 评估日期 | （YYYY-MM-DD） |
| 对迭代目标的影响 | （是否影响本迭代承诺的目标，影响程度） |
| 对进度的影响 | （预计延后天数或受影响的工作项） |
| 工作量增减 | （以人天或故事点计，注明估算依据） |
| 质量与返工风险 | （测试范围变化、返工可能性、技术风险） |
| 依赖与关联事项 | （上下游团队、外部系统、关联需求） |
| 可替代或可延后项 | （为腾出容量可调整的现有工作项） |
| 评审结论 | （接受／有条件接受／拒绝／延至下迭代） |
| 未完成工作处理方式 | （重新评估后拆分、移出、降级或关闭，逐项说明） |
| 评审参与人 | （姓名与角色） |
| 生效日期 | （结论开始执行的日期） |
字段说明：每个字段记录什么、怎么填
字段说明的作用是让不同的人填写同一张表时口径一致。尤其是影响评估部分，如果每个人对“工作量增减”的计量方式不同，评审时就无法横向比较。下表逐字段给出含义、填写口径和示例值。
| 字段 | 含义 | 填写口径 | 示例值 |
|---|---|---|---|
| 变更编号 | 唯一标识一次变更申请 | 建议采用“迭代标识-序号”结构，同一迭代内不重复 | ITER-2024-03-CR01 |
| 变更类型 | 变更的性质分类 | 新增指加入原范围外的工作；删减指移出已承诺工作；替换指用一项工作换另一项；延期指整体推迟到后续迭代 | 新增 |
| 变更内容 | 变更的具体对象和边界 | 写到功能点或工作项级别，说明包含什么、不包含什么、验收标准是什么 | 订单列表增加按客户名称模糊搜索，不含导出 |
| 变更原因 | 提出变更的业务动因 | 说明触发事件和不做的后果，避免只写“客户要求” | 大客户上线前验收要求，缺失将影响签约 |
| 紧急程度 | 时间敏感度 | 高：影响本迭代交付或对外承诺；中：影响下迭代排期；低：可择机处理 | 高 |
| 初步影响判断 | 提出人的预估 | 给出粗略工作量与受影响工作项，供评估人参考，不作为结论 | 约3人天，可能影响支付模块联调 |
| 对迭代目标的影响 | 变更与迭代承诺目标的关系 | 说明是否动摇迭代目标，影响是局部还是整体 | 不影响核心目标，挤占优化类工作 |
| 对进度的影响 | 时间维度的后果 | 给出预计延后天数或受影响工作项清单 | 预计延后2天，影响2个工作项 |
| 工作量增减 | 容量变化 | 统一用人天或故事点，注明估算依据和估算人 | +3人天（开发2、测试1） |
| 质量与返工风险 | 对交付质量的影响 | 说明测试范围变化、回归成本和潜在返工 | 需补充回归测试，返工风险中等 |
| 依赖与关联事项 | 外部约束 | 列出上下游团队、接口方和关联需求 | 依赖用户中心接口调整 |
| 可替代或可延后项 | 容量腾挪方案 | 列出可移出本迭代的现有工作项及理由 | 报表样式优化延至下迭代 |
| 评审结论 | 评审会的决定 | 取值固定为接受、有条件接受、拒绝、延至下迭代；有条件接受需写明条件 | 有条件接受：替换报表优化 |
| 未完成工作处理方式 | 受影响工作的去向 | 逐项说明是拆分、移出、降级还是关闭，并注明重新评估的结果 | 报表优化移出，下迭代重新估算 |
| 评审参与人 | 决策与知情人员 | 记录姓名和角色，便于后续追溯 | 产品负责人、技术负责人、测试负责人 |
| 生效日期 | 结论执行起点 | 与评审日期区分，结论需要准备时间时单独标注 | 2024-03-18 |
必填与选填：哪些字段不能空
必填字段的设计目标是让评审会不必为基本信息返工。变更内容、变更原因、所属迭代、提出人和影响评估结论这五项缺失任何一项，申请都不应进入评审。前四项决定“评什么”，评估结论决定“评完怎么执行”。
| 字段 | 必填／选填 | 说明 |
|---|---|---|
| 变更内容 | 必填 | 没有明确对象和边界，评审无法估算 |
| 变更原因 | 必填 | 用于判断变更的必要性和优先级 |
| 所属迭代 | 必填 | 确定影响的是哪一段承诺范围 |
| 提出人 | 必填 | 便于评估阶段追问细节 |
| 影响评估结论 | 必填 | 评审后的执行依据，缺失则变更无法落地 |
| 紧急程度 | 选填 | 提出人可给出判断，评审时可修正 |
| 可替代或可延后项 | 选填，删减和替换类必填 | 删减或替换必须有腾挪方案，否则容量账算不清 |
| 依赖与关联事项 | 选填 | 存在跨团队或外部依赖时填写 |
| 初步影响判断 | 选填 | 提出人有把握时填写，供评估参考 |
提交前可以按以下要点自查：变更内容是否写到可验收的粒度；变更原因是否说明了不做的后果；所属迭代与期望完成时间是否一致；删减或替换类申请是否列出了可替代项；影响评估是否覆盖目标、进度、工作量、质量和依赖五个维度；未完成工作是否逐项写明了处理方式。
填写示例：一次迭代中期的范围变更
以下示例为演示情景：某团队的双周迭代进行到第5个工作日，客户提出在订单列表增加按客户名称搜索的功能。示例展示申请表与评估记录如何对应填写，以及未完成工作如何重新评估。
申请表填写示例
| 字段 | 填写内容 |
|---|---|
| 变更编号 | ITER-2024-03-CR01 |
| 提出日期 | 2024-03-14 |
| 提出人 | 李敏（客户成功） |
| 所属迭代 | 2024年第3迭代（03-11至03-22） |
| 变更类型 | 新增，同时替换一项现有工作 |
| 变更内容 | 订单列表增加按客户名称模糊搜索，支持回车触发，结果高亮匹配词；不含导出和批量操作 |
| 变更原因 | 大客户上线验收清单要求，缺失将影响本周签约 |
| 期望完成时间 | 2024-03-21 |
| 紧急程度 | 高：直接影响本迭代对外承诺 |
| 初步影响判断 | 约3人天，可能影响支付模块联调排期 |
| 申请人签字 | 李敏 2024-03-14 |
影响评估记录填写示例
| 字段 | 填写内容 |
|---|---|
| 关联变更编号 | ITER-2024-03-CR01 |
| 评估人 | 王强（技术负责人）、赵蕾（测试负责人） |
| 评估日期 | 2024-03-15 |
| 对迭代目标的影响 | 不影响核心目标，挤占原定的报表样式优化 |
| 对进度的影响 | 预计延后2天，影响支付联调和报表优化2个工作项 |
| 工作量增减 | +3人天（开发2人天、测试1人天），按历史同类需求估算 |
| 质量与返工风险 | 需补充搜索相关回归测试，返工风险中等 |
| 依赖与关联事项 | 依赖用户中心接口提供客户名称字段 |
| 可替代或可延后项 | 报表样式优化延至下迭代；支付联调保持原计划 |
| 评审结论 | 有条件接受：以报表样式优化移出为条件 |
| 未完成工作处理方式 | 报表样式优化移出本迭代，下迭代重新估算后纳入；支付联调按原计划执行，不自动结转 |
| 评审参与人 | 产品负责人、技术负责人、测试负责人、客户成功代表 |
| 生效日期 | 2024-03-18 |
示例中值得注意的是未完成工作的处理：报表样式优化没有默认顺延到下一迭代，而是移出后重新估算。这样做的原因是下迭代容量和优先级可能已经变化，直接结转容易造成排期虚高。评审结论中的“有条件接受”也写明了条件，执行时可以直接对照检查。
当变更申请和评估记录需要在多人之间流转时，可以把申请表作为工作项、评估记录作为关联文档，评审结论和生效日期随工作项状态更新，归档后按变更编号检索。ONES 的工作项与文档能力可以承载这类流转：申请提交、评估填写、评审结论记录和归档在同一处完成，减少表格在聊天工具中反复传递造成的版本混乱。
调整与维护方法：让模板适配团队节奏
模板的价值在于长期可用，而不是一次填得漂亮。团队规模、迭代长度和评审方式变化后，字段也应随之调整。调整的基本依据是评审会的实际讨论内容：会上反复追问的信息应补为字段，连续几个迭代无人填写的字段可以删除或改为选填。
字段增删的判断依据
- 评审会上多次口头补充的信息，说明申请表缺少对应字段，应补充并写明填写口径。
- 连续两个以上迭代为空且无人查阅的字段，可以删除，避免增加填写负担。
- 团队规模扩大、出现跨团队依赖时，补充“依赖与关联事项”的必填要求。
- 迭代周期缩短时，工作量计量方式应统一到更细的粒度，并在字段说明中更新。
模板存放与版本管理
模板应有统一入口，避免多个副本并存。每次修订记录修订人、修订日期、修订内容和生效日期，旧版本归档保留，便于追溯历史申请是按哪一版填写的。修订记录本身可以作为模板文档的固定附表。
| 修订记录字段 | 填写要求 |
|---|---|
| 版本号 | 按 v1.0、v1.1 递增 |
| 修订日期 | 实际修改日期 |
| 修订人 | 姓名与角色 |
| 修订内容 | 增删了哪些字段、调整了哪些口径 |
| 生效日期 | 新版本开始适用的日期 |
与评审和回顾会议的衔接
可以在迭代回顾会上固定留出几分钟检查模板：本迭代的变更申请是否有字段反复空缺，评估记录是否支撑了评审决策，评审结论的取值是否够用。回顾会形成的调整意见进入修订记录，下一个迭代生效。这样模板随流程一起演进，而不是停留在初次制定时的样子。
变更记录归档与查阅
已完成的变更申请与评估记录应按迭代归档，保留变更编号、评审结论和生效日期三个检索入口。后续复盘范围波动、统计变更频率或回答“这项功能为什么进本迭代”时，可以直接按编号调取原始记录。归档时保持申请表与评估记录的关联关系，避免只存其中一张。
常见问题
迭代进行到一半才提出变更，申请表还来得及走完评审吗？
来得及，但需要压缩评审前的准备时间。提出人应先把变更内容写到可验收的粒度，并说明不做的后果；评估人可以只针对目标、进度、工作量三项做快速判断，质量和依赖维度在评审会上补充。如果变更影响本迭代对外承诺，建议当天完成评估并召集短会，评审结论和生效日期当场记录。迭代末期容量紧张时，评审结论更可能落在“延至下迭代”，此时申请表仍应完整归档，作为下迭代排期的输入。
删减类变更为什么必须填写可替代或可延后项？
删减意味着本迭代承诺的范围减少，但团队容量并不会因此自动释放给其他工作。如果不写明腾挪方案，评审会无法判断减少的这部分容量是用于承接新增请求、提前启动后续工作，还是形成空闲。填写可替代或可延后项，相当于把容量账算清楚，也让被移出的工作有明确去向。替换类变更同理，需要说明用哪项工作换哪项工作。
评审结论为“有条件接受”时，条件应该记在哪里？
条件写在评审结论字段内，与结论取值放在一起，例如“有条件接受：以报表样式优化移出为条件”。条件涉及的具体工作项调整，同步写入可替代或可延后项和未完成工作处理方式两个字段，保证执行时能逐条对照。生效日期填写条件满足后结论开始执行的日期，与评审日期区分开。后续检查时按变更编号调取记录，即可确认条件是否已落实。
团队规模变大或出现跨团队依赖后，模板要改哪些地方？
优先调整依赖与关联事项字段，从选填改为必填，并要求写明上下游团队和接口方。评审参与人字段也需要扩充，把外部依赖方的代表纳入记录。如果团队拆分为多个小组，变更编号规则可以加入小组标识，便于按组检索。字段调整后更新字段说明中的填写口径，并在修订记录中登记，新版本从下一个迭代开始适用。
变更申请和评估记录用什么方式保存，后续复盘才查得到？
按迭代归档，申请表与评估记录保持关联，保留变更编号、评审结论和生效日期三个检索入口。如果使用文档或表格工具，可以把两张表放在同一目录下，文件名带变更编号；如果使用工作管理工具，可以把申请表作为工作项、评估记录作为关联文档，评审结论随状态更新。ONES 的工作项与文档能力可以承载这类流转，申请提交、评估填写、结论记录和归档在同一处完成，减少表格在聊天工具中反复传递造成的版本混乱。
