开始之前先达成共识的一句话
复盘文化的经典、诺姆·克尔斯的《项目复盘》(2001) 要求在开始前全员先就一个前提达成共识: 无论我们发现什么，都真心相信每个人在当时所知、所会、所有的资源和处境下，已经尽了全力。这句话被称为复盘基本指令 (Prime Directive)。
这不是客套话，有实打实的理由。复盘一旦变成追责现场，人们就不再说出问题，而是开始藏起问题，从下一次复盘起，真正的问题就上不了台面了。不指责不是为了显得友善，而是保护复盘赖以运转的数据的装置。
Keep·Problem·Try 三栏各管什么
KPT 源自敏捷宣言联合作者阿利斯泰尔·科伯恩的反思工作坊结构 (要保持的、反复出现的问题、下次要尝试的)，后来在日本开发者社区定型为现在的名字。只有三栏，第一次做的团队几乎不用专门学主持方法。
- Keep: 想继续保持的。写清做得好的事和它为什么奏效。
- Problem: 反复出现的问题。写的是模式，不是某一次事故。
- Try: 下个周期要尝试的。从 Problem 里挑出来，改写成实验。
为什么先做 Keep
先说做得好的事，不是为了活跃气氛。做得好的事大多不是运气，而是某个人可复制的行为，不写明白，下个周期它就悄无声息地消失了。故障早早发到共享频道所以响应快，这不是表扬素材，是要保持的流程。
Keep 栏每次都空着的团队，多半是把门槛定太高了。不需要是了不起的成果，下次还想这么干的，都算 Keep。
Problem 对准的是方式, 不是人
同一个问题，两种写法，能救活一场复盘也能弄死它。以人名当主语的句子是指控，以方式当主语的句子才是改进对象。把形容词去掉、换成可测量的事实，也是诀窍之一。
Try 是实验, 不是决心
复盘沦为清谈就败在这里。加强沟通、做事更细心这样的 Try 什么都改变不了。好的 Try 有实验的形状: 做什么、到什么时候、怎么检验，齐了这三样，下次复盘才能裁定是保留还是放弃。
数量也很关键。一次挑五个 Try 的团队，通常一个都落不了地。选出最疼的那一个 Problem，收敛成一两个实验。复盘一次次做下去，团队里通过验证的规则就一条条攒起来，这才是复盘的产出。
60 分钟流程表
刚引入这套做法的团队，60 分钟足够。不管用便利贴还是共享文档，诀窍是把各自安静写的时间和一起看的时间分开。
| 时间 | 做什么 |
|---|---|
| 开头 5 分钟 | 检查上次复盘的 Try 结果 |
| 10 分钟 | 各自写 Keep, 然后一起读 |
| 20 分钟 | 各自写 Problem, 归类后投票选最疼的 |
| 20 分钟 | 把选中的 Problem 改写成 Try 实验(含负责人和期限) |
| 最后 5 分钟 | 整理记录, 定下次复盘日期 |
常见问题
复盘多久开一次合适?
按冲刺工作的团队每个冲刺结束时开一次，或者两周一次都合适。只在出大事故时才开复盘，复盘这个词就会变成追责的同义词。平时短而频繁地开的团队，才能在问题还小的时候抓住它。
远程团队怎么开?
打开同一份文档，用计时器明确划出各自安静写的时间，效果和面对面差不多。团队比较安静的话，写的阶段可以匿名，从讨论环节再亮名字。远程复盘最常见的失败，就是嫌视频会议里的沉默尴尬，把写的环节跳过去了。
每次复盘都冒出同样的 Problem。
二者必居其一: 要么 Try 没落成真正的实验，所以什么都没变; 要么问题在团队权限之外，复盘解决不了。前者就把 Try 切得更小; 后者就在记录里标成团队外议题，把它送到有权限的人手里，这一步也算复盘的工作。同一个问题写到第三遍，需要的已经不是复盘，而是另一条渠道。