回顾会议
在项目或冲刺的节点上由团队进行回顾的会议。在敏捷的 Scrum 中被标准地纳入。
回顾会议（Retrospective，简称 Retro）是指在项目或冲刺（Sprint）的节点上，由团队进行回顾的会议。它是“回顾过去、用于下一步”的过程，在敏捷开发的 Scrum 中被标准地纳入。在日本也称为“回顾会”“KPT”。定期设置回顾的场合，就能成为发现工作推进方式的问题并采取措施的契机。
回顾会议的基本结构
框架多种多样，其中简单且广泛使用的是“KPT”。它从 Keep（继续做的事）、Problem（问题点）、Try（下次尝试的事）3 个维度进行回顾。
KPT 以外的框架
| 名称 | 维度 | 适用 |
|---|---|---|
| KPT | Keep / Problem / Try | 通用。被广泛使用 |
| Start / Stop / Continue | 开始 / 停止 / 继续 | 以行动为导向 |
| 4Ls | Liked / Learned / Lacked / Longed for | 重视情感与收获 |
| Mad / Sad / Glad | 怒 / 悲 / 喜 | 想坦诚面对情感的场合 |
| Sailboat | 风（推动力）/ 锚（障碍）/ 礁石（风险）/ 岛（目标） | 重视可视化 |
能发挥作用的回顾会议的条件
- 确保心理安全感（发言不会受到责备）
- 批评过程而不是进行人身攻击
- 在 Try 中定下具体的行动
- 上一次的 Try 反映到下一次的 Keep / Problem 中
- 所需时间以 30-60 分钟左右为参考进行时间盒限制
避免流于形式
回顾会议沦为带着“被迫感”的形式化仪式，原因之一是提出的 Try 迟迟没有被执行。与会后跟进一样，最好把 Try 作为行动项定好负责人和期限，并在下一次开头确认进度，把这个循环纳入进去。
频率的设计
Scrum 在冲刺结束时实施。项目整体的回顾（项目回顾）则按季度或在大规模发布后实施。与例会的优化结合起来，平衡频率与质量。
Try 的粒度决定成败
回顾会议的质量很容易受 Try 的具体程度左右。“改善沟通”这样抽象的 Try 谁也无法执行，下一次同样的 Problem 会再次出现。要细化到像“在晨会最后设置 5 分钟提问时间”这样，负责人明天就能执行、下次能判断是否执行了的粒度。Problem 一方也是如此，如果在持续进行的过程中，从“资源不足”这样过大的课题，逐渐细化到过程中具体的卡点，就可以看作回顾会议开始发挥作用的信号。