迭代回顾要解决的问题很具体：把一个迭代中发生的事实，转化为下个迭代能执行的改进。做法是按“准备数据—回顾会议—形成改进项—跟踪验证”四步推进，会前收集迭代目标、完成情况、缺陷与阻塞记录，会上按事实、原因、改进三个层次讨论，会后收敛出不超过3条改进项并明确负责人、完成时间和验证方式，下个迭代检查落地情况。未完成的工作项需要重新评估优先级与工作量，不默认自动结转。
要点总览（TL;DR）
- 迭代回顾按“准备数据—回顾会议—形成改进项—跟踪验证”四步执行，每一步都有明确的输入、动作和完成标志，缺一步就容易停在讨论层面。
- 会前由主持人整理迭代目标、完成项、未完成项、缺陷与阻塞四类数据并提前发出；会上按事实、原因、改进的顺序推进，控制在60–90分钟。
- 会后收敛不超过3条改进项，逐条写明负责人、完成时间和可检查的验证方式，并在下个迭代中期和下次回顾会两个时点检查。
- 未完成工作项由产品负责人逐项重新评估优先级与工作量，结论分为继续排入、拆分排入、移出计划，不默认结转到下个迭代。
- 回顾是否有效可用一份检查清单当场核对，重点看数据是否齐全、改进项是否可执行、是否进入跟踪、未完成项是否完成重新评估。
迭代回顾的核心步骤与每步产出
迭代回顾围绕一个已结束的具体迭代展开，四步流程各自有明确的输入、动作和完成标志。缺少任何一步，回顾都容易停留在讨论层面，难以形成可验证的改进。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 会前准备 | 迭代目标、完成项与未完成项清单、缺陷记录、阻塞事项记录 | 主持人整理数据，标注异常点，提前发给参会人 | 一份可供讨论的迭代数据摘要 | 参会人会前已了解数据，会上无需花时间核对基础事实 |
| 回顾会议 | 迭代数据摘要、参会人各自的观察 | 先对齐事实，再分析原因，最后收敛改进项 | 改进项候选清单 | 会议在60–90分钟内结束，形成明确的改进方向 |
| 形成改进项 | 改进项候选清单 | 筛选不超过3条，逐条确认负责人、完成时间、验证方式 | 改进项登记记录 | 每条改进项都有负责人签字确认，验证方式可操作 |
| 跟踪验证 | 改进项登记记录 | 在下个迭代固定时点检查执行情况，记录结果 | 改进项验证结论 | 每条改进项有“已落地/未落地/调整”的明确结论 |
会前准备：让会议从事实出发
会前准备的质量决定会议效率。主持人需要收集四类数据：迭代目标及达成情况、已完成工作项清单、未完成工作项清单、缺陷与阻塞记录。收集完成后，主持人应标注出与计划偏差较大的部分，例如某类任务集中延期、某个模块缺陷密度偏高、某条阻塞持续多日未解决。这些标注不是结论，而是引导会上讨论的线索。
数据摘要建议在会议前至少半天发给参会人，让团队成员有时间回忆和补充。如果团队使用 ONES 管理迭代，迭代中的工作项状态、缺陷记录和迭代进展可以在同一处查看，主持人整理数据时可以直接引用这些记录，减少手工汇总的工作量。
会议环节：按事实、原因、改进的顺序推进
会议讨论分三层，顺序不能颠倒。第一层是事实回顾，对照会前数据确认“这个迭代实际发生了什么”，包括完成了什么、没完成什么、出现了哪些意外。这一层只陈述事实，不展开评价。第二层是原因分析，针对偏差项追问“为什么会这样”，区分偶发因素和系统性因素，例如需求变更频繁属于外部输入问题，估算偏差属于团队方法问题。第三层是改进项收敛，从原因中提炼出团队在下个迭代能控制、能执行的动作。
会议时长控制在60–90分钟。事实回顾约占20分钟，原因分析约占30分钟，改进项收敛约占20分钟，剩余时间用于确认分工。主持人需要在每个环节结束时做小结，防止讨论发散到与当前迭代无关的话题。
会后动作：改进项登记与确认
会议结束当天，主持人应将改进项整理成登记记录，每条包含四项内容：改进内容的具体描述、负责人、完成时间、验证方式。负责人需要当场或会后24小时内确认，避免出现“会上认领、会后遗忘”的情况。验证方式要写成可检查的形式，例如“下个迭代第3天检查新评审流程的执行记录”，而不是“观察是否改善”。
未完成工作项的重新评估
未完成的工作项不默认结转到下个迭代。产品负责人需要逐项判断：该工作项是否仍然必要、优先级是否变化、剩余工作量是否需要重新估算。评估结论有三种：继续排入下个迭代、拆分后部分排入、移出当前计划。这个评估应在回顾会后、下个迭代计划会前完成，避免未评估的工作项直接占用下个迭代容量。
谁来做：回顾中的角色分工与交付物
回顾会议涉及四类角色，各自承担不同的职责和交付物。角色可以兼任，但职责需要明确到人，否则容易出现数据没人准备、改进项没人跟踪的情况。
| 角色 | 职责 | 交付物 |
|---|---|---|
| 主持人（通常是 Scrum Master 或团队负责人） | 准备会前数据、设计会议议程、控制讨论节奏和时间、记录改进项 | 迭代数据摘要、会议记录、改进项登记表 |
| 团队成员（开发、测试等执行角色） | 提供各自负责工作项的事实细节、参与原因分析、认领改进项 | 事实补充说明、原因分析意见、改进项承诺 |
| 产品负责人 | 对未完成需求给出重新评估意见，说明优先级变化和业务影响 | 未完成工作项的处理结论 |
| 技术负责人 | 对技术类改进项给出可行性判断，评估实施成本和风险 | 技术改进项的可行性意见 |
主持人的关键动作在会前和会中：会前把数据整理到“参会人看一眼就能进入讨论”的程度，会中在讨论偏离事实或陷入互相指责时及时拉回。主持人不承担评判对错的角色，而是保障流程完整。
产品负责人的参与重点在未完成工作项的评估环节。如果产品负责人缺席回顾会，未完成项的重新评估容易被推迟到下个迭代计划会，届时时间压力大，评估质量下降。建议产品负责人至少参加事实回顾和未完成项讨论两个环节。
技术负责人的作用体现在改进项的可行性判断上。团队提出的技术类改进，例如引入自动化测试、调整分支策略、优化构建流程，需要技术负责人当场判断是否可在下个迭代内启动、需要哪些前置条件。缺少这一判断，改进项容易写成“计划引入自动化测试”这类无法验证的表述。
一个完整示例：两小时回顾会如何开
以下示例为演示情景，用于说明流程如何落地，数据为虚构。
某团队刚结束一个为期两周的迭代，迭代目标为完成订单模块的三个功能点。实际完成两个功能点，第三个功能点延期；迭代中产生8个缺陷，其中3个为严重级别；有一条阻塞事项持续4天未解决，原因是等待外部接口联调。
会议过程记录
事实回顾（约25分钟）：主持人展示数据摘要。团队确认：功能点A和B按期完成；功能点C延期3天，原因是联调阻塞；8个缺陷中5个在测试阶段发现，3个在上线前回归时发现；阻塞事项在第2天提出，第6天才解决。
原因分析（约35分钟）：针对功能点C延期，团队讨论后确认两个原因：外部接口联调排期未提前确认，属于计划阶段的遗漏；阻塞提出后没有明确的升级路径，导致等待时间过长。针对缺陷分布，测试阶段发现的5个缺陷集中在边界条件处理，回归阶段发现的3个缺陷与功能点B的改动相关，说明改动影响范围评估不足。
改进项收敛（约20分钟）：团队提出若干候选，最终保留3条：
- 改进项1：下个迭代计划阶段，对涉及外部依赖的工作项增加“联调排期确认”检查项。负责人为产品负责人，完成时间为下个迭代计划会前，验证方式为检查下个迭代计划中外部依赖项是否都有排期确认记录。
- 改进项2：建立阻塞事项升级规则，阻塞超过1天未解决时通知团队负责人。负责人为主持人，完成时间为下个迭代第1天，验证方式为下个迭代检查阻塞记录中是否有超期未升级的情况。
- 改进项3：功能点B类改动在提交测试前增加影响范围说明。负责人为技术负责人，完成时间为下个迭代第3天，验证方式为抽查下个迭代的测试提交记录是否附带影响范围说明。
未完成工作项处理（约10分钟）：功能点C剩余工作量经团队重新估算为3天，产品负责人确认其优先级仍为当前最高，决定排入下个迭代，并拆分出一个仅包含内部逻辑的部分先交付，联调部分待外部排期确认后安排。
会议总时长约90分钟。会后当天，主持人将3条改进项登记到团队的工作项管理工具中，与迭代工作项并列跟踪。如果团队使用 ONES，改进项可以作为工作项登记在项目中，与迭代安排一起查看状态；回顾中形成的经验记录也可以沉淀到 ONES Wiki，供后续迭代参考。
改进项如何跟踪与验证
改进项的价值在于落地。跟踪机制需要解决三个问题：记什么、什么时候查、没落地怎么办。
登记字段
| 字段 | 填写要求 |
|---|---|
| 改进内容 | 描述具体动作，避免“加强”“优化”等无法验证的表述 |
| 负责人 | 具体到一个人，不写“团队”或“相关同学” |
| 完成时间 | 落在下个迭代内，精确到日期 |
| 验证标准 | 写成可检查的证据形式，例如记录、清单、抽查结果 |
| 状态 | 未开始、进行中、已完成待验证、已验证、未落地 |
检查时点
建议设置两个检查时点。第一个在下个迭代中期，检查改进项是否已启动、是否遇到阻碍，这个时点用于纠偏。第二个在下个迭代回顾会上，逐条验证改进项是否落地、验证标准是否满足。两个时点都写入迭代计划，作为固定议程，避免被其他事项挤占。
未落地时的处理
改进项未落地时，先判断原因：是负责人时间不足、改进内容本身不可行，还是执行中遇到外部阻碍。原因不同，处理方式不同。时间不足的，评估是否调整负责人或缩小改进范围；内容不可行的，在回顾会上说明并替换为新的改进项；外部阻碍的，记录阻碍因素，判断是否需要升级。无论哪种情况，未落地的改进项都需要有明确结论，不能静默消失。
避免改进项堆积
控制数量是最直接的办法：每次回顾不超过3条改进项，且下个迭代验证完成前不新增同类改进。如果上一条改进项尚未验证，本次回顾提出的同类问题应合并到原改进项中，而不是另立一条。另一个做法是给改进项设置优先级，当团队同时面对多条改进项时，优先执行与当前迭代主要问题直接相关的那条。
完成检查：回顾是否有效的判断标准
回顾结束后，可以用以下清单逐项核对。全部满足，说明这次回顾达到了目的；有未满足项，需要在下次回顾前补上。
| 检查项 | 判断标准 | 核对结果 |
|---|---|---|
| 会前数据是否齐全 | 迭代目标、完成项、未完成项、缺陷与阻塞记录四类数据均有记录，且会前已发给参会人 | 是 / 否 |
| 会议是否围绕事实展开 | 讨论从数据出发，原因分析区分了偶发因素和系统性因素，未陷入互相指责 | 是 / 否 |
| 是否收敛出改进项 | 形成不超过3条改进项，每条有具体动作描述 | 是 / 否 |
| 改进项是否可执行 | 每条改进项有唯一负责人、明确完成时间、可检查的验证标准 | 是 / 否 |
| 改进项是否进入跟踪 | 改进项已登记，下个迭代中期和回顾会两个检查时点已写入计划 | 是 / 否 |
| 未完成工作项是否重新评估 | 每个未完成项有“继续排入/拆分排入/移出”的明确结论，未默认结转 | 是 / 否 |
这份清单也可以作为回顾会议结束前的最后一项议程，由主持人当场逐项确认。当场核对比事后补查更有效，因为参会人都在场，缺失项可以立即补充。对于改进项跟踪这类跨迭代的检查项，可以在下个迭代回顾会开始时先核对上一轮的跟踪结果，形成闭环。
常见问题
迭代回顾会上讨论发散、时间不够用，怎么控制？
控制的关键在会前和议程设计。会前把数据摘要发给参会人，会上不再花时间核对基础事实，讨论就能直接从偏差项开始。议程按事实回顾、原因分析、改进项收敛三段分配时间，主持人每段结束时做小结，把话题拉回当前迭代。
如果某条原因分析持续深入但短期无法定论，主持人可以记录后转入改进项收敛环节，把“继续查清原因”本身作为一条改进项，避免会议被单个议题占满。
团队规模小、角色由一人兼任，回顾还能按角色分工做吗？
可以。角色分工的目的是让每项职责有明确归属，兼任不影响这一点。例如团队负责人同时承担主持人和技术负责人职责时，会前数据准备、会议节奏控制、技术类改进项可行性判断都由同一人完成，但每项交付物仍需单独产出并记录。
需要留意的是产品负责人相关的未完成工作项评估，这部分涉及优先级和业务判断，建议由实际掌握需求决策的人参与，避免评估结论与业务安排脱节。
改进项在下个迭代没有落地，应该怎么处理？
先判断原因，再决定处理方式。负责人时间不足的，评估是否更换负责人或缩小改进范围；改进内容本身不可行的，在回顾会上说明并替换为新的改进项；执行中遇到外部阻碍的，记录阻碍因素并判断是否需要升级。
无论哪种原因，未落地的改进项都要有明确结论，不能静默消失。如果同类问题再次出现，应合并到原改进项中继续跟踪，而不是另立一条新的，否则改进项会越积越多。
回顾会产出的经验记录放在哪里，后续迭代怎么用？
经验记录建议与改进项分开存放：改进项进入工作项跟踪，经验记录沉淀为团队可查阅的文档。团队使用 ONES 时，回顾中形成的经验可以沉淀到 ONES Wiki，供后续迭代参考；改进项可以作为工作项登记在项目中，与迭代安排一起查看状态。
后续使用时，可以在下个迭代回顾会开始时先调出上一轮的经验记录和改进项验证结果，对照检查哪些做法已经生效、哪些问题重复出现，让每次回顾都建立在前一次的基础上。
迭代回顾和迭代计划会之间怎么衔接？
两个会议之间有一项必须完成的动作：未完成工作项的重新评估。这项评估应在回顾会后、下个迭代计划会前完成，由产品负责人逐项给出继续排入、拆分排入或移出计划的结论。
如果评估拖到计划会上才做，时间压力大，容易出现未评估的工作项直接占用下个迭代容量的情况。把评估结论作为计划会的输入，计划会就能直接基于已确认的范围排期，减少反复。
