迭代范围变更影响评估记录用于在范围调整进入开发前，把变更内容、影响判断和决策依据固定下来。建议包含五组字段：变更基本信息、变更内容、影响评估、结论与决策、执行与跟踪。本文提供一份可直接复制的空白表格，并逐项说明填写口径、必填规则和完整示例，适用于具体迭代运行中的范围变更评估。
要点总览（TL;DR）
- 迭代范围变更影响评估记录建议包含五组字段：变更基本信息、变更内容、影响评估、结论与决策、执行与跟踪，外加用于识别记录的表头信息区。
- 必填字段覆盖变更来源、影响判断和决策结果；质量与测试影响、依赖与资源影响、落实动作等按变更情形条件必填。
- 影响评估要写判断依据，例如影响天数、人天估算和定级理由，只写结论会让评审无法复核。
- 模板可按团队规模和变更频率裁剪，新增字段统一命名口径，历史记录按迭代归档并保留原字段口径。
- 变更记录在评审或站会中提出，决策后同步更新迭代计划，回顾时核对评估与实际影响的偏差。
可复制空白模板：迭代范围变更影响评估记录表
下表按六个区域组织，空白单元格可直接复制到文档或表格工具中使用。表头信息区用于识别记录本身，其余五个区域对应一次变更从提出到关闭的完整过程。
| 区域 | 字段 | 填写内容 |
|---|---|---|
| 表头信息区 | 记录编号 | |
| 所属迭代 | ||
| 填写日期 | ||
| 变更基本信息区 | 申请编号 | |
| 提出人 | ||
| 提出日期 | ||
| 所属迭代 | ||
| 变更类型 | ||
| 变更内容区 | 原范围 | |
| 拟变更范围 | ||
| 变更原因 | ||
| 关联需求或工作项 | ||
| 影响评估区 | 进度影响 | |
| 工作量影响 | ||
| 质量与测试影响 | ||
| 依赖与资源影响 | ||
| 风险等级 | ||
| 结论与决策区 | 评估结论 | |
| 决策人 | ||
| 决策日期 | ||
| 处理方式 | ||
| 是否调整迭代目标 | ||
| 执行与跟踪区 | 落实动作 | |
| 责任人 | ||
| 完成时间 | ||
| 复盘记录 |
复制时建议保留“区域”列作为分组标识，填写完成后可隐藏该列。若团队使用在线文档或工作项系统承载记录，可将每个区域拆为独立小节，字段名称保持不变，便于跨记录检索和对比。
字段说明：每个字段记录什么、怎么填
同一字段在不同角色手中容易写出不同口径，下面按区域说明含义与填写要求，保证模板、说明和示例使用同一套字段定义。
表头与变更基本信息
| 字段 | 记录什么 | 填写口径 |
|---|---|---|
| 记录编号 | 本条评估记录的唯一标识 | 建议采用“迭代名称-序号”格式，如“S24-03”，便于归档检索 |
| 所属迭代 | 变更发生的迭代 | 填写迭代名称与起止日期，避免同名迭代混淆 |
| 填写日期 | 记录创建日期 | 与提出日期区分，填写日期是记录成文时间 |
| 申请编号 | 变更申请的来源编号 | 与需求单、工单或会议纪要编号对应，便于追溯 |
| 提出人 | 发起变更的角色 | 填写姓名与角色，如“产品经理 张某” |
| 提出日期 | 变更正式提出的日期 | 精确到日，用于判断距迭代结束的剩余时间 |
| 变更类型 | 变更的性质分类 | 可选新增范围、删减范围、替换范围、优先级调整四类，按团队习惯统一 |
变更内容
“原范围”写变更前已纳入迭代的需求或工作项清单，注明数量与关键项；“拟变更范围”写调整后的清单，用增、删、改标注差异。两栏对照填写，评审时无需再翻查原始计划。“变更原因”写触发变更的业务或技术事实，如客户反馈、线上缺陷、依赖方延期，避免只写“需求调整”这类无法判断的表述。“关联需求或工作项”填写系统内的需求编号或任务链接，保证记录与执行对象一一对应。
影响评估
影响评估从五个角度展开，每个角度写判断依据而非只给结论。进度影响说明对迭代结束时间和里程碑的影响天数；工作量影响给出新增或减少的人天估算，并注明估算人；质量与测试影响说明测试范围、回归量和发布风险的变化；依赖与资源影响列出受影响的上下游团队、外部接口或人员安排；风险等级按团队既定标准给出高、中、低，并附一句定级理由。
结论与决策与执行跟踪
评估结论写“建议接受”“建议拒绝”“建议拆分后部分接受”等明确判断；决策人填写有权拍板的角色，决策日期与结论同日或晚于评估完成日；处理方式写具体安排，如“移入下个迭代”“替换低优先级需求”“拆分后本期只做第一部分”；是否调整迭代目标用“是/否”并说明调整内容。执行与跟踪区写落实动作、责任人和完成时间，复盘记录在迭代回顾后补填，说明本次变更的实际影响与评估是否吻合。
必填与选填：哪些字段不能空
必填字段保证记录可追溯、可决策；选填字段按变更复杂度和团队习惯补充。必填缺失时，记录不应进入决策环节。
| 类别 | 字段 | 说明 |
|---|---|---|
| 必填 | 记录编号、所属迭代、填写日期、申请编号、提出人、提出日期、变更类型、原范围、拟变更范围、变更原因、进度影响、工作量影响、风险等级、评估结论、决策人、决策日期、处理方式、是否调整迭代目标 | 缺少任一项，无法判断变更来源、影响和决策结果 |
| 选填 | 关联需求或工作项、质量与测试影响、依赖与资源影响、落实动作、责任人、完成时间、复盘记录 | 小型变更可简化；涉及测试或跨团队依赖时必须补充 |
| 条件必填 | 质量与测试影响 | 变更涉及已提测功能或发布范围时必填 |
| 条件必填 | 依赖与资源影响 | 变更涉及外部团队、接口或人员调配时必填 |
| 条件必填 | 落实动作、责任人、完成时间 | 决策为接受或部分接受时必填，拒绝时可只留决策记录 |
| 条件必填 | 复盘记录 | 迭代回顾完成后补填，未到回顾节点可暂空 |
必填缺失时的处理规则建议统一为：评估人提交前自检，缺失项退回补充；评审会上发现缺失，记录暂缓决策，由提出人当日内补齐；涉及进度和工作量估算的缺失，由评估人补充后再排期。规则写入团队迭代公约，避免每次评审临时争论。
填写示例：一次迭代范围变更的完整记录
以下为演示情景，用于说明各字段的写法，不代表真实项目数据。
背景：某团队迭代 S24 周期为两周，已进行到第 6 天。运营侧提出在本次迭代内增加一个数据导出功能，用于配合下周的客户演示。
| 区域 | 字段 | 示例内容 |
|---|---|---|
| 表头信息区 | 记录编号 | S24-03 |
| 所属迭代 | S24（3月4日—3月15日） | |
| 填写日期 | 3月9日 | |
| 变更基本信息区 | 申请编号 | CR-2024-017 |
| 提出人 | 运营经理 李某 | |
| 提出日期 | 3月9日 | |
| 所属迭代 | S24 | |
| 变更类型 | 新增范围 | |
| 变更内容区 | 原范围 | 本期共 8 个需求，含报表筛选优化、登录体验改进等，无导出功能 |
| 拟变更范围 | 新增“客户数据导出”需求 1 项，其余 8 项不变 | |
| 变更原因 | 下周客户演示需要现场导出数据，演示时间已确定 | |
| 关联需求或工作项 | 需求编号 REQ-231，关联任务 3 个 | |
| 影响评估区 | 进度影响 | 新增开发与联调约 2 天，按当前进度将挤占报表筛选优化的测试时间，迭代结束时间不变但发布内容需取舍 |
| 工作量影响 | 新增约 3 人天（开发 2 人天、测试 1 人天），由开发负责人估算 | |
| 质量与测试影响 | 导出涉及权限校验，需增加 1 轮回归测试；报表筛选优化的测试窗口压缩半天 | |
| 依赖与资源影响 | 依赖数据平台团队开放导出接口，对方本周四前可提供 | |
| 风险等级 | 中：接口依赖有明确时间点，但测试窗口压缩可能影响发布质量 | |
| 结论与决策区 | 评估结论 | 建议部分接受：本期只做基础导出，高级筛选导出移入下个迭代 |
| 决策人 | 产品负责人 王某 | |
| 决策日期 | 3月9日 | |
| 处理方式 | 新增基础导出需求，报表筛选优化顺延至 S25 | |
| 是否调整迭代目标 | 是：本期目标由“报表体验优化”调整为“报表体验优化 + 基础数据导出” | |
| 执行与跟踪区 | 落实动作 | 更新迭代计划与看板，通知测试调整用例范围，同步运营演示口径 |
| 责任人 | 迭代负责人 赵某 | |
| 完成时间 | 3月10日 | |
| 复盘记录 | 回顾时补填：实际新增 3.5 人天，接口按时交付，测试窗口压缩导致 1 个次要缺陷延后修复 |
示例中影响评估部分均写出判断依据，如“按当前进度将挤占测试时间”“接口本周四前可提供”，决策和处理方式与评估结论对应。复盘记录在回顾后补填，体现记录从提出到关闭的闭环。
调整与维护：按团队情况裁剪字段并持续使用
模板落地后需要按团队实际调整，否则容易变成评审会上的额外负担。以下建议可作为裁剪和维护的操作清单。
- 按团队规模裁剪：5 人以下小团队可合并“表头信息区”与“变更基本信息区”，保留记录编号、所属迭代、提出人、变更类型四项；跨团队协作较多的团队保留依赖与资源影响、质量与测试影响两个条件必填字段。
- 按变更频率裁剪：每周多次变更的团队可简化复盘记录为一行结论；变更较少的团队保留完整字段，便于季度汇总分析。
- 新增字段的命名与口径：新增字段使用“对象+判断”的命名方式，如“发布影响”“客户承诺影响”，并在字段说明中写清取值范围，避免同一字段出现多种写法。
- 版本与归档：模板每次调整记录版本号和生效日期，历史记录按迭代归档，保留原字段口径，不随新版本回溯修改。
- 与迭代流程衔接：变更评估记录在迭代评审或每日站会中提出，决策后同步更新迭代计划；迭代回顾时抽取记录核对评估与实际影响的偏差，作为下轮估算参考。
- 定期检查使用情况：每季度抽查记录是否按时填写、必填项是否完整、复盘记录是否补填，连续空置的字段考虑删除或改为选填。
当团队使用 ONES 承载迭代管理时，可将变更涉及的需求与任务规划至对应迭代并分配负责人，利用任务工时统计和燃尽图核对进度影响，评估记录本身可沉淀在 ONES Wiki 文档中并关联相关工作项，使变更决策与执行状态保持在同一处可查。具体字段配置以团队实际开通的版本和项目设置为准。
常见问题
变更被拒绝时，执行与跟踪区还要填吗？
决策为拒绝时，执行与跟踪区可以只保留决策记录，落实动作、责任人、完成时间不必填写。若拒绝后仍需通知提出人或调整相关排期，可把通知动作写入落实动作，便于后续追溯。复盘记录在迭代回顾后按需补填，说明拒绝的原因是否仍然成立。
一次迭代里有多项范围变更，是合并成一条记录还是分开记？
建议按变更来源分开记录，每项变更一条记录，用记录编号区分。多项变更如果来自同一业务诉求且影响评估相互关联，可以在变更内容区合并描述，但结论与决策区仍要分别写明处理方式。分开记录便于回顾时逐项核对评估与实际影响的偏差。
影响评估由谁填写，提出人可以自己评估吗？
影响评估通常由承担开发与测试工作的角色填写，提出人负责说明变更原因和期望时间。工作量估算注明估算人，进度影响由迭代负责人确认。提出人自行评估容易低估对测试和依赖方的影响，建议至少由开发负责人和测试负责人各确认一次。
评估记录和迭代计划如何保持同步？
决策完成后，责任人应在当天更新迭代计划与看板，把新增、删减或替换的工作项落实到具体任务，并通知受影响的测试和依赖方。记录中的落实动作、责任人和完成时间要与计划变更对应。使用 ONES 承载迭代管理时，可将变更涉及的需求与任务规划至对应迭代并分配负责人，评估记录沉淀在 ONES Wiki 文档中并关联相关工作项，具体配置以团队实际开通的版本和项目设置为准。
模板用了一段时间后字段越来越多，怎么判断哪些该删？
每季度抽查一次记录，统计各字段的实际填写率和被引用情况。连续多个迭代空置、且不影响决策复核的字段，可改为选填或删除；被评审反复引用的字段保留并补充填写口径。删除字段时记录版本号和生效日期，历史记录保留原口径，不回溯修改。
