如果是有在跑 scrum 的團隊，應該對於 retro 這個詞並不陌生。在 scrum 這套方法中，每一個 sprint 結束後，團隊都會開一個回顧會議（也就是 retro，全名是 retrospective），讓大家一起討論有哪些做得好或不好的地方。此外，網路上也已經有很多 retro 相關資訊，甚至包含 retro 需要用的的模版都有了，可參考下面 2 篇文章：
1. 17 Sprint Retrospective Examples for Exciting End of Sprints
2. How to Run a Sprint Retrospective Meeting
之所以想寫這篇文章，是因為我的現職公司有進行 retro 的慣例，執行幾次下來，也覺得效果不錯，所以想記錄一下我們是如何進行、有哪些要特別注意的事，有需要的人可以參考。
※ 補充一些背景資訊：雖然我的現職公司並沒有跑 scrum，但仍會盡量注入敏捷的精神，力求每次產品迭代的項目不要全塞進一個版本，盡量把這波迭代需求拆成不同階段，這樣每兩三週就可以完成一個版本並上線，讓產品開發的時間調度有更多彈性。因此，一個產品迭代的專案可能會包含好幾個版本，而在完成一個專案後，PM 便會召集這個專案團隊一起來開一場 retro。
為什麼要開 retro？回顧的目的是什麼？
每次專案的人員組成可能不同，要面臨的核心任務也不同，有時是做新產品、有時是功能迭代，有時是後端程式碼要重構、有時是 UI redesign，既然每次都會出現不同的人與事，代表團隊也會遇到不同的問題和挑戰。
在平常的開發過程中，大家在乎的通常都是「如何在期限前解決問題」，碰到突發狀況時，很可能因為時間與人力限制，只能用最快、最省力的方式解決，也就是說，解決的通常是單點的問題；相較之下，回顧的目的是讓大家不要一味地趕專案死線，而是要從過程中學習、檢討，讓下一次的專案跑得順利，所以討論問題的角度可能可以提升到「線」或是「面」。
舉例來說，我在現職公司的第一個任務就是要做一個新產品，當時想把所有的票都集結起來，一來方便工程師在 KO 後估時、瀏覽對應的 UX 和 UI 畫面，二來也讓設計師清楚知道每一個任務的內容以及進度。然而，我在公司的文件管理系統和 JIRA 都沒有找到適合的文件模板，所以最後就自己做了一個清單（task list），如下圖：
後來在 retro 時，有工程師說，他覺得這個文件很清楚，能夠很快找到對應的設計稿；設計師也跟我說，他在出圖時能用這張表跟我對進度。兩邊都覺得這張表很方便，所以我們後來也把這張票當成其他專案的模板，並且也把這個模板分享給其他產品線的同事，讓他們參考使用。
誰應該要參與 retro？
一般來說，有參與該專案的 PM、FE、BE、QA、UI、UX 都應該要參加，但實際狀況依各組織需求而異。
以我公司為例，經過幾次經驗，負責 code review 的工程師都建議他們不用參加，因為他們主要是負責技術上的確認，對於專案的商業目標與做法不一定熟悉，而且也不會參與專案中間的討論，只會出現在專案 KO 與最後上線前的 code review 流程，所以即使參與 retro，他們也沒有太多建議能提出。
另外，主管與 devop 通常也不會參與這個會議，主管主要是在前期確認執行方向與目標無誤，對於實際做法與開發流程的細節不會干涉太多；devop 主要是在上線前協助各種部署，對於產品本身的熟悉度不高，以產品開發的過程來說，和其他組員的共事機會也不多，所以這兩種角色基本上也不會加入 retro。
retro 的進行方式與流程
上面講完了人（誰要參加）、事（為什麼要有 retro）、時（什麼時候開 retro），再來就逐一介紹一場 retro 會議會包含的環節。之前寫過一篇〈會議都是必要的嗎？如何建立良好的開會流程？〉，不過內容比較概略，只能當作基本款會議的參考指南。有鑒於 retro 的目的更明確，下面會一一介紹每個細節。
step 0：尋找主持人
每場會議都會有主持人，負責掌握流程、控時、開場與做結尾等，retro 當然也不例外。依照個人經驗，會擔任 retro 主持人的通常都是 scrum master，至於像我公司沒有用 scrum，所以多半是 PM 擔任 retro 主持人；但也會鼓勵其他組員多多參與，可以讓有需要的同事趁機練英文、訓練口條或者培養面對人群的勇氣（？），所以像我也有和自願擔任主持人的工程師一起主持過。
主持人大致上需要做的事情有：
● 確認會議需時：
會議時間長短因團隊人數而異，如果人比較少，可能 30 分鐘就可開完；但如果人較多，大家也都有意見想發表的話，也可能 1.5 小時才會開完。
● 準備 retro board：
下面會細講，但大致上 retro 包含 4 個環節（step 2-5），需要把對應的內容視覺化。像我公司是用 miro 來進行，讓大家一起在上面協作。不過工具百百種、模板也很多種，找到適合自己的就行，沒有絕對的對與錯。
● 控時：
為了控制會議時間與發言效率，retro 的每個環節都有固定的時長，主持人也要負責計時。
● 維持會議氣氛：
retro 有點像是「檢討會」，有時如果有些同事表達地比較直接，可能會給其他人一種「為什麼對我那麼兇＝＝」的感覺，所以主持人要確保會議可以在「認真但不劍拔弩張」、「有效率但每個人都能暢所欲言」、「讓彼此都有學習，但只對事不對人」的情況下進行。比如適時替發言者補充細節、作結，或者確認對方的語意，甚至在氣氛有點過度嚴肅時，出來緩解氣氛等，都是可以嘗試的方式。
● 確保理解一致：
我之前在台灣工作時，某間前公司有跑 scrum，所以我也參加過幾次 retro，當時畢竟產品線單純、合作的成員也都很固定，再加上工作語言是中文，所以比較沒有溝通理解上的問題。
但來到新加坡後，會議多半是用英文進行，且產品線複雜許多，每做一個新產品，合作的工程師陣容也都不太一樣，所以等於每次的 retro 都要適應不同人的表達方式與口音。
綜合以上原因，有時在 retro 會議裡，大家可能會聽不太懂某位同事的意思，或者也因為大家的母語並非英文，表達地不一定很順暢或到位，這時主持人就要幫忙補充、接話或協助歸納。（但有時連我自己都聽不太懂……那就只能請同事再說明一次了……）
step 1：定調會議風格 (set the tone)
經過上面的前置作業，終於來到 retro 會議了！在會議開始時，主持人會先講述一些 retro 的原則，以我公司為例，主持人會宣讀這些注意事項：
Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.
● Don’t make it personal, don’t take it personally.
● Listen with an open mind.
● Everyone’s experience is valid.
● Focus on improvement, rather than placing blame.
雖然看起來基本，不過畢竟 retro 不是一個會太頻繁召開的會議，像我任職一年以來，大概也只參與過 3 至 4 次 retro，所以為了怕大家忘記一些基本規則，宣讀這些原則還是有其必要。
step 2：安全檢查 (safety check)
再來會請大家投票，以表明自己對於該場會議的立場與願意分享的程度。以我公司為例，我們的選項有這些：
5: I’ll talk about anything
4: I’ll talk about almost anything, but one or two few things might be hard
3: I’ll talk about some things, but others will be hard to say
2: I’m not going to say much, I’ll let others bring up issues
1: I’ll smile, claim everything is great and agree with authority figures
0: I’m not comfortable talking / I don’t want to do this / I want to leave
這個投票是匿名的，我自己是習慣用 slido 讓大家投票，也有同事會用 zoom 的投票功能。投票目的主要是了解大家對這場會議有沒有「安全感」，基本上 1–5 分都還算是 ok，差別只是在於與會者有多少心得想分享；但如果出現了 0 分，代表成員可能心裡不太舒服、有某種排斥或恐懼感。
如果出現這個情況，下一步就是要讓大家投票「是否要繼續進行這場 retro」。
如果大家投票結果是繼續進行，仍得先討論一下為什麼會有 0 分的情況、怎樣可以舒緩大家的情緒、是否需要調整流程或內容等，以避免之後有類似情況，然後再依照上面的討論結果與解決方式，繼續進行 retro。
如果大家投票是不繼續進行，那也得進行相關討論，最後再進行一次投票，如果大家還是決定不進行會議，則會議中止；如果大家認為上面的討論可能有幫助，那會議就繼續進行。
step 3：what went well
再來就進入到集思廣益的時間了！為了讓會議有個充滿希望（？）的開始，通常會先請大家分享「這次會議中，做得不錯的地方有哪些」。
主持人宣布主題後，就可以開始計時，自己與成員們在協作工具上開始寫東西。時間一到，主持人需確認大家是否都寫完，可適時延長或提早結束該步驟。再來主持人就把成員寫的內容做個分類整理，比如跟設計有關的放一類、開發有關的放一起、專案管理放一類等，然後再請成員說明自己寫的內容。
step 4：what could be better
講完好的，再來就請成員們分享「有哪些可以做得更好」。
可以特別注意的是，我自己習慣會用「正面表述」，也就是會詢問大家「有哪些可以做得更好」，而不是「有哪些事情需要改進 / 改善」、「你認為哪些地方做得不夠好」。
雖然背後的意思是差不多的，前者意指「已經做得不錯，可以再更好」，後者則是「雖然做了一些，但仍有需改進處」，兩句話傳達的語氣仍有些不同。而且大家通常也是卯足勁在趕專案死線，這時大家需要的多半是打氣和希望，即使有做得不好，也應該是抱著一種「所以我們提出來可以改進的地方，這樣下次才會更好」的正面態度，而非互相指責或找戰犯。
另外可以注意的是，有些人會急著在這個環節就點出「問題」與「解法」，但其實這個階段只需要大家列出問題，具體的解決方式可以留待 step 5 一起處理。所以作為主持人，如果遇到這情形，也可以適時給一些提點，暗示同事「這個解法聽起來很棒，那我先放到 next step 區塊，等下可以一起討論」，不用現在馬上講完。
step 5：next step
完成 step 4，這時協作的區塊應該也寫了很多大家認為可以改進的事項，主持人照例要做個分類，並請寫的人詳述內容。
最後，可以看一下總共分出幾類，如果項目不多（比如 3 至 5 類），那可以直接開始請大家貢獻想法，寫出未來可以怎麼改善、避免此情況發生；如果分類多達 6 至10 種，礙於時間與資源有限，通常我會請大家再進行一個匿名投票，選出「你認為最需要被改善的 top 3」，然後再針對這 top 3 開始動腦。
除了最前面分享的清單模板例子，最近剛開完另一場 retro，遇到一個因而優化工作流程的例子：我們以往的 KO 只會過 UX，主要著重於這次要做的功能與邏輯，UI 細節就不會講到很細。但經過幾個專案後，前端工程師覺得 UI 時常有缺漏，不一定是 UI 設計師粗心漏掉，而是他並不知道前端工程師需要知道這些細節，所以就在 retro 時提出：是否能增加 UI KO 的環節？
也就是說，KO 主要是過 UX，但如果是 UI 比較複雜的地方，比如小螢幕的尺寸流變、極端狀況處理等，希望設計師們可以特別提出來介紹，而不是讓工程師自己去看 UI，這樣可能會造成誤解。
經過討論後，我們也覺得可以在 KO 時增加 UI demo 的環節，讓設計師和前端工程師有更多交流的機會，以降低後續的溝通成本。
從這些例子應該可以看出，如果用心地好好跑完一場 retro，便能更全面地重新檢視整個團隊的合作流程，甚至找出潛在的優化機會，讓未來的合作越來越順利！
結尾
盤點這次專案執行的做得好＆可進步處之後，step 3 得到的 “what went well” 可以記下來、繼續保持，至於對於 step 4 的 “what could be better” 以及 step 5 的 “next step”，則需要有對應的人做後續追蹤。
如果事項與技術有關，比如需要增補一些 API 文件、調整 deploy 流程等，那就看是找哪位工程師負責；如果是像前面說的，需要增加 UI demo 環節，或者是其他和設計有關的建議，那就應該由設計師負責。至於跟專案或產品管理相關的建議，比如希望時程不要壓太緊、需求要確認之後才 KO 等，這些就是 PM 要負責的。
上述這些結論可以在 retro 完成後，寫成一份會議紀錄，不管是分享在公司群組還是用文件留存都可以，目的就是要讓大家知道會議的結論與下一步，這樣之後也才知道怎麼跟進這些進度，讓這場 retro 不會淪於形式，而是真正能不斷地讓工作流程和團隊合作越來越順暢！
本站所有文章未經事先書面授權，請勿任意利用、引用、轉載。
