作者 | 林寧

對于敏捷團隊來說，不斷成長的關鍵是反饋，而反饋的最大信息來源是回顧。

回顧，不是敏捷的專利。

我黨的 “批評與自我批評”，美國陸軍的 AAR，中國航天在每一次發射事故后都會做的”歸零行動“，這些都是回顧。

Retro 是敏捷軟件開發方法中的回顧，Retro 這個單詞的全稱是 Retrospective。Retro 有很多種形式，可以根據團隊所處的上下文來選擇，這里以某次培訓后的回顧會為例，簡單說明 Retro 的一般方法。

一次 Retro 的目標是發現培訓中的問題進行改進，做的好的實踐，以便于繼續堅持，或者挖掘團隊中的金點子和建議。所以在會議中，要求全員積極參與，一般來說聚焦于3個問題：

舉例來說，在一個培訓項目完成后的 Retro 會議可能會收集到如下的清單：

于是，根據 Less well 中的條目，制定改進行動：

• 在課程計劃中添加每日總結的內容
• 使用Parking Lot(停車場，一張大白紙放置學生疑問的便利貼)收集沒有及時回復的問題，在其余時間回復
• 設計作業和批改作業

因此只要堅持使用 Retro 這種會議形式，隨著項目的進行，就會有足夠多的培訓經驗被積累下來。這就是 Retro 的魅力， Retro 本身只是一種形式，但是提供了一種持續改進的方法。

當然，Retro 也不一定限于這三個方面，也有一些其他的 Retro 形式。例如從項目的風險角度出發，這里有另外一種有趣的 Retro 形式 ——《Anchors and Engine》。它使用一個有趣的比喻：團隊像在大海中航行的帆船，目的地是我們團隊的愿景和目標，風是我們前進的動力，而水面下的礁石則是潛在的風險。

通過這種模型，Retro 時需要關注下面幾點：

• 團隊的目標和愿景是什么？
• 團隊前進的動力是什么？
• 團隊的風險是什么？
• 有哪些事情可以幫助到團隊？
• 團隊聚焦在哪里？

對于更多的 Retro 模型，你可以在 funretrospectives.com 的網站上找到類似更多的Retro形式。不過需要注意的是，Retro 的形式是一種套路，而非 Retro 本身。

常用的 Retro 具體的操作方法有兩種，一種是面對面的方式，主持人白板上畫出制定區域，參與者通過報事貼發布自己的想法;另一種是通過一些在線工具讓參與者更為方便的參與 Retro。

面對面 Retro

這里給出便利貼的操作方法，在線工具的方法大同小異，并使用最基本的回顧模型(Well、Less well、Puzzle)。一般 Retro 的時間在30-60分鐘，需要相關的人員全部都參與，其中需要一個主持者全程引導。

下面是具體的操作步驟：

• 主持人在白板上書寫 Well、Less well、Puzzle 三列。
• 主持人回顧上次 Retro 的行動執行情況。
• 所有參與者在5分鐘內書寫報事貼，并貼到白板上，每個報事貼只書寫一項內容。
• 主持人對所有報事貼分類，把相同和類似的內容貼到一起。
• 所有人員需要討論 Less well 的內容，得出行動，但限于時間原因主持人決定討論的數量，一般 3 - 5項。
• 所有人員使用“正”字計數法，對分組后的內容進行投票。
• 團隊逐個討論 Less well，找到可以采取的行動。例如在某次教學活動中，物料準備不夠充分，我們可以采取的行動應該是，每一次教學應該有專人根據物料清單檢查物料情況。
• 得出的行動應該指派到專人負責，否則沒有意義。

面對面的 Retro 最好找一個大一點的會議室，為了讓會議更加高效，可以偷偷的把椅子藏起來，或者約定大家都站立參與。

在線 Retro

如果不能面對面 Retro，通過會議的方式進行效果會差很多。不過可以通過一些在線白板工具來幫助，解決這個問題。

ideaboardz

ideaboardz 是一個在線協作的白板工具，用來進行 Retro、頭腦風暴和協作創新。訪問網址是：https://ideaboardz.com/ 。

我們有較長使用 ideaboardz 的經驗，尤其是疫情期間，遠程工作給團隊帶來一些潛在的問題和不便，包括 Retro 都沒有那么方便的開展。

ideaboardz 讓遠程加入的同事能快速開啟協作，再配合視頻會議的工具下，完成了大量的頭腦風暴、Retro。

Beeart

Beeart 也是一種白板協作工具，它比 ideaboardz 更加靈活。通過在線繪圖的方式來呈現會議事項會方便一些，另外也方便的導出會議結論，便于發到微信群。

上面是一次使用 Beeart 做 Retro 的截圖，我們只使用了最簡單的 Retro 模型，不過令人驚喜的是，Beeart 后來發布了其他的一些思維工具和協作的模板，讓畫圖更加方便了。

讓 Retro 更有效

Retro 只是一種會議形式，其成效取決于會議的主持人和參與者，有一些注意事項給到大家，避免 Retro 流于形式。

“打開”團隊

在 Retro 開始前，如果是新組建的團隊，有可能有團隊成員處于某些原因，不放心說出自己真實感受和問題，可以進行安全度檢查。具體操作方法是進行匿名投票，使用便利貼書寫 “安全” “不安全” 然后由主持人統計查看。如果團隊中存在感受到不安全的成員出現，讓參與者中職級最高的參與者離開，然后再次投票，直到安全為止。

如果有參與者認為團隊環境不安全，無法暢所欲言，不去解決不安全因素而直接開始，Retro 的效果會只能是形式化的，對項目的推動沒有意義。

當團隊成員之間充滿矛盾時，無論怎么推動大家都不愿意暢所欲言，這種 Retro 已經不再有意義。對于這種情況，可能最有幫助的事情就是吃個飯、喝個酒，在沒有防備的時候讓大家吐露心聲。

堅持

Retro 很重要的一個點是持續堅持，如果只做一次 Retro 實際上意義不大。如果一個團隊定期都會舉行 Retro，那么團隊成員就會時刻準備下一次 Retro 可以討論的問題。

Retro 中產出的行動需要有專人負責，即使有些行動是針對團隊所有人，但需要有專人負責提醒、檢查。

行動

每一次 Retro 如果有改進項，都需要制定行動，并有專人負責。一個合適的行動包括了：執行人、截止時間、驗收標準。對于一些復雜的事情，行動只是負責把這件事情合理的創建任務卡，便于跟蹤管理。

Retro 過程中，有些行動往往不能完美的解決問題，會被質疑。這種情況下，需要說服團隊，不能因為沒有完美的方案就不做，因為不做可能會帶來更大的問題。

“歸零” 心態

航天事業中，當出現了一項航天事故后，航天人會將所有的發射計劃推到，并從零開始重新設計發射計劃，并驗證有無問題。

軟件開發過程中，當出現嚴重質量問題時，修復局部往往不能真的解決問題，“歸零” 心態就是從整體性、從零開始，論證整個系統、方案和流程的問題。

Retro 提出的問題、建議，不應該只是當前迭代、表面的問題，也可以從更為深刻的角度出發。