迭代管理要落成一条可重复的节奏：开始前定清目标和容量，规划会上把工作项拆到一两天能完成的粒度，每日跟进只处理阻塞和计划偏差，范围调整走显式评审，评审看产出、回顾改机制，未完成的工作重新评估后再决定是否进入下一迭代。ONES 可以把迭代目标、Sprint Backlog、阻塞记录和范围变更放在同一处承载，让这条节奏有据可查。下面按阶段说明每一步的输入、动作和产出。
要点总览（TL;DR）
- 迭代开始前先备齐五类输入：一到两条可验证的迭代目标、已排序且带验收口径的候选条目、扣除休假与支持性事务后的容量、团队共识的完成定义、依赖与风险清单。
- 规划会先确认目标和容量，再按优先级挑选工作项，拆到一到两天能完成的粒度，逐条指定负责人和依赖跟进人，形成 Sprint Backlog 并冻结基线。
- 每日跟进控制在十五分钟，看板状态、计划偏差和阻塞项是观察对象；阻塞当场记录责任人和时限，超时升级到迭代负责人，加班放在调整拆分和范围之后。
- 迭代内新增需求先判断是否影响目标，不影响就进需求池排队；必须进入的走等量替换并记录被替换项去向，所有变更留下内容、原因、批准人和对目标的影响。
- 迭代结束时未完成项逐条判断原因、重新评估优先级、重新拆分后再进入候选，不默认自动结转；评审产出反馈条目，回顾产出两到三条带负责人和验证时点的改进项。
迭代开始前要准备哪些输入
规划会开成拍脑袋会，通常是因为会前输入不齐。启动一个迭代前，至少要把五类材料准备到位，并提前发给参会人。
- 迭代目标：本迭代要达成的可观察结果，一到两条即可。目标写成“完成订单模块重构并通过回归测试”比“提升系统质量”更容易在评审时验证。
- 候选工作项：来自需求池、已排序、具备验收口径的条目。排序在需求池阶段完成，规划会只做取舍，不重新排优先级。
- 容量依据：团队可用人力、休假安排、支持性事务占用。容量按人天或故事点估算均可，关键是口径统一并扣除非迭代事务。
- 完成定义：什么状态算完成，包含代码评审、测试通过、文档更新等要求。完成定义是团队共识，不随单个条目临时更改。
- 依赖与风险清单：外部团队接口、测试环境、数据准备等前置条件，标明期望就绪时间和对接人。
这五项齐备后，规划会才有取舍依据。输入缺失时，宁可推迟半天补齐，也不要在会上临时估算容量或现场排序。
迭代规划会怎么开、产出什么
规划会的操作顺序不能倒：先确认目标和容量，再挑选工作项。反过来做，容易出现“先塞满条目再倒推容量”的情况，承诺从一开始就不可信。
- 确认目标与容量：迭代负责人说明本迭代目标，团队确认可用容量，包括休假和支援性事务的扣减。
- 按优先级挑选工作项：从已排序的候选条目中自上而下选取，累计工作量不超过容量。超出容量的条目留在候选池，不进入本迭代。
- 拆到可完成粒度：把选中条目拆成能在一到两天内完成的工作项。拆不动的条目往往意味着验收口径不清或依赖未明，应当场澄清或退回。
- 逐条确认验收口径和负责人：每个工作项写明完成标准，指定负责人。没有负责人的条目不算进入迭代。
- 识别依赖并指定跟进人：对每条外部依赖指定一名跟进人，约定确认时点。
- 形成 Sprint Backlog 并冻结基线：会议结束时产出完整的 Sprint Backlog，作为本迭代的基线，后续变更走显式流程。
会议产出物包括：Sprint Backlog（含负责人、验收口径、依赖跟进人）和迭代基线。基线冻结的意义在于，之后任何范围变化都能与基线对比，而不是凭记忆争论“当初说好做多少”。
每日跟进看什么、怎么处理偏差
每日跟进的价值在于发现偏差并当场处理，逐人汇报进度只会消耗时间。十五分钟的站会，看三样东西：看板状态、计划偏差、阻塞项。
- 看板状态：工作项在各列之间的流动是否正常，有没有长期停在某一列无人推动的条目。
- 计划偏差：剩余工作量与剩余时间的对比，偏差出现时先讨论调整拆分或范围，再考虑加班。
- 阻塞项：当场记录问题、指定解决人和时限，写入阻塞清单。
偏差处理有优先级：拆分过大的工作项可以再拆，范围可以按 S4 的规则调整，加班是最后手段。超过约定时限未解决的阻塞，升级到迭代负责人协调资源。站会控制在十五分钟内，技术细节和方案讨论另开小会，不占用全员时间。
每日跟进的产出是阻塞清单（问题、责任人、时限、升级状态）和偏差处理记录。这两份记录在评审和回顾时是判断迭代健康度的直接证据。
迭代中范围调整怎么管
范围无声膨胀是迭代失控最常见的原因。管住它靠两条：新增需求先判断是否影响迭代目标，以及所有变更留下记录。
新增需求的判断路径：如果它不影响本迭代目标，进入需求池排队，由需求方在下一轮排序中处理；如果它影响目标且必须在本迭代完成，走替换流程——等量替换，说明被替换项的去向（退回候选池或顺延），由迭代负责人确认并记录原因。替换完成后同步更新容量评估和完成预期，让团队和需求方对交付结果有同一预期。
允许中止或缩小迭代的情况需要事先约定，常见的有：关键依赖长期未就绪、目标本身失效、团队容量因突发情况大幅下降。触发这些条件时，由迭代负责人发起，与需求方共同决定中止或缩小范围，并记录决策原因。
范围变更记录的字段包括：变更内容、原因、批准人、对迭代目标的影响。这份记录在回顾时用来分析变更频率和来源，判断是排序机制问题还是外部干扰过多。
评审与回顾分别解决什么问题
评审看产出，回顾改机制，两次会议目标不同，参与人和准备方式也不同。
评审对照迭代目标展示可运行产出，收集反馈并形成后续条目。参与人应包含需求方和下游角色（如运维、客服），他们关心的是产出能否使用、还缺什么。准备要求是：演示真实可运行的成果，不用截图和幻灯片替代；提前列出对照目标的完成情况。评审的产出是反馈条目，进入需求池参与后续排序。
回顾聚焦流程问题，输出少量可执行的改进项。参与人是团队本身，讨论范围是协作方式、工具使用、沟通节奏，不评价个人绩效。改进项控制在两到三条，每条有负责人和验证时点，进入下一迭代跟进。改进项过多等于没有重点，下一迭代无法验证。
两类会议各有常见走偏：评审开成演示会，只展示顺利的部分，回避未达成目标的原因；回顾开成追责会，讨论变成互相指责，改进项无从产生。避免的方式是提前明确议程和产出要求，评审对照目标逐项说明，回顾只谈机制不谈人。
未完成工作如何重新安排
迭代结束时，未完成的工作项逐条处理，不默认自动结转到下一迭代。自动结转会让优先级评估失效，低价值条目靠惯性占用容量。
处置分三步：
- 判断原因：拆分过大、依赖未就绪、优先级变化、估算偏差，四类原因对应不同的改进动作。拆分问题改拆分习惯，依赖问题改前置确认机制，估算偏差积累数据校准。
- 重新评估优先级：按当前业务价值重新排序，已投入的工作量不作为保留理由。优先级下降的条目退回需求池或关闭。
- 重新拆分并补充验收口径：确认仍要做的条目，重新拆分到可完成粒度，补齐验收口径后进入候选池，参与下一轮规划的正常取舍。
对反复未完成的条目做规律分析：同一类条目连续多个迭代完不成，通常指向拆分粒度、依赖管理或验收口径的系统性问题，应在回顾中作为改进项处理。处置结果记入未完成工作项处置表，包含原因、新优先级、是否重新进入候选。
角色分工与各阶段交付物
迭代管理涉及的角色不多，但每个环节的责任要落到人。下表按阶段列出输入、动作、输出和完成标志，可直接作为团队的分工参照。
| 阶段 | 主要负责角色 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 迭代准备 | 迭代负责人、需求方 | 确认目标、整理候选条目、核算容量、明确完成定义 | 迭代启动输入清单 | 五项输入齐备并提前发出 |
| 规划 | 迭代负责人主持，全员参与 | 确认目标容量、挑选并拆分工作项、指定负责人和依赖跟进人 | Sprint Backlog、迭代基线 | 每个条目有负责人和验收口径，总量不超容量 |
| 每日跟进 | 迭代负责人、全体成员 | 查看看板与偏差、记录阻塞、指定解决人和时限 | 阻塞清单、偏差处理记录 | 阻塞项均有责任人和时限 |
| 范围调整 | 迭代负责人、需求方 | 判断影响、执行替换、更新容量与预期 | 范围变更记录 | 变更内容、原因、批准人齐全 |
| 评审 | 迭代负责人、需求方、下游角色 | 对照目标展示产出、收集反馈 | 评审反馈条目 | 反馈条目进入需求池 |
| 回顾 | 团队全体 | 分析流程问题、确定改进项 | 改进项清单 | 每条改进项有负责人和验证时点 |
| 收尾 | 迭代负责人、条目负责人 | 逐条处置未完成项、分析规律 | 未完成工作项处置表 | 无条目默认结转 |
职责冲突时的裁决路径：范围与目标冲突由迭代负责人裁决，优先级冲突由需求方裁决，两者意见不一致时提交到共同上级或产品决策会议，裁决结果记入变更记录，避免同一问题反复争论。开发与测试在完成定义上有分歧时，以迭代开始前确认的完成定义为准，需要修改则在回顾中提出。
这些记录分散在文档和表格里时，跟进成本会明显上升。ONES 的迭代视图可以承载 Sprint Backlog 和看板状态，工作项上记录负责人、验收口径和阻塞原因，范围变更与未完成项处置留痕在同一处，评审和回顾时直接调取，减少会前整理材料的时间。
一个两週迭代的运行示例
以下示例为演示情景，用于说明各环节的时间安排和产出对应关系，不代表特定团队的实际数据。
第一天：规划会。迭代负责人确认本迭代目标为“完成支付模块两个接口上线并通过联调”，团队核算容量为十人天（已扣除一人休假两天）。从候选池按优先级选取条目，拆成十二个工作项，每个不超过两天。识别出外部依赖一项：第三方支付渠道的测试账号，指定跟进人，约定第三天前确认。会议产出 Sprint Backlog 和基线。
第二至九天：每日跟进。每天十五分钟站会，看板显示两个工作项停在“待测试”超过两天，记录为阻塞，指定测试环境负责人当天处理。第五天发现一个工作项实际工作量超出估算，团队当场将其拆为两个，剩余容量重新核算，完成预期顺延半天并在看板标注。
第六天：中期范围调整。需求方提出新增一个对账功能。判断结果：不影响本迭代目标，进入需求池排队。同日另一项原定条目因依赖方接口延期无法开始，团队执行等量替换，将新增的对账条目替换进来，记录被替换项去向（顺延至下一迭代候选），更新容量评估，迭代负责人确认并记录原因。
第十三天：评审。对照目标展示两个接口的联调结果，需求方和运维参加，收集到三条反馈，形成条目进入需求池。
第十四天：回顾与收尾。回顾聚焦两个问题：测试环境阻塞重复出现、一个条目估算偏差过大，各形成一条改进项，指定负责人和下一迭代中期的验证时点。未完成的两个工作项逐条处置：一个因优先级下降退回需求池，一个重新拆分后进入下一迭代候选，均未默认结转。
示例中每个动作都有对应产出：规划会有 Backlog 和基线，跟进有阻塞清单，范围调整有变更记录，评审有反馈条目，回顾有改进项，收尾有处置表。这条产出链就是迭代管理可追溯的基础。
迭代运行是否健康的完成检查
判断迭代管理是否真正运转，可以按下表逐项核对。检查频率建议每个迭代结束时做一次，连续两三个迭代出现同一项不通过，说明该环节的机制需要调整。
| 检查项 | 通过标准 | 证据来源 |
|---|---|---|
| 迭代目标与容量依据 | 每个迭代都有明确的一到两条目标和书面容量核算 | 迭代启动输入清单、规划会记录 |
| 工作项粒度 | Sprint Backlog 中每个条目可在一到两天内完成 | Sprint Backlog |
| 阻塞处理 | 阻塞项均有责任人和解决时限，超时项有升级记录 | 阻塞清单 |
| 范围变更 | 所有变更均有记录和批准人，替换项注明去向 | 范围变更记录 |
| 评审产出 | 评审形成反馈条目并进入需求池 | 评审反馈条目 |
| 回顾改进 | 改进项数量可控，每条有负责人和验证时点 | 改进项清单 |
| 未完成项处置 | 逐条重新评估，无默认结转 | 未完成工作项处置表 |
七项全部通过，说明迭代的规划、执行、变更和收尾形成了闭环。若某几项反复不通过，优先检查对应环节的输入是否齐备、责任人是否明确，再考虑调整流程本身。迭代管理的改进来自每个迭代的回顾积累，而不是一次性设计出完美流程。
常见问题
迭代目标应该写几条，写到什么程度才算可验证？
一到两条即可，写成本迭代结束时能用产出对照的结果。比如“完成支付模块两个接口上线并通过联调”可以在评审时逐项核对；“提升系统质量”无法在评审时判断是否达成。目标过多会让取舍失去依据，规划会上挑选工作项时也难以判断哪些该进、哪些该留。
目标确定后，规划会挑选工作项、迭代中判断新增需求是否影响目标、评审对照目标展示产出，都围绕这一到两条展开。目标本身失效时，按事先约定的条件中止或缩小迭代，并记录决策原因。
团队容量怎么估算，休假和支持性事务要不要扣？
容量按人天或故事点估算都可以，关键是全团队口径统一，并把非迭代事务扣除。休假、值班、线上支持、面试等占用要先从总人力中减掉，剩下的才是可用于本迭代的容量。示例中团队核算容量为十人天，已扣除一人休假两天，这类扣减写在容量依据里，规划会上直接引用。
迭代进行中如果容量因突发情况大幅下降，属于允许缩小迭代的常见触发条件，由迭代负责人发起，与需求方共同决定并记录原因。
迭代中途需求方坚持要加一个需求，怎么处理才不伤协作？
先判断它是否影响本迭代目标。不影响就进入需求池排队，由需求方在下一轮排序中处理，这个结论要当面说清，避免需求方误以为被搁置。影响目标且必须在本迭代完成的，走等量替换：说明被替换项的去向（退回候选池或顺延），由迭代负责人确认并记录原因，替换后同步更新容量评估和完成预期。
把判断路径事先约定好，比每次临时争论更省事。范围变更记录里的变更频率和来源，在回顾时可以用来判断是排序机制问题还是外部干扰过多。
未完成的工作项为什么不能直接结转到下一迭代？
自动结转会让优先级评估失效，低价值条目靠惯性占用容量，下一轮规划会失去取舍空间。正确做法是逐条处理：先判断原因（拆分过大、依赖未就绪、优先级变化、估算偏差），再按当前业务价值重新排序，已投入的工作量不作为保留理由；确认仍要做的条目重新拆分、补齐验收口径后进入候选池，参与下一轮规划的正常取舍。
同一类条目连续多个迭代完不成，通常指向拆分粒度、依赖管理或验收口径的系统性问题，应在回顾中作为改进项处理，而不是每次收尾时重复处置。
评审和回顾能不能合并成一次会议？
不建议合并。评审的参与人包含需求方和下游角色，关注产出能否使用、还缺什么，产出是反馈条目；回顾的参与人是团队本身，讨论协作方式、工具使用和沟通节奏，产出是两到三条带负责人和验证时点的改进项。参与人和议题都不同，合并后容易出现评审占满时间、回顾草草收场的情况。
两次会议各有常见走偏：评审开成演示会，只展示顺利的部分；回顾开成追责会，讨论变成互相指责。提前明确议程和产出要求，评审对照目标逐项说明，回顾只谈机制不谈人，可以降低走偏的概率。
