開始之前先達成共識的一句話
回顧文化的經典、諾姆·克爾斯的《專案回顧》(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 切得更小; 後者就在記錄裡標成團隊外議題，把它送到有權限的人手裡，這一步也算回顧的工作。同一個問題寫到第三遍，需要的已經不是回顧，而是另一條渠道。