迭代回顾会要讨论得具体，一份按阶段组织的引导问题清单比临场提问更可靠。本文提供三张可直接复制的空白表：会议议程表、分阶段引导问题清单和现场记录表，并逐项说明字段含义、必填与选填规则，再用一次两小时回顾会的完整填写示例演示三张表如何配合使用，最后给出随迭代调整维护的方法。
要点总览（TL;DR）
- 迭代回顾会按“回看事实—分析原因—形成改进”三段组织引导问题，配合议程表控制节奏，两小时会议保留9到12个问题即可。
- 现场记录表的必填项是观察到的事实、改进动作、负责人和截止时间；原因未查清时标注待验证，行动项缺负责人时当场指定。
- 每条改进动作要落到具体做法，并写明负责人、截止时间和可观察的验证信号，下轮回顾开头先检查上轮行动项。
- 未完成的行动项在本次回顾中重新评估，明确继续、调整范围或关闭，不默认顺延到下一迭代。
- 模板本身每轮回顾后花五分钟复盘：连续两轮没引出有效讨论的问题，替换或删除，并按团队成熟度调整问题重心。
可复制空白模板：议程表、引导问题清单与现场记录表
三张表分别解决会怎么开、问什么、记什么。建议把议程表和问题清单放在同一份文档里，现场记录表单独建一份，每次回顾复制一份新记录，按迭代命名归档。
表一：迭代回顾会议议程表
| 时间 | 环节 | 引导问题编号 | 负责人 | 环节产出 |
|---|---|---|---|---|
| 会前数据准备 | ||||
| 开场与规则确认 | ||||
| 回看事实 | ||||
| 分析原因 | ||||
| 形成改进 | ||||
| 行动项确认 | ||||
| 收尾与纪要归档 |
表二：分阶段引导问题清单
| 编号 | 阶段 | 问题 | 适用情形 | 追问方向 |
|---|---|---|---|---|
| Q1 | 回看事实 | |||
| Q2 | 回看事实 | |||
| Q3 | 回看事实 | |||
| Q4 | 分析原因 | |||
| Q5 | 分析原因 | |||
| Q6 | 分析原因 | |||
| Q7 | 形成改进 | |||
| Q8 | 形成改进 | |||
| Q9 | 形成改进 |
表三：现场记录表
| 序号 | 观察到的事实 | 影响 | 原因假设 | 改进动作 | 负责人 | 截止时间 | 验证方式 |
|---|---|---|---|---|---|---|---|
| 1 | |||||||
| 2 | |||||||
| 3 |
字段说明：每个栏目记录什么、怎么填
三张表的字段各有分工：议程表管节奏，问题清单管提问质量，记录表管结论落地。填写口径统一后，回顾会才不会变成漫谈。
议程表字段
| 字段 | 填写内容 | 填写口径 |
|---|---|---|
| 时间 | 该环节的起止时间或时长 | 按总时长倒排，给“形成改进”留足时间，通常不少于三分之一 |
| 环节 | 环节名称 | 使用固定名称，便于跨迭代对比 |
| 引导问题编号 | 对应问题清单中的编号 | 一个环节可对应多个编号，用逗号分隔 |
| 负责人 | 主持或引导该环节的人 | 写具体人名，不写“主持人”这类角色代称 |
| 环节产出 | 该环节结束时应得到的东西 | 写成可检查的产物，如“事实清单不少于5条” |
问题清单字段
| 字段 | 填写内容 | 填写口径 |
|---|---|---|
| 编号 | 问题唯一编号 | 按阶段前缀编号，如F1、C1、A1，便于议程引用 |
| 阶段 | 回看事实、分析原因或形成改进 | 一个问题只归一个阶段 |
| 问题 | 问题正文 | 用开放式问法，指向具体对象和时间段 |
| 适用情形 | 什么情况下使用这个问题 | 写明团队阶段、迭代异常类型或会议剩余时间 |
| 追问方向 | 回答笼统时的下一问 | 准备一到两个追问，把回答引向具体事件 |
| 避免的问法 | 同类问题中容易引发防御的表述 | 记录“谁的责任”式问法作为反面参照 |
记录表字段
| 字段 | 填写内容 | 填写口径 |
|---|---|---|
| 观察到的事实 | 迭代中实际发生的事 | 写时间、对象和现象，不写评价 |
| 影响 | 对进度、质量或协作的具体影响 | 尽量带数量或范围，如“延迟两天”“影响三个需求” |
| 原因假设 | 会上讨论出的可能原因 | 标注为假设，未查清时写“待验证” |
| 改进动作 | 下一迭代要做的具体改变 | 写成一个可执行动作，避免“加强沟通”这类表述 |
| 负责人 | 执行改进动作的人 | 写具体人名，会上当场确认 |
| 截止时间 | 完成改进动作的日期 | 落在下一迭代内，便于下轮回顾检查 |
| 验证方式 | 如何判断改进是否生效 | 写成可观察的信号，如“该类缺陷数量下降” |
必填与选填：哪些栏目不能空
记录表最容易出现两种问题：事实写成流水账，行动项没有负责人。用必填规则约束这两处，其余栏目允许留空并注明原因。
| 字段 | 必填/选填 | 留空时的处理 |
|---|---|---|
| 观察到的事实 | 必填 | 不能空；写不出具体事实的议题不进入记录 |
| 改进动作 | 必填 | 不能空；只讨论出原因、没有动作的条目转为待办议题 |
| 负责人 | 必填 | 会上当场指定；确实无法确定时指定临时负责人，下轮回顾前确认 |
| 截止时间 | 必填 | 会上当场约定；跨迭代动作需拆成下一迭代可完成的第一步 |
| 原因假设 | 选填 | 原因未查清时标注“待验证”，并写明由谁在何时验证 |
| 影响 | 选填 | 无法量化时写影响范围，如涉及的环节或角色 |
| 关联工作项编号 | 选填 | 能对应到具体需求、任务或缺陷时填写，便于后续跟踪 |
| 补充备注 | 选填 | 记录分歧意见或会上未展开的线索 |
留空规则的核心是让每条记录都有下一步：原因可以待验证，但必须有人去验证；动作可以小，但必须有负责人和日期。上一迭代未完成的行动项，在本次回顾中重新评估——继续、调整还是关闭，都要在会上明确决定，不默认顺延到下一迭代。
填写示例：一次两小时迭代回顾会的完整记录
以下示例为演示情景，团队为六人研发小组，迭代周期两周。示例展示三张表如何衔接：议程表控制节奏，问题清单提供问法，记录表沉淀结论。
示例议程（两小时）
| 时间 | 环节 | 引导问题编号 | 负责人 | 环节产出 |
|---|---|---|---|---|
| 会前 | 会前数据准备 | — | 李明 | 燃尽图、工时日志、缺陷清单各一份 |
| 0:00–0:10 | 开场与规则确认 | — | 王芳 | 确认讨论规则与时间盒 |
| 0:10–0:40 | 回看事实 | F1、F2、F3 | 王芳 | 事实清单不少于5条 |
| 0:40–1:10 | 分析原因 | C1、C2、C3 | 王芳 | 每条重点事实对应一个原因假设 |
| 1:10–1:40 | 形成改进 | A1、A2、A3 | 王芳 | 改进动作不超过3条，每条可执行 |
| 1:40–1:55 | 行动项确认 | — | 李明 | 负责人、截止时间、验证方式齐全 |
| 1:55–2:00 | 收尾与纪要归档 | — | 李明 | 记录表归档，行动项同步到工作项 |
示例引导问题
| 编号 | 阶段 | 问题 | 适用情形 | 追问方向 |
|---|---|---|---|---|
| F1 | 回看事实 | 本迭代哪些需求按计划交付，哪些延后了？ | 常规回顾开场 | 延后的需求具体卡在哪个环节？ |
| F2 | 回看事实 | 本迭代出现了哪些计划外的工作？ | 迭代中插入较多临时任务时 | 这些工作来自哪里，占用了多少时间？ |
| F3 | 回看事实 | 测试阶段发现了哪些本可以更早发现的问题？ | 质量波动明显时 | 问题最早在哪个环节就有迹象？ |
| C1 | 分析原因 | 延后的需求在等待什么，等待了多久？ | 存在跨角色依赖时 | 等待期间相关人是否知情？ |
| C2 | 分析原因 | 计划外工作进入时，团队是如何决定的？ | 临时任务频繁时 | 有没有可以提前约定的判断标准？ |
| C3 | 分析原因 | 哪些做法本迭代有效，值得保留？ | 需要平衡负面讨论时 | 保留它需要什么条件？ |
| A1 | 形成改进 | 下一迭代我们只改一件事，改哪件？ | 问题较多需要收敛时 | 这件事改好后，哪个指标会变化？ |
| A2 | 形成改进 | 这个改进动作由谁负责，什么时候能看到结果？ | 每条改进动作确认时 | 如果中途受阻，找谁协调？ |
| A3 | 形成改进 | 下轮回顾时，我们用什么信号判断它生效了？ | 行动项收尾时 | 信号从哪里取数或观察？ |
示例记录
| 序号 | 观察到的事实 | 影响 | 原因假设 | 改进动作 | 负责人 | 截止时间 | 验证方式 |
|---|---|---|---|---|---|---|---|
| 1 | 需求“订单导出”在测试前等待接口联调三天 | 该需求延后两天交付 | 联调排期未在迭代计划中约定（待验证） | 迭代计划会上为跨角色联调约定固定时间窗 | 李明 | 下迭代第3个工作日 | 下迭代联调等待时间不超过一天 |
| 2 | 本迭代插入5个临时数据查询需求 | 占用约一天半工时 | 临时需求缺少统一入口 | 临时需求统一提交到需求池，由产品经理每周集中评估一次 | 王芳 | 下迭代结束前 | 下迭代临时插入次数与工时记录 |
| 3 | 测试阶段发现3个接口字段缺失问题 | 返工约半天 | 开发自测清单未覆盖字段校验 | 在自测清单中增加接口字段核对项 | 张涛 | 下迭代第1个工作日 | 下迭代同类问题数量下降 |
示例中每条记录都从事实出发，原因标注为假设，改进动作落到具体做法，并配有负责人、日期和验证信号。记录完成后，行动项需要进入团队的日常工作项中跟踪，否则下轮回顾时无从检查。ONES Project 支持任务管理、迭代管理等场景，任务工时统计与燃尽图可用于会前准备进度数据；ONES Wiki 支持文档关联任务，可将回顾记录与对应工作项关联，并把经验沉淀为团队知识库。具体字段配置以实际使用的产品版本为准。
调整与维护方法：按团队节奏迭代这份清单
模板本身也需要回顾。建议每轮回顾结束后花五分钟检查问题清单：哪些问题引出了具体事实，哪些问题只得到沉默或泛泛回答。连续两轮没有产生有效讨论的问题，替换或删除。
- 按团队阶段替换问题。新组建的团队，问题重心放在事实澄清和角色分工，如“本迭代谁在等谁”；运行较成熟的团队，问题重心转向改进验证，如“上轮行动项的实际效果如何”。
- 控制问题数量。两小时会议保留9到12个问题足够，问题过多会挤压讨论时间。议程表中引用的编号要与问题清单同步更新。
- 行动项跨迭代跟踪。每轮回顾开头先检查上轮行动项：已完成的记录验证结果，未完成的重新评估——继续、调整范围或关闭，并说明原因。未完成工作不默认自动结转。
- 维护模板版本。模板存放在团队固定的知识库位置，文件名带版本号和生效迭代，如“迭代回顾模板_v2_第12迭代起”。修改时保留旧版本，便于追溯某轮回顾使用的是哪版问题。
- 记录归档规则。现场记录表按迭代命名归档，与对应迭代的燃尽图、缺陷清单放在一起，方便下轮回顾取用对比数据。
当团队把回顾记录、行动项和验证结果放在同一处可检索的位置时，模板的调整就有据可依。ONES Wiki 可将回顾文档与工作项关联，配合 ONES Project 的迭代管理，让每轮回顾的改进动作有明确的跟踪对象，减少“会上说得好、会后找不到”的情况。
常见问题
回顾会上讨论很热烈，但会后行动项没人跟进，怎么用记录表解决？
问题通常出在记录表只记了结论，没记跟踪要素。填写时把改进动作、负责人、截止时间三项作为必填，会上当场确认人名和日期，写不出负责人的条目当场指定临时负责人。截止时间落在下一迭代内，跨迭代的大动作拆成下一迭代能完成的第一步。会后把行动项同步到团队日常工作项中跟踪，下轮回顾开头逐条检查：已完成的记录验证结果，未完成的重新评估继续、调整还是关闭。
团队刚开始做迭代回顾，问题清单应该多详细？
新组建的团队，问题重心放在事实澄清和角色分工，比如“本迭代谁在等谁”“哪些需求延后了、卡在哪个环节”。问题数量不必多，两小时会议9到12个足够，每个问题配一到两个追问方向，把笼统回答引向具体事件。问题清单先覆盖三段各两三个问题，跑过几轮后再根据哪些问题真正引出了讨论来增删。
上轮回顾定的改进动作没做完，这次回顾该怎么处理？
在议程开头安排检查上轮行动项的环节，逐条确认状态。已完成的记录验证结果，对照当初约定的验证方式看是否生效；未完成的在会上重新评估——继续、调整范围还是关闭，并说明原因，形成明确决定。未完成工作不默认自动结转，避免行动项越积越多、无人负责。如果一条动作连续两轮没有推进，考虑拆小或换负责人。
回顾记录和行动项放在哪里，才能让下轮回顾查得到？
现场记录表按迭代命名归档，与对应迭代的燃尽图、缺陷清单放在同一处可检索的位置。行动项同步到团队的工作项工具中跟踪负责人和截止时间，回顾文档与对应工作项建立关联，下轮回顾时直接从工作项状态取数据。ONES Project 支持任务管理、迭代管理等场景，任务工时统计与燃尽图可用于会前准备进度数据；ONES Wiki 支持文档关联任务，可将回顾记录与工作项关联并沉淀为团队知识库，具体字段配置以实际使用的产品版本为准。
远程或混合团队开回顾会，模板需要调整吗？
三张表的结构可以沿用，调整集中在两处：一是议程表给每个环节标注明确的引导人和时间盒，远程会议更容易跑题，时间盒要执行得更严格；二是现场记录表由专人实时共享填写，事实条目当场投屏确认，避免会后各人记忆不一致。引导问题可以提前发给参会者，让大家带着事实和数据进会，缩短回看事实环节的耗时。
