迭代回顾是什么
迭代回顾（Retrospective）是团队定期检视协作与流程的会议：先摆出事实与数据，再聚类问题追问根因，最后收敛成少量可执行的改进项。周期常见每 1-2 个迭代一次，重大事件后也可临时加开。衡量标准是后续迭代里问题是否真的减少，而不是会上聊得是否热闹。
怎么才落得下去
行动项要写进日常看板、指定负责人并在下期开头逐条核对；连续两期未完成的行动项，要么缩小范围重排，要么明确放弃并说明理由，否则会长期挂在墙上变成背景噪声。回顾结论宜在团队范围内公开，让相邻团队了解依赖与改进方向，也便于跨团队问题升级。
基本信息
| 周期 | 每 1-2 个迭代，或重大事件后加开 |
|---|---|
| 输入 | 交付数据、故障与中断记录、成员感受 |
| 产出 | 1-3 个行动项，含负责人与期限 |
| 跟踪 | 下个迭代开头核对上期行动项是否完成 |
典型使用场景
- 迭代结束：对比承诺与实际完成率，找计划偏差的原因
- 线上故障之后：复盘时间线，定位可预防的环节
- 协作出现摩擦：先把感受转成具体事件再讨论
- 新流程试行一段时间：验证是否真的减少等待与返工
- 跨团队项目节点：对齐依赖、接口与升级路径
- 团队规模或人员变动后：重新确认协作约定
六十分钟议程示例
六十分钟议程示例
0-10 min：数据回顾（承诺 vs 完成、故障、中断） # 先摆事实
10-25 min：每人写下最在意的议题并投票 # 人人参与
25-40 min：讨论票数最高的 2-3 个议题根因 # 连问几个为什么
40-55 min：定行动项（负责人 + 期限） # 控制在 3 条内
55-60 min：确认跟踪方式，写进看板 # 否则必然遗忘常见玩法
| 玩法 | 结构 |
|---|---|
| 开始/停止/继续 | 按行为分类，最容易转成具体行动项 |
| 4L | 喜欢、学到、缺少、期待四类 |
| 数据先行 | 先看指标与事件，再看主观感受 |
安全氛围决定回顾质量：有管理者在场时成员常回避真实问题，可先匿名收集议题再合并讨论，会后由主持人与当事人单独确认。
回顾会一旦变成追责会，信任很难恢复，之后能听到的只剩“都挺好”。