(此圖片由 AI 生成)

今天來看 Retro Meeting，是敏捷專案管理中非常重要的一部分。Retro 通常在每個 Sprint 結束後舉行，目的是讓團隊反思 Sprint 的工作過程，發現並討論問題，從而持續改進團隊的工作效率和品質。

回顧會議的目的

反思和學習

團隊成員一起回顧過去的衝刺，反思什麼做得好、什麼地方需要改進，並學習如何在未來的衝刺中避免相同的問題。

以我們工程師來說，可以有很多內容可以提出，包含但不限於：

1. 對隕石與需求變動的改善方式
2. 整體流程上的問題
3. Legacy Code 程式碼與架構的資訊同步

其中我覺得3是最重要的部分，雖然工程師討厭(但又尊敬) Legacy Code，但是屠龍者終成惡龍，我們現在寫的 code 只要未來稍有個一個人員流動斷層或各種原因出現，馬上變成未來後人的 Legacy Code ，每次有後人進來踩前人的雷，就可以在 Retro 中回報並分享，另外也要記錄起來，這樣未來 Sprint 處理類似需求其他人才可以降低踩到雷的衝擊並降低消化 Legacy Code 的成本。

促進團隊合作

回顧會議提供了一個開放、誠實的環境，團隊成員可以自由分享自己的觀點，這有助於促進團隊的合作與信任。

持續改進

敏捷中的一個核心理念就是持續改進。通過定期的回顧會議，團隊可以逐漸完善工作流程，提升生產力和產品品質。

回顧會議常用方法

Start-Stop-Continue，開始做、停止做、繼續做。

筆者我在刷全真題的時候有遇到：詢問 Start-Stop-Keep（開始做、停止做、繼續做）是和敏捷中什麼行為有關？
答案即是衝刺回顧會議。

Start-Stop-Keep（開始做、停止做、繼續做）是一種常見的反思工具，用於敏捷專案中的衝刺回顧會議。幫助團隊成員反思過去的工作，識別哪些實踐應該開始、停止或繼續，以改進未來的工作流程和協作方式。

• Start: 什麼事情我可以開始去做？
• Stop: 什麼事情我可以停止去做？
• Continue: 什麼事情我可以持續去做？

5 Whys，連問五個為什麼？

這是一種原因分析方法，通過連續五次追問「為什麼」，幫助團隊找到問題的根本原因。

圓桌討論

按照順時針或逆時針發言，讓每個人依次分享，確保每個人都有發言的機會。
這是應該算是 Retro 基本方式，總不會順序跳來跳去，要讓每個人都知道現在是誰在講，下一個會由誰講，預期何時輪到自己與每個人都要發言。

挑戰

如果團隊氣氛不夠開放，Retro 效果大打折扣，要有讓團隊鼓勵發言的空間。

而且改進措施提出改進措施後，確保這些措施在後續的衝刺中得到有效執行，這一點非常重要。否則，回顧會議的成果可能難以體現。我曾聽過比較消極的工程師同事說「說了又不會改，那幹嘛說？」但我認為還是要講，當大家都不反應之時，即是這個團隊衰敗的開始。

對事不對人這真的很重要，筆者我就不贅述了。

會議時間當大家暢所欲言時，會議時間可能會拖太久，我之前遇過開一個多小時的，所以要適度避免特定成員搶麥一直講，影響後面其他人的發言時間，這時就仰賴主持人的控場能力了。

結語

回顧會議是的反思，能讓團隊能夠找出好與不好的地方，並將學到的經驗教訓融入未來的工作中。它的有效性取決於團隊的開放性和執行力，但是如果只是流於形式，反而會讓成員感到疲憊和挫折。因此保持對事不對人的討論方式，以及落實改進措施，才能讓團隊不斷進步。