迭代进行到一半，突然插入一个“必须马上做”的需求，或者某个需求被临时扩大，团队原本的交付承诺就会被打乱。处理这类情况的关键是先判断变更来自哪里、影响的是迭代目标还是任务排期，再决定接受、拆分、延期还是拒绝。本文按识别症状、验证原因、分类处置、事后核验的顺序展开，并说明如何借助 ONES 把变更结论和调整记录留在迭代工作项上。
要点总览（TL;DR）
- 范围变更先分清影响的是迭代目标还是任务排期：目标变了需要产品负责人与团队共同决策，排期调整由团队内部协调。
- 把需求澄清滞后、外部插入、估算偏差、依赖方延期当作假设逐条找证据，先看工作项创建记录，再对照工时与燃尽图，最后与依赖方确认。
- 处置方式按条件选择：与目标一致且容量可覆盖则接受，方向正确但超出容量则拆分，重要不紧急或目标不可动摇则延期，与目标冲突或信息不足则拒绝。
- 处置后对照验收标准核验目标达成，逐个确认遗留项去向并重新评估优先级，不默认自动结转到下一迭代。
- 预防复发从需求准入、变更窗口和沟通节奏入手，在迭代回顾中用燃尽图与工时日志复盘变更次数、来源与处置结果。
迭代范围变更的典型症状与影响范围
范围变更已经发生的信号通常很具体：迭代看板上出现计划外的新卡片，某个已排期需求的验收标准被追加条款，或者外部干系人直接调整了优先级却没有同步团队。识别症状之后，下一步是界定它影响的是迭代目标、团队容量，还是仅仅影响任务排期，因为不同影响对应不同的处置力度。
影响迭代目标的变更，指改变了本次迭代要达成的业务结果或交付承诺，例如核心功能被替换、验收标准发生实质变化。仅影响任务排期的变更，指目标不变，只是执行顺序、负责人或完成时间需要调整。前者需要产品负责人和团队共同决策，后者通常由团队内部协调即可。
| 症状表现 | 可能影响的对象 | 影响性质 | 需要同步的角色 |
|---|---|---|---|
| 计划外需求插入当前迭代 | 迭代目标、剩余容量 | 可能改变交付承诺 | 产品负责人、团队、提出方 |
| 已有需求被临时扩大 | 验收标准、工作量估算 | 目标范围实质变化 | 产品负责人、研发、测试 |
| 优先级被外部调整 | 任务排期、依赖关系 | 视调整幅度而定 | 产品负责人、依赖方 |
| 依赖方交付延期 | 任务排期、集成节点 | 多为排期影响 | 团队、依赖方接口人 |
| 验收标准追加条款 | 验收标准、测试范围 | 可能改变目标定义 | 产品负责人、测试 |
界定影响范围时，要同时列出受影响的工作项、验收标准和依赖方。把“哪些工作项需要改”“谁的验收口径变了”“哪个外部团队需要重新对齐”写清楚，后续的原因排查和处置决策才有共同的事实基础。
范围变更从哪来：原因假设与排除证据
看到变更就下结论，容易把执行偏差误判为范围变更，也容易把真正的需求变化当成团队能力问题。更稳妥的做法是把常见原因当作假设，逐条找证据验证，再按排查顺序缩小范围。
常见的原因假设有四类。需求澄清滞后：需求在进入迭代时描述不清，开发过程中才逐步明确，表现为验收标准反复补充。外部干系人插入：业务方或管理层在迭代中途提出新要求，表现为计划外工作项突然出现。估算偏差：任务实际工作量远超预估，表现为剩余工作曲线异常陡峭。依赖方延期：上游接口、设计稿或第三方服务未按时交付，表现为任务卡在等待状态。
| 原因假设 | 验证证据 | 排查顺序 |
|---|---|---|
| 需求澄清滞后 | 需求描述修改记录、验收标准补充时间点、澄清会议纪要 | 先查需求文档与评论历史 |
| 外部干系人插入 | 计划外工作项的创建人、创建时间、提出方的沟通记录 | 查工作项来源与提出渠道 |
| 估算偏差 | 原估算与实际工时对比、燃尽图走势、任务拆分粒度 | 对比工时日志与燃尽图 |
| 依赖方延期 | 依赖项的承诺时间、实际交付时间、阻塞记录 | 查依赖项状态与交接记录 |
区分真实范围变更与执行偏差，关键看“要交付的东西是否变了”。验收标准、功能边界或交付对象发生变化，属于范围变更；目标不变但进度落后、返工增多，属于执行偏差，应按进度问题处理，避免用变更流程掩盖执行问题。排查时建议从证据最容易获取的一类开始，例如先看工作项创建记录，再对照工时与燃尽图，最后与依赖方确认交付时间。
按变更类型处置：接受、拆分、延期与拒绝
原因验证清楚后，处置决策要回答三个问题：这个变更与当前迭代目标是什么关系，团队还有多少剩余容量，已经投入的工作是否需要停止或回退。产品负责人对“要不要做、优先级如何”负责，团队对“能不能在剩余时间内完成、技术风险多大”负责，提出方则需要理解变更对原承诺的影响。
| 处置方式 | 适用条件 | 主要决策角色 | 操作要点 |
|---|---|---|---|
| 接受 | 变更与迭代目标一致，剩余容量可覆盖，或可替换掉同等工作量的低优先级项 | 产品负责人与团队共同确认 | 明确替换关系，更新验收标准与排期 |
| 拆分 | 变更方向正确但工作量超出剩余容量，可切出最小可用部分 | 产品负责人定优先级，团队定拆分方案 | 拆出本期可交付部分，其余进入待办池 |
| 延期 | 变更重要但不紧急，或当前迭代目标不可动摇 | 产品负责人决定，提出方知悉 | 记录延期原因与目标迭代，保留原始描述 |
| 拒绝 | 变更与迭代目标冲突，或缺乏必要信息无法评估 | 产品负责人决定并说明理由 | 书面回复提出方，说明拒绝依据与替代路径 |
涉及已开始的工作时，要先确定停止点。对已经完成部分开发但方向被否定的工作项，评估已投入的代码、测试用例能否复用；不能复用的部分明确标记为废弃，避免后续统计把废弃工作算进交付。回退要考虑对已集成环境的影响，涉及数据或接口变更时，先确认回退方案再执行停止。
变更结论需要落到可追溯的位置：在迭代工作项上更新状态、验收标准和负责人，把决策理由、决策人和时间写进工作项描述或评论；涉及范围调整的，同步更新迭代目标说明。这样在迭代评审和回顾时，团队能还原每一次变更的来龙去脉。ONES 的敏捷研发管理方案把需求规划、迭代跟踪和复盘放在同一条流程里，产品负责人可以把需求规划至迭代，团队用子任务拆分需求，并通过看板管理任务状态，变更后的工作项状态和进度在同一视图中可见。
处置后的验证与复发预防
处置是否生效，要看三个口径：迭代目标是否仍然达成，遗留项是否被明确处理，团队容量是否被透支。目标达成情况对照迭代开始时约定的验收标准判断；遗留项逐个确认去向，重新评估优先级后再决定进入哪个迭代，不默认自动结转到下一迭代；容量是否透支则看实际工时与计划工时的偏差，以及是否出现连续加班或测试被压缩的情况。
- 核对迭代目标：逐条对照验收标准，标记达成、部分达成和未达成。
- 清理遗留项：为每个未完成工作项写明重新评估后的优先级和去向，避免无声结转。
- 检查容量：对比工时日志与计划，确认变更是否导致质量活动被挤压。
- 确认记录完整：变更理由、决策人和调整结果都能在工作项上查到。
降低同类变更反复出现，可以从三个动作入手。需求准入：进入迭代前完成澄清，验收标准与团队达成一致后再排期，减少开发中途补充定义的情况。变更窗口：与提出方约定变更的受理时间和评估节奏，例如每日站会后集中处理，避免随时插入打断执行。沟通节奏：在站会和迭代评审中同步范围状态，让依赖方和提出方及时了解容量约束。
迭代回顾时，用燃尽图、工时日志等数据复盘范围变更的次数、来源和处置结果，讨论哪些变更本可以在计划阶段避免。ONES 支持在迭代回顾会上通过燃尽图、工时日志等报表复盘进度与成本偏差，并可用 ONES Wiki 把复盘结论沉淀为团队知识库，让下一次迭代的范围规则有据可依。
常见问题
迭代中途插入紧急需求，团队剩余容量不够，应该先拆还是先延期？
先看这个需求与当前迭代目标的关系。如果方向与目标一致，只是工作量超出剩余容量，优先考虑拆分：切出本期能交付的最小可用部分，其余进入待办池，由产品负责人确认优先级。如果需求重要但当前迭代目标不可动摇，或者拆分后剩余部分仍无法在迭代内形成可用交付，则选择延期，记录延期原因和目标迭代。两种处置都需要同步提出方，让对方了解对原承诺的影响。
怎么判断是真实的范围变更，还是执行进度落后？
关键看要交付的东西是否变了。验收标准、功能边界或交付对象发生变化，属于范围变更；目标不变但进度落后、返工增多，属于执行偏差，应按进度问题处理。实际操作中可以对照需求描述的修改记录、验收标准补充的时间点，以及燃尽图走势和工时日志，确认变化发生在需求定义层面还是执行层面。用变更流程处理执行问题，会掩盖真实的进度风险。
变更导致部分已开发的工作被废弃，迭代统计怎么处理？
先确定停止点，评估已完成的代码和测试用例能否复用。不能复用的部分明确标记为废弃，不计入本次迭代的交付范围，避免后续统计把废弃工作算成已完成。涉及已集成环境的数据或接口变更时，先确认回退方案再执行停止。处置结论、决策人和时间写进工作项描述或评论，迭代评审时团队能还原这次调整的来龙去脉。
迭代结束时未完成的工作项，可以直接带到下一迭代吗？
不建议默认结转。每个未完成工作项都应重新评估优先级，再决定进入哪个迭代或退回待办池。直接结转会让下一迭代的容量在开始前就被占满，也容易让遗留项长期无人处理。团队可以在迭代规则中事先约定遗留项的标记方式和评估时点，例如在迭代评审会上逐项确认去向。
范围变更频繁发生，复盘时应该看哪些数据？
可以统计变更的次数、来源和处置结果：变更来自需求澄清、外部插入、估算偏差还是依赖方延期，各自占比多少，处置后有多少被接受、拆分、延期或拒绝。结合燃尽图和工时日志看变更对进度与成本的影响，讨论哪些变更本可以在计划阶段避免。ONES 支持在迭代回顾会上通过燃尽图、工时日志等报表复盘进度与成本偏差，并可用 ONES Wiki 把复盘结论沉淀为团队知识库。
