迭代评审回顾里复盘范围调整规则，要回答的是“这套规则本迭代有没有起作用、哪里需要改”，而非追究某次变更由谁拍板。做法是把范围变更从口头讨论还原成可核对的事实链：先备齐变更记录，再逐条判定规则被执行、有缺口还是被绕过，最后转成纠偏项、修订项和下个迭代的验证动作。本文按这条主线给出字段表、判定表、角色分工、完整示例和完成检查清单。
要点总览（TL;DR）
- 复盘范围调整规则，先备齐本迭代全部范围变更的事实清单，字段包括变更内容、提出时间、提出人、变更类型、决策人、决策依据和影响的目标与交付物，并区分计划内调整与计划外插入。
- 逐条判定时统一使用三类结论：规则被正确执行、规则本身有缺口、规则被绕过或按例外处理；判定依据看决策时点、约定角色是否参与、是否留下书面依据。
- 判定结论按变更类型汇总，再转成三类可执行结论：执行纠偏项、规则修订项和下个迭代的验证动作，每项写明负责人、时点和完成标志。
- 复盘角色分工要提前约定：迭代负责人准备事实清单并主持判定，产品负责人说明变更依据，团队代表反馈实际影响，记录人形成判定表、修订清单与验证计划并归档。
- 回顾会结束前用检查清单逐项核对，确认事实覆盖完整、每条变更有判定依据、修订项有验证方式、未完成工作已重新评估、结论已归档可追溯。
复盘范围调整规则先要准备哪些事实
回顾会最容易出现的场面是各方凭记忆争论“那次加需求到底谁同意的”。要让讨论落在事实上，迭代负责人应在会前一到两天把本迭代全部范围变更整理成一张清单，会上只核对和补充，不现场翻找。清单的取数口径要统一：以迭代启动时确认的承诺目标为基线，凡是对交付内容、交付时间或验收标准产生实质影响的调整都计入。
范围变更记录建议至少包含以下字段，每个字段都要能指向具体来源，避免填“口头沟通”了事。
| 字段 | 填写要求 | 常见取数来源 |
|---|---|---|
| 变更内容 | 一句话说明改了什么，涉及哪个需求或交付物 | 迭代看板工作项、需求池记录 |
| 提出时间 | 精确到日期，标注处于迭代的哪个阶段 | 工作项创建或更新时间、变更记录 |
| 提出人 | 记录最初提出方，区分业务方、产品、技术 | 评审纪要、沟通记录 |
| 变更类型 | 新增、删减、替换、延期四类中选一 | 复盘时统一归类 |
| 决策人 | 实际拍板的人，与规则约定的角色对照 | 评审纪要、决策记录 |
| 决策依据 | 业务价值、外部约束、技术风险等书面理由 | 变更说明、评审结论 |
| 影响的目标与交付物 | 写明被挤占或调整的承诺项 | 承诺目标清单、燃尽图 |
整理时要区分计划内调整与计划外插入。迭代规划阶段已经预留缓冲、按约定吸收的需求澄清和小幅替换，属于计划内调整，不应算作规则失效的证据；只有突破承诺基线、需要重新决策的变更才进入判定环节。需求澄清如果只是把模糊描述说清楚、交付范围未变，也不计入范围变更，否则清单会被大量噪声淹没。
未完成工作的处理口径同样要写进事实清单。迭代结束时未完成的事项，应逐项重新评估：是继续做、拆小后放入下个迭代，还是取消。默认自动结转到下个迭代会让范围持续膨胀，也会掩盖本迭代范围失控的真实原因。重新评估的结论要作为清单的一部分记录，注明评估人和理由。
逐条判定：规则被执行、有缺口还是被绕过
事实清单备齐后，回顾会进入判定环节。判定针对规则本身，每条变更只回答一个问题：这次调整与现行规则的关系是什么。统一使用三类结论，可以避免讨论滑向个案对错。
- 规则被正确执行：变更在约定时点提出，约定角色参与决策，留下了书面依据，影响也被同步给相关方。这类变更说明规则在运转，可作为正面样本。
- 规则本身有缺口：团队按规则做了，但规则没有覆盖这种情形，例如紧急线上问题导致的范围替换没有对应的快速通道，或跨团队依赖变更缺少约定角色。缺口指向规则需要补充条款。
- 规则被绕过或按例外处理：决策发生在约定时点之后、关键角色未参与、或没有留下书面依据。需要进一步区分是偶发例外还是习惯性绕过，前者记录例外理由，后者指向执行纠偏。
判定依据集中在三点：决策是否发生在规则约定的时点，约定角色是否实际参与，是否留下可查的书面依据。三点都满足归入正确执行；规则未覆盖该情形归入缺口；规则有约定但未照做归入绕过。紧急变更单独归类，标注触发原因和处理时长，避免用一次紧急事件否定整条规则，也避免把紧急当成常态通道。
判定结论按变更类型汇总，而非逐条争论。例如本迭代新增类变更五次，其中三次正确执行、一次暴露缺口、一次被绕过，结论就写成“新增类变更规则基本有效，缺口在跨团队依赖场景，绕过发生在迭代后期”。汇总后再挑一两条典型变更展开细节，会上时间才够用。
| 变更条目 | 判定类别 | 判定依据 |
|---|---|---|
| 变更 A（新增） | 规则被正确执行 | 迭代中期提出，产品与迭代负责人共同决策，有书面说明 |
| 变更 B（替换） | 规则有缺口 | 紧急线上问题触发，规则未约定快速替换通道 |
| 变更 C（新增） | 被绕过 | 迭代后期直接进入开发，无决策记录，约定角色未参与 |
从判定结论到规则修订与验证动作
判定表只是中间产物，回顾会要落到三类可执行结论上，每类都写明负责人、时点和完成标志。
执行纠偏项解决“规则有、但没照做”的问题。动作要具体到谁在什么时点补做什么，例如“迭代负责人从下个迭代起，在迭代中期的范围确认节点检查新增需求是否有决策记录，缺失的当场补登”。完成标志是下个迭代该类变更的书面记录覆盖率达到约定水平。
规则修订项解决“规则没覆盖”的问题。每条修订写清修订哪一条、修订理由、生效时点。修订遵循收敛原则：一次只改少量条款，优先补最常触发的缺口，其余进入待办池排队。频繁大改规则会让团队无所适从，也无法判断哪条修订真正起了作用。
验证动作回答“改完怎么知道有效”。为每条修订指定下个迭代可观察的检验方式，例如“紧急替换通道启用后，统计紧急变更占比与平均处理时长，若紧急变更占比超过约定比例则重新审视通道门槛”。验证结果在下个迭代回顾会上作为固定议题回看，形成闭环。
这些记录需要承载在工作项和文档中才能被追溯。使用 ONES 的团队可以把范围变更登记为迭代下的工作项，把判定表、修订清单和验证计划写入 ONES Wiki 文档并关联对应任务，迭代结束后沉淀为团队知识库；迭代回顾时结合燃尽图、工时日志等报表核对进度与成本偏差。具体字段配置和报表维度以实际开通的功能为准。
角色分工与各环节交付物
复盘变成主持人独讲，通常是因为角色和交付物没有提前约定。会前明确下表的分工，会上按环节推进，会后按交付物验收。
| 角色 | 主要动作 | 交付物 |
|---|---|---|
| 迭代负责人 | 会前整理事实清单，会上主持逐条判定，控制讨论聚焦规则层面 | 范围变更事实清单、判定表 |
| 产品负责人 | 说明每次变更的业务依据与优先级取舍，确认哪些属于计划内调整 | 变更依据补充说明 |
| 团队代表 | 反馈变更对交付节奏、质量和未完成工作的实际影响 | 影响说明与未完成工作重新评估意见 |
| 记录人 | 现场形成判定表、修订清单与验证计划，会后归档 | 规则修订清单、验证计划、归档记录 |
迭代负责人和记录人可以是同一人，小团队里产品负责人也常兼提变更依据，但职责边界要清楚：判定由集体做，记录人只负责如实落笔，不替团队下结论。归档位置固定，下个迭代回顾会开场先回看上期修订项和验证结果，再进入本期事实清单。
示例：一次两周长迭代的范围复盘
以下为演示情景，用于说明流程走法，团队规模和迭代节奏不同需相应调整。
某团队两周长迭代，承诺交付六个需求。迭代中发生四次范围变更：第二次评审后新增一个运营活动需求；第八天因线上故障替换一个原定需求；第十天业务方口头追加一个报表字段；第十一天一个需求因依赖方延期而顺延到下个迭代。迭代结束有两个需求未完成。
事实清单显示：新增活动需求有产品负责人和迭代负责人共同确认的书面记录；线上故障替换由技术负责人发起，规则中无对应快速通道；报表字段追加无决策记录，直接进入开发；依赖延期有书面说明但未同步给业务方。未完成的两个需求经重新评估，一个拆小后放入下个迭代，一个取消。
判定结果为：活动需求属规则正确执行；故障替换暴露规则缺口；报表字段追加属被绕过；依赖延期属正确执行但同步环节缺失。据此产出：纠偏项为迭代负责人下个迭代中期检查新增需求决策记录，记录人为业务方补做延期同步；修订项为补充紧急替换通道条款，明确触发条件与决策角色，下个迭代生效；验证动作为统计下个迭代紧急变更占比和新增需求书面记录覆盖率，在下期回顾会回看。
复盘完成检查清单
回顾会结束前逐项核对，全部满足才算闭环；有缺项的当场指定补做人和时点。
- 事实清单覆盖本迭代全部范围变更，计划内调整与计划外插入已区分。
- 每条变更都有判定类别和判定依据，结论已按变更类型汇总。
- 紧急变更和例外处理单独归类，并注明触发原因。
- 纠偏项写明负责人、时点和完成标志。
- 修订项写明修订条款、理由和生效时点，且本次修订数量控制在少量条款内。
- 每条修订都有下个迭代可观察的验证动作或指标。
- 未完成工作的重新评估结论已记录，未默认结转。
- 判定表、修订清单与验证计划已归档，下个迭代回顾会可追溯。
常见问题
迭代中出现的紧急变更，复盘时应该算规则缺口还是执行问题？
紧急变更单独归类，不直接归入规则缺口或执行问题。先看规则是否约定了紧急通道：如果规则有紧急处理条款且团队按条款执行，归入规则被正确执行；如果规则没有覆盖这类情形，归入规则缺口，需要在修订项中补充触发条件和决策角色；如果规则有约定但团队未按约定时点或角色处理，归入被绕过。紧急变更的触发原因和处理时长要单独记录，避免用一次紧急事件否定整条规则，也避免把紧急当成常态通道。
范围变更记录不完整，回顾会还能开吗？
可以开，但要把补记录作为会前动作。迭代负责人提前一到两天从迭代看板、变更记录、评审纪要和承诺目标清单中整理已有信息，缺失字段标注“待补”并指定补录人。会上先花少量时间核对和补充关键字段，再进入判定。如果某条变更的决策依据确实无法还原，判定时归入“依据缺失”并记录原因，作为下个迭代加强记录的执行纠偏项，而不是凭记忆下结论。
规则修订一次改多少条比较合适？
遵循收敛原则，一次只改少量条款，优先补最常触发的缺口，其余进入待办池排队。修订数量过多会让团队难以适应，也无法判断哪条修订真正起了作用。每条修订要写明修订哪一条、修订理由和生效时点，并为下个迭代设定可观察的验证动作或指标。下个迭代回顾会开场先回看上期修订项的验证结果，再决定是否继续调整。
未完成的工作在复盘时怎么处理？
未完成工作应逐项重新评估，而不是默认自动结转到下个迭代。评估结论可以是继续做、拆小后放入下个迭代，或者取消，并注明评估人和理由。重新评估的结论要作为范围变更事实清单的一部分记录。默认结转会让范围持续膨胀，也会掩盖本迭代范围失控的真实原因。
复盘结论如何在下个迭代中追溯和验证？
判定表、修订清单与验证计划要归档到固定位置，下个迭代回顾会开场先回看上期修订项和验证结果，再进入本期事实清单。验证动作要具体到可观察的指标或变更类型，例如统计紧急变更占比或新增需求书面记录覆盖率。使用 ONES 的团队可以把范围变更登记为迭代下的工作项，把判定表、修订清单和验证计划写入 ONES Wiki 文档并关联对应任务，迭代结束后沉淀为团队知识库；迭代回顾时结合燃尽图、工时日志等报表核对进度与成本偏差。具体字段配置和报表维度以实际开通的功能为准。
