迭代回顾记录要把一次迭代的事实、讨论和后续动作写在同一份文档里，方便团队回看和跟进。本文给出一份两周迭代的完整填写示例，覆盖基本信息、目标完成情况、数据事实、问题归纳、行动项和下次检查方式，并逐项说明为什么这样填、换成自己的迭代该怎么调整。示例为演示情景，数值与结论仅用于说明写法。
要点总览（TL;DR）
- 一份可用的迭代回顾记录包含六部分：基本信息、目标完成情况、数据事实、讨论要点与问题归纳、行动项、下次检查方式，缺一部分就难以形成闭环。
- 目标完成情况先写总体结论再分条说明状态；未完成工作要写下重新评估的结论和依据，例如退回修改后放入需求池排期，不默认带入下一迭代。
- 行动项按动作、单一负责人、截止时间、完成标志四项填写，一次回顾控制在三条以内，优先选择影响下一迭代交付的改进。
- 示例适用于单团队、两周左右、目标集中的迭代；跨团队交付或涉及敏感议题时，需补充协调字段和记录约定。
- 回顾记录要与迭代计划、需求池衔接，未完成项评估结论作为下一迭代计划的输入，重新定义的需求回到需求池等待排期。
这份示例要解决什么问题
很多团队的回顾会开得热闹，记录却只剩几句“沟通要加强”“下次注意质量”。这类记录无法支撑下一次检查，也无法让缺席成员了解发生了什么。本示例的目标是给出一份字段齐全、前后自洽的回顾记录，让读者看完就能照着填。
示例设定为一次两周迭代，团队包含产品、开发、测试三类角色，迭代目标是完成订单模块的三个需求并修复上一迭代遗留的高优先级缺陷。文中出现的需求数量、缺陷数、工时等均为演示数据，不对应任何真实客户或项目。
读者可以从这份示例中获得三样东西：一份可直接套用的完整记录结构；每个字段的填写标准和常见错误写法；一套按团队情况调整字段颗粒度的方法。示例不涉及敏捷框架的概念讲解，也不讨论需求池管理的具体做法。
完整示例：一次两周迭代的回顾记录
下面是一份已填写的回顾记录。为便于阅读，按真实记录中常见的顺序排列：先基本信息，再目标完成情况，然后是数据事实、讨论要点、行动项和检查方式。
一、迭代基本信息
| 字段 | 填写内容 |
|---|---|
| 迭代名称 | 订单模块 2024 年第 8 迭代 |
| 迭代周期 | 3 月 4 日至 3 月 15 日，共 10 个工作日 |
| 迭代目标 | 完成订单导出、订单批量取消、订单备注三个需求；关闭上一迭代遗留的 2 个高优先级缺陷 |
| 参与角色 | 产品经理 1 人、开发 3 人、测试 1 人、设计 0.5 人 |
| 回顾会时间与参与人 | 3 月 15 日下午，全员 5 人参加，1 人请假并提前提交书面反馈 |
二、目标完成情况
迭代目标整体达成，三个需求中两个按期上线，订单备注需求完成开发但未通过验收，顺延处理。上一迭代遗留的 2 个高优先级缺陷均已关闭。
- 订单导出：已上线，验收通过。
- 订单批量取消：已上线，验收通过。
- 订单备注：开发完成，验收时发现备注长度限制与产品文档不一致，退回修改。经评估，该需求不自动带入下一迭代，由产品经理重新确认规则后放入需求池排期。
- 遗留缺陷：2 个均已修复并验证关闭。
三、数据事实
| 指标 | 计划 | 实际 | 说明 |
|---|---|---|---|
| 完成需求数 | 3 | 2 上线，1 退回 | 退回原因见目标完成情况 |
| 关闭缺陷数 | 2 个高优先级 | 2 个 | 无新增高优先级缺陷 |
| 迭代内新增缺陷 | — | 7 个，其中中低优先级 6 个 | 集中在订单批量取消的边界场景 |
| 阻塞时长 | — | 累计约 1.5 人天 | 测试环境不稳定，集中在第 6 至第 7 个工作日 |
团队感受部分单独记录：开发同学反馈批量取消需求的接口联调等待时间偏长；测试同学反馈验收标准在开发后期才明确，导致返工；产品经理认为需求规则确认环节可以更早完成。
四、讨论要点与问题归纳
回顾会围绕三个问题展开，最终归纳为两条团队级问题：
- 问题一：验收标准在开发后期才对齐，订单备注需求的长度限制就是典型例子。讨论结论是需求进入开发前需要有一次验收标准确认，参与人包括产品和测试。
- 问题二：测试环境在第 6 至第 7 个工作日不稳定，造成约 1.5 人天阻塞。讨论结论是先由测试同学整理环境问题清单，提交给负责环境的同事处理。
- 未形成团队级问题的讨论：个别成员提出的排期偏紧属于本迭代特例，记录在案但不转为改进行动。
五、改进行动项
| 编号 | 行动项 | 负责人 | 截止时间 | 完成标志 |
|---|---|---|---|---|
| A1 | 在需求进入开发前组织验收标准确认，输出确认记录附在需求下 | 产品经理 | 下一迭代开始前 | 下一迭代三个需求均有验收标准确认记录 |
| A2 | 整理测试环境问题清单并提交处理，跟踪到问题关闭 | 测试同学 | 3 月 22 日 | 清单中问题全部关闭或有明确处理计划 |
| A3 | 重新确认订单备注的长度限制规则，更新需求描述后放入需求池 | 产品经理 | 3 月 20 日 | 需求描述更新完成并完成排期评估 |
六、下次回顾的检查方式
下次回顾会开始前，由本次回顾的记录人逐条核对 A1 至 A3 的完成标志，把核对结果写进下次记录的第一部分。未完成的行动项要在会上说明原因，并决定继续跟进还是关闭。这样每次回顾都从上次的行动项开始，形成连续检查。
逐项解释：每个字段为什么这样填
同样的字段，写法不同，记录的可用性差别很大。下面挑出示例中最容易写偏的几处，说明填写依据和常见错误写法。
目标完成情况写结论，不罗列任务
示例中先给一句总体结论“整体达成，两个上线、一个退回”，再分条说明每个目标的状态。这样读者三秒钟就能判断这次迭代的结果。常见错误是把迭代里的所有任务逐条列出，读完仍不知道目标到底完成没有。判断标准很简单：读完这一段，能否回答“迭代目标达成了吗、差在哪里”。
未完成工作重新评估，不默认结转
订单备注需求没有直接带入下一迭代，而是写明“退回修改、重新确认规则后放入需求池排期”。未完成的工作可能有多种去向：规则不清需要重新定义、优先级下降可以延后、拆分后部分进入下一迭代。回顾记录要写下评估结论和依据，让下一迭代的排期有据可查。直接把未完成项原样搬到下一迭代，会让问题被掩盖，也让下一迭代的承诺失真。
数据事实与主观感受分开记录
示例把计划与实际、缺陷数、阻塞时长放在表格里，把团队感受单独成段。两类信息性质不同：数据可以核对，感受需要讨论。混在一起写，容易让“感觉进度慢”替代“阻塞了 1.5 人天”这样可核查的描述。分开记录后，讨论时可以先看数据，再听感受，问题归纳更有依据。
行动项写到可执行粒度并指定单一负责人
对比两种写法：“加强验收标准沟通”无法判断是否完成；“下一迭代开始前，产品经理组织验收标准确认，输出确认记录附在需求下”则有动作、有负责人、有截止时间、有完成标志。示例中每个行动项都按这四项填写，并且负责人只写一个人。多人负责的行动项在跟进时容易出现互相等待，指定单一负责人、其他人作为参与方，跟进责任更清楚。
检查方式写进记录，形成闭环
示例在最后写明由谁、在什么时间、按什么标准核对行动项。这一步常被省略，结果是行动项写完就没人再看。把检查方式写进本次记录，等于给下次回顾预设了起点，也让行动项的负责人知道会被检查。
可迁移规律：换成自己的迭代怎么改
示例的结构可以直接复用，但字段颗粒度和内容重点需要按团队情况调整。下面区分哪些部分应当固定，哪些部分可以改。
固定骨架与可变内容
建议固定的骨架是：基本信息、目标完成情况、数据事实、讨论要点与问题归纳、行动项、下次检查方式。这六部分对应“发生了什么、结果如何、依据是什么、问题是什么、接下来做什么、怎么验证”的完整链条，缺一部分记录就不完整。可变的是每部分的详细程度：小团队可以把参与角色合并成一行，数据表格只保留三到四个关键指标；跨职能团队则需要把角色和协作接口写得更细。
按迭代长度与团队规模调整颗粒度
一周迭代的回顾记录可以压缩到一页，数据事实只写完成情况和阻塞；一个月以上的迭代，建议把目标完成情况按子目标拆分，数据事实增加质量趋势的描述。团队人数较多时，讨论要点需要注明提出人和讨论范围，避免记录变成会议纪要的流水账。调整的原则是：读者能否据此判断结果和跟进动作，而不是字段越多越好。
行动项数量控制与优先级取舍
示例只保留三条行动项，因为这三条对应两个团队级问题和一个待确认需求。一次回顾产出五条以上行动项，跟进成本会明显上升，完成率往往下降。建议每次回顾的行动项控制在三条以内，优先选择影响下一迭代交付的改进；其余讨论结论可以记录在案，等条件成熟再转为行动项。
回顾记录与迭代计划、需求池的衔接
回顾记录中的未完成项评估结论，应当成为下一迭代计划的输入；重新定义的需求要回到需求池等待排期。示例中订单备注需求的处理就体现了这条链路：回顾记录给出结论，需求池承接重新定义后的需求，下一迭代计划再决定是否纳入。记录、计划和需求池三处信息保持一致，团队才不会在排期会上重新争论已经讨论过的问题。
如果团队使用 ONES，回顾会可以结合燃尽图、工时日志等报表复盘进度、质量和成本偏差，会后用 ONES Wiki 把经验沉淀为团队知识库；记录中的行动项可以关联到 ONES Project 的工作项，围绕迭代安排跟踪状态和待处理事项，减少文档与任务两处维护的负担。
适用边界：哪些情况这份示例不适用
这份示例适用于单团队、两周左右、目标相对集中的迭代。以下情形需要另行处理，直接照搬示例结构可能不够用。
- 跨团队大型迭代：涉及多个团队共同交付时，需要补充协调类字段，例如依赖关系、接口约定、跨团队阻塞和升级路径。示例中的单团队字段无法覆盖这些内容。
- 涉及人员冲突等敏感议题：这类讨论的记录方式需要团队事先约定，例如是否记录原话、记录范围给谁看、后续如何跟进。示例只处理工作层面的问题，不涉及敏感议题的记录规范。
- 示例中的数值与结论仅用于演示：需求数、缺陷数、阻塞时长和行动项内容都是为说明写法而设定的，读者不应把它们当作基准值或参考指标。
- 回顾记录不能替代迭代过程中的实时跟踪：记录是对已发生事实的复盘，迭代中的进度、阻塞和风险需要在过程中及时更新。等到回顾会才第一次暴露的问题，记录得再完整也弥补不了过程中的信息滞后。
判断是否适用，可以问自己两个问题：这次迭代是否由单一团队主导交付；讨论的问题是否集中在工作方式和交付流程上。两个答案都是“是”，示例结构可以直接使用；任一答案是否，就需要在示例基础上补充相应字段和记录约定。
常见问题
回顾会上讨论的问题很多，哪些应该转成行动项？
优先把影响下一迭代交付的问题转成行动项，例如验收标准确认滞后、测试环境不稳定这类会直接造成返工或阻塞的事项。一次回顾的行动项建议控制在三条以内，其余讨论结论记录在案，等条件成熟再转为行动项。个别成员提出的排期偏紧如果属于本迭代特例，记录但不转为改进行动，避免行动项清单变成愿望清单。
行动项负责人写一个人还是写一个小组？
建议指定单一负责人，其他人作为参与方。多人共同负责的行动项在跟进时容易出现互相等待，到了下次回顾谁也说不清进展。示例中的三条行动项都只写一个人，完成标志也按这个人的交付物来定义，核对时责任清楚。
下次回顾会怎么检查上次的行动项？
在本次记录的最后写明检查方式：由谁、在什么时间、按什么标准核对。示例的做法是由本次回顾的记录人在下次回顾会开始前逐条核对完成标志，把结果写进下次记录的第一部分；未完成的行动项在会上说明原因，并决定继续跟进还是关闭。这样每次回顾都从上次的行动项开始，形成连续检查。
团队用工具管理迭代，回顾记录还需要单独写吗？
需要。燃尽图、工时日志等报表能提供进度、质量和成本的数据事实，但目标完成情况的结论、问题归纳和行动项的去向仍要写下来，否则下次回顾缺少可核对的依据。如果团队使用 ONES，可以结合燃尽图、工时日志等报表复盘偏差，会后用 ONES Wiki 把经验沉淀为团队知识库，记录中的行动项可以关联到 ONES Project 的工作项跟踪状态，减少文档与任务两处维护。
一周迭代的回顾记录可以简化到什么程度？
六部分骨架保留，内容压缩到一页左右：基本信息合并成两三行，数据事实只写完成情况和阻塞，讨论要点只记团队级问题，行动项一到两条。判断标准是读者能否据此判断结果并跟进动作，字段数量可以减，结论和负责人不能省。
