迭代回顾要真正推动改进，关键在于把会议做成一条可执行、可核对的流程：会前定好范围和数据口径，会中还原事实、找到可改变的原因，会后把少量行动登记为可跟踪的工作项，并在下一次回顾开头逐条核对。未完成的迭代工作需要在回顾时重新评估优先级和拆分方式，不默认自动结转到下一迭代。下面按五步流程、角色分工、完整示例、常见失效点和有效性检查展开。
要点总览（TL;DR）
- 迭代回顾按“定范围与口径—收事实—讨论归因—制定行动—跟踪闭环”五步执行，每步都有明确输入、输出和完成标志。
- 会前由主持人确认迭代范围与数据口径，记录人整理计划与完成对照、缺陷、阻塞和变更记录，会上先过数据再讨论。
- 改进行动控制在三条以内，每条写明负责人、完成标志和验证方式；无人认领的行动不进入清单。
- 未完成的迭代条目要逐条重新评估：优先级下降的回待办池，估算偏差的重新拆分，被阻塞的先解决阻塞再决定是否进入下一迭代。
- 判断回顾是否有效，看上次行动是否逐条核对、改进结果是否可观察，而不只是会开完了。
迭代回顾的五步操作流程
迭代回顾可以拆成五个前后衔接的步骤。每一步都有明确输入、动作和输出，完成标志是进入下一步的前提。团队规模较小或迭代周期较短时，可以把会前准备与事实收集合并到会前半天完成，但不要跳过数据口径的确认。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 定范围与口径 | 本次迭代的起止时间、迭代目标、参与角色名单 | 主持人确认回顾覆盖哪个迭代、统计哪些数据、会议时长与议程；约定“完成”的判定口径，例如是否包含验收通过 | 一份会议通知，写明迭代范围、数据口径、议程和参会人 | 参会人提前知道要带什么数据、讨论什么范围 |
| 2. 收事实 | 迭代计划条目、实际完成条目、缺陷记录、阻塞记录、需求变更记录 | 记录人提前整理计划与实际对照表；把缺陷按严重程度和发现阶段归类；列出阻塞事项及其持续时长 | 事实清单：计划与完成对照、缺陷分布、阻塞与变更记录 | 关键数字能追溯到具体条目，会上不需要现场翻找 |
| 3. 讨论与归因 | 事实清单、团队成员对过程的观察 | 按时间线还原迭代中发生了什么；先描述现象，再追问“为什么会这样”，区分外部约束与团队可改变的工作方式 | 若干条经过讨论确认的原因，按可改变程度排序 | 团队对主要原因形成共识，原因指向具体做法而非泛泛评价 |
| 4. 制定行动 | 确认的原因清单 | 每个原因对应一条改进行动；控制行动数量，一般不超过三条；为每条行动写明负责人、完成标志和验证方式 | 改进行动清单，含负责人、截止时间和完成标志 | 每条行动都有人认领，完成标志可以被第三方判断 |
| 5. 跟踪闭环 | 改进行动清单 | 把行动登记为可跟踪的工作项；下一次回顾开头逐条核对结果，未完成的说明原因并决定继续、调整或放弃 | 行动状态记录与下次回顾的核对结果 | 下次回顾能逐条说出每条行动的结果 |
未完成工作的处理放在第2步和第3步之间：把迭代结束时未完成的条目单独列出，逐条判断是优先级变化、估算偏差还是被阻塞。优先级下降的条目回到待办池重新排序；估算偏差明显的条目重新拆分；被阻塞的条目先解决阻塞再决定是否进入下一迭代。这个判断过程本身也是回顾的事实来源，能帮助团队发现计划与执行之间的偏差模式。
行动闭环环节需要让行动脱离会议纪要、进入日常跟踪。在 ONES 中，可以把每条改进行动登记为工作项，指定负责人和截止时间，借助 ONES Project 的任务管理能力持续查看状态；下次回顾时直接打开这些工作项核对结果。ONES Project 提供看板、燃尽图等工具查看进度，也支持任务工时统计，便于在回顾时对照计划与实际。迭代结束后，还可以用 ONES Wiki 把本次回顾的结论和经验沉淀为团队知识库，供后续迭代参考。
回顾会议的角色分工与交付物
回顾会容易变成无主讨论，常见原因是角色没有提前明确。会议规模不同，一人可以兼任多个角色，但职责要分开写清楚，避免主持人在控场的同时还要记录，导致事实遗漏。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 主持人 | 控制节奏和时间盒，维护发言规则，保证每位成员都有发言机会，把跑题讨论拉回议程 | 会议议程、时间分配、讨论规则说明 |
| 记录人 | 沉淀事实清单、讨论中的关键判断、最终行动与决议，会后整理成可查阅的记录 | 事实清单、回顾记录、改进行动清单 |
| 团队成员 | 提供一线观察，还原具体事件，参与原因讨论并对行动认领负责 | 各自负责的改进行动及完成标志 |
| 产品角色 | 提供业务背景和优先级判断，解释需求变更的原因，参与未完成条目的重新评估 | 优先级调整说明、未完成条目的处理意见 |
| Scrum Master 或团队教练 | 跟进改进行动的执行状态，在迭代过程中提醒负责人，下次回顾前汇总行动结果 | 行动跟踪状态汇总、下次回顾的核对清单 |
记录人的交付物要区分两类内容：事实和判断。计划完成率、缺陷数量、阻塞时长属于事实，直接来自迭代数据；原因分析和行动优先级属于判断，需要标注讨论中形成的共识程度。这样下次回顾翻看记录时，能分清哪些是当时的数据、哪些是当时的推断。
产品角色的参与程度取决于迭代中需求变更的多少。变更频繁时，产品角色应在会前准备好变更原因说明，避免会上用“需求就是这样”结束讨论。团队教练的跟进动作则决定了行动能否闭环：如果没有人负责在迭代过程中提醒和汇总，改进行动很容易停留在记录里。
一次迭代回顾的完整示例
以下为演示情景，用于说明从事实到行动的推演过程，数据为示例数据，不代表真实客户案例。
迭代背景与数据。某团队进行为期两周的迭代，迭代目标为完成订单模块的三个功能点。计划条目12条，实际完成8条；迭代中新增缺陷9个，其中3个为严重缺陷，6个在提测后发现；阻塞记录2条，一条为接口联调等待外部团队，持续3天，另一条为测试环境不可用，持续1天；迭代中发生需求变更2次，均为订单状态字段的调整。
从现象到根因。会上先还原时间线：第一周进展正常，第二周初接口联调受阻，团队转而开发其他条目；联调恢复后集中提测，测试时间被压缩到两天，6个缺陷在提测后集中暴露；两次需求变更都发生在开发后期，导致已完成部分返工。讨论中团队先提出“测试时间不够”，继续追问后发现两个可改变的原因：一是联调依赖没有在迭代计划阶段识别为风险，没有预留缓冲；二是需求变更没有约定评估节点，变更直接进入开发。测试时间被压缩是结果，不是根因。
形成的改进行动。团队控制行动数量，最终确定三条：
- 迭代计划阶段为外部依赖条目标注风险，并预留缓冲时间，负责人为迭代负责人，完成标志是下一个迭代计划中所有外部依赖条目都有风险标注和缓冲说明。
- 需求变更进入开发前，由产品角色和开发负责人共同评估影响并记录，负责人为产品角色，完成标志是下一个迭代的变更记录中能看到评估结论。
- 提测前留出至少一天的联调自测时间，负责人为开发负责人，完成标志是下一个迭代的提测记录中体现自测完成时间。
未完成条目的处理。4条未完成条目中，2条因需求变更返工而延后，优先级仍然较高，重新拆分后进入下一迭代；1条因外部接口未就绪继续阻塞，暂不进入下一迭代，待接口就绪后重新评估；1条经产品角色判断优先级下降，回到待办池。团队没有把这4条默认结转到下一迭代，而是在会上逐条给出了处理结论。
回顾常见失效点与处理办法
回顾流于形式通常有可识别的信号。下面列出五类常见情形及对应处理办法，团队可以在会前对照检查，也可以在会中发现偏离时及时纠正。
| 失效点 | 典型表现 | 处理办法 |
|---|---|---|
| 只谈感受不谈事实 | 讨论集中在“感觉这次很乱”“大家都很累”，没有具体事件和数据支撑 | 会前把事实清单发到参会人手中，会上先过一遍数据再开放讨论；感受可以表达，但归因必须落到具体事件 |
| 行动过多无人负责 | 一次回顾产出七八条行动，散会后没有一条被跟进 | 限制行动数量，按原因优先级取舍；每条行动必须有人当场认领并写下完成标志，无人认领的行动不进入清单 |
| 老问题反复出现 | 连续几个迭代都在讨论同一个问题，行动写了但没有变化 | 下次回顾开头逐条核对上次行动；连续两次未完成的行动，重新分析是行动设计不合理还是执行条件不具备，必要时更换做法而非重复原行动 |
| 成员不敢说真话 | 发言集中在少数人，问题被归因于外部或个别成员 | 主持人明确讨论对事不对人；可以先用书面方式收集观察再汇总讨论，降低当面表达的压力；管理者在场时先说明不追究个人责任 |
| 会议超时与跑题 | 讨论某个技术细节占用大量时间，议程后段被压缩 | 设定时间盒，每个环节到点收束；跑题内容记入待办，会后单独讨论；主持人对超时环节有权中断并转入下一项 |
这些失效点的共同背景是回顾缺少明确的产出约束。把“会上必须产出少量责任到人的行动”作为硬性要求，多数跑题和空谈会在议程设计阶段被过滤掉。团队规模较大时，可以分组讨论再汇总，但行动认领仍要回到具体个人。
完成检查：判断这次回顾是否有效
判断一次回顾是否有效，看的不是会开得是否热闹，而是会前数据、会中产出和会后跟踪是否形成闭环。可以在会议结束前用下面的清单逐项核对，也可以由主持人在下次回顾前复查。
- 会前数据是否齐备：计划与实际完成对照、缺陷记录、阻塞记录、变更记录是否在会前整理完成，关键数字能否追溯到具体条目。
- 行动是否责任到人：每条改进行动是否有明确负责人、完成标志和验证方式，是否存在无人认领的行动。
- 上次行动是否逐条核对：本次回顾开头是否对上一次的每条行动给出结果，未完成的行动是否说明了原因和处理决定。
- 未完成工作是否重新评估：迭代结束时未完成的条目是否逐条判断了优先级、估算和阻塞情况，是否给出了进入下一迭代、拆分、暂缓或回到待办池的结论。
- 改进结果是否可观察：行动完成后，团队的工作方式或迭代数据是否有可观察的变化，例如阻塞时长缩短、提测后缺陷减少、变更评估记录出现。
清单中任何一项为否，都说明回顾的某个环节需要补强。连续多个迭代行动都能被核对、改进结果能被观察到，才说明回顾真正进入了闭环，而不只是完成了一次会议。
常见问题
团队规模小、迭代周期短，五步流程可以压缩吗？
可以合并步骤，但不要跳过关键动作。常见做法是把会前准备与事实收集合并到会前半天完成，会议只保留讨论归因、制定行动和核对上次行动三个环节。需要保留的底线是：数据口径提前确认、事实清单会前发出、行动有人认领并写明完成标志。迭代周期越短，事实清单越要精简，聚焦计划与实际对照、阻塞和变更三类信息即可。
上次回顾定的行动这次没做完，应该怎么处理？
先核对结果，再判断原因。会上逐条说明每条行动的实际进展，区分三种情况：执行条件不具备的，调整做法或补充资源后继续；行动设计本身不合理的，更换做法而不是重复原行动；优先级已经变化的，明确放弃并说明理由。连续两个迭代都未完成的行动，需要重新分析根因，避免把同一条行动反复写入清单。
迭代结束时未完成的工作，回顾会上要给出什么结论？
每条未完成条目都要有明确处理结论，不能默认结转到下一迭代。判断维度包括：优先级是否变化、估算是否偏差、是否被外部依赖阻塞。优先级下降的回到待办池重新排序；估算偏差明显的重新拆分；被阻塞的先解决阻塞再决定是否进入下一迭代。这些判断同时是回顾的事实来源，能帮助团队发现计划与执行之间的偏差模式。
团队成员在会上不愿说真话，主持人能做什么？
先从降低表达压力入手。会前用书面方式匿名收集观察，会上汇总讨论，可以让敏感问题先以事实形式出现。主持人需要明确讨论对事不对人，管理者在场时先说明不追究个人责任。发言集中在少数人时，主持人可以按议题轮流邀请每位成员补充一句观察，把发言机会分散开。这些做法需要持续几个迭代才能建立信任，单次调整效果有限。
回顾会产出的行动，怎么保证下次回顾时能逐条核对？
关键是让行动脱离会议纪要、进入日常跟踪。每条行动登记为可跟踪的工作项，指定负责人和截止时间，迭代过程中由 Scrum Master 或团队教练提醒和汇总状态。下次回顾开头直接打开这些工作项核对结果。在 ONES 中，可以把改进行动登记为工作项，借助 ONES Project 的任务管理能力持续查看状态；迭代结束后还可以用 ONES Wiki 把回顾结论沉淀为团队知识库。
