相信大家一定都經歷過團隊開發的鬼故事——每個人都有在做事，但同樣的問題卻也重複在發生，就像是整個團隊在跑倉鼠滾輪。每個人都拼了命地在開發，但最後，大家卻都只是精疲力竭，而一個產品又被搞砸了。
有些頭腦清醒的人可能有辦法看到「問題根源」，比如說缺少了一個設計師、或者目前總是使用舊方法在解決問題、又或著是因為PM管理方式有問題。意思是說，應該有更好的方法可以解決問題！但夢想豐滿現實骨感，到最後卻因為沒人開口、或開口了沒人執行，導致惡性循環一再重演。
有什麼方法可以脫離這個惡性循環呢？答案是：回顧會議 (Retrospective Meeting) ，在大家有共識的情況下，定期評估開發過程，得以讓團隊跳出惡性循環的牢籠，找到解決方案。以下就讓我們聊聊什麼是「回顧會議 (Retrospective Meeting)」，以及它是怎麼協助團隊節省大量時間與成本，並成功完成目標的吧！
回顧會議：成員共同研究階段時間內團隊的合作情況，以及找出未來的改善方法及目標。
你可能還曾經聽過 Scrum Retrospective、Sprint Retrospective，或者是Post-mortems ( 事後回顧 )。通常越久開一次回顧會議，會議時間也會變得更長 ( 例如 3個小時 )，但如果是短時間內就有一次回顧會議，例如敏捷開發團隊在每個 Sprint ( 衝刺 ) 結尾都會發起回顧會議，通常這個回顧會議也會在很短的時間內結束。
回顧會議通常能讓團隊了解這段時間內哪些事情進展順利，而哪些則進展不順利，這些資訊可以讓他們在下一個Sprint做得更好更有效率。
為什麼團隊會需要回顧會議Retrospectives？
1. 有個安心的場合讓大家暢所欲言
我記得以前在高中和大學的時候，學校活動或社團在結束後都會開「檢討會」，美其名是一個找到問題與解決方法的會議，但很常最後卻變成批鬥大會。由於回顧會議同時點出做的好與待改進的地方，也以找到方法最為目標，這讓大家更能夠放寬心說出以及接受回饋。
另外，在團隊中總有人能夠自在地說出自己的想法，但也有很多人是埋頭苦幹的類型，不太願意發表想法 ( 在台灣的大環境下，我認為多數人不擅長表達 )。Retrospectives能夠幫助大家說出自己真實的想法和見解，包含哪些事做得很好？哪些可以改善？可以怎麼改善？一個Retrospective會議能讓每個人都有機會為自己的想法發聲，而不是只是平常比較外向或比較會表達的那些成員。
2. 問題能夠被解決
我們是否都曾有類似的情緒「一次一次做著相同的事情，卻得到與期待不同的結果」，就像是青春期少女總是愛上會說甜言蜜語的渣男，卻一次次以被劈腿收場 ( 怎麼聽起來那麼難過 )。
許多人會專注在完成工作，但忘了退一步審視自己是如何完成的，過程是否有一直重複產生的問題。這些問題都能夠在Retrospective後浮出水面，並在後續被團隊中的所有人重視，並且有效率且有效果的解決。
3. 增進團隊合作
我記得在帶領完某個新創團隊第一次的 Retrospective後，團隊成員分別在私下跟我說「我感覺我們團隊變得更緊密了」，這讓我感受到開回顧會議真的不是在浪費時間，而是有真真實實的效用。
回顧會議讓大家講出做的好的地方，這能讓許多成員感受到被鼓勵以及被看見；在提出可以改進的地方時，也會感受到團隊在共同為彼此著想和前進，不會覺得被責備；同時，團隊也能透過回顧會議感受到彼此在同一艘船上，要持續合作才能讓團隊持續進步。
4 個步驟完成 Retrospective
1. 規劃Retrospectives的時間
通常在計畫好 Sprint 的週期後，就可以開始規劃 Retrospective的時間了，他通常會在每個 Sprint 的最後；如果你不知道怎麼開始的話，大該兩週一次會是滿中庸的週期，畢竟通常 Sprints 不會超過一個月那麼長。
2. 邀請團隊加入
你可能會思考哪些人需要加入 ( 我知道有些團隊會排除相關的業務或設計師 ) ，但如果可能的話，請加入團隊中的「所有人」，畢竟每個角色看事情的角度會大大的不同。
3. 問出好的問題
將參與者引導到同一個答案對團隊是沒有幫助的，因此會議主持人在剛開始最好先不要帶任何偏見 ，問出開放式的問題才能有多個有效的答案得以去選擇，避免那種可以只用「是和不是」回答的問題。
偏見問題如：「你是否覺得在這個sprint中 task 太多？」
試著把問題改成：「你對於這次sprint中的工作範圍有什麼看法? 」
我知道團隊可能遇到了困境，每個人腦中可能只想得到困難，而想不到目前有哪些地方做得好，但建議主持人仍然先從 What was good 開始討論起，讓每個人能更放鬆的表達自己內心的想法。
4. 改善流程
在下個Sprint中，每個人都要將Sprint中討論的方法實際用在工作流程中，這不只是要讓工作完成而已，更是一個共同進步的機會。並且這些改善將在下一次的Sprint中被討論到，因此每個人的努力都會是能被看到的。
Retrospective 中可以問哪些問題？
以下列出許多問題供大家參考，大家可以依照時間與狀況問出不同的問題。
Warm up 暖身
你認為這個sprint中誰幫助你最多？
你最欣賞同事做的哪件事？
1-10分你給這個sprint幾分，為什麼？
一個字形容這個sprint。
What went well 哪些事進展得不錯
有哪件事比你預期的還要好？
有任何部分比上一個sprint好嗎？
哪個工具和資源在sprint中幫助你？
上一次回顧的哪個結論幫助你改善工作流程？
如果我們團隊是一個超級英雄，你認為是哪個超級英雄？
你在這個sprint中最為什麼感到驕傲？
你在這個sprint中學到了什麼？
What didn’t go well 哪些事進展得不好
有任何一刻你感覺到事情沒有往對的方向進展嗎？
對你個人來說最大的壓力是什麼？
有發生什麼讓你措手不及的事情？
你怎麼處理出問題的步驟？
你認為是什麼導致這個問題的發生？
這個問題對你產生了什麼影響？
你在問題發生時期待有什麼資源可以協助？
我們團隊最薄弱的環節是什麼？
事後你會怎麼處理這個問題？
Future-oriented 未來導向
如果可以回到當時你會有什麼不同的做法？
如果回到過去有哪些步驟你會不想改變？
哪些事運作得非常好可以被保留？
哪些事讓你感到驚訝？
你在過程中學到什麼，讓你在下個sprint變得更好？
我們要怎麼複製這次的成功經驗？
你可以怎麼協助身邊的夥伴讓下一次變得更好？
你認為下個sprint如果成功了會是什麼樣子？
哪些狀況你下個sprint絕對不想看到？
哪些改變可以讓我們更容易達到下個目標？
這個改變可能導致哪些額外的反應或副作用？
哪些問題仍然是在待解決的階段？
Action 行動與改變
哪個微小的改變可以產生進步？
這個問題的代價是什麼？
如果你要對這個問題負全責你會怎麼做？
在所有我們找出的解決方案中，哪個會有最大的影響力？
如果我們要對這個問題進行研究會是什麼樣子？
你期待在改變後看到什麼結果？
如果得到這個結果你會有什麼感受？
你如果要讓他成功會需要哪些幫助？
為什麼 ( 所有問題都可以再接著問為什麼 )
Team Wellbeing 團隊福祉
如果有的話，什麼團隊的事情讓你難以入睡？
如果你不用做某件事情讓你更輕鬆，那件事是什麼？
你對於這週 Work-life balance有什麼感受？
哪些團隊文化是你喜歡或希望改進的嗎？
你認為自己目前的動力是什麼？
Retrospective 技巧與注意事項
- 每次Retrospective的開場白都很重要！儘管每次都可能需要重複一樣的內容，但還是建議大家在開場時明確的表達回顧會議的目的，並在開場時創造出正向而且安全的氛圍，讓大家能夠自在的表達。
- 每次都依照不同的狀況問問題，避免團隊一直重複回答相同的問題很無聊，也會感覺事情沒有進展。
- 可以使用像是白板或便利貼等工具，有些成員會需要一些反應時間，這時讓他們先寫在便利貼上會是一個好的方法。
- 準備足夠的時間進行回顧會議，跟其他會議比起來，Retrospective可能會需要比較長的時間讓氣氛變得合適，因此準備長一點，後面不會被打斷的時間是必要的。
- 如果想要進行得比較有效率，可以考慮事先搜集大家的答案。
嗨！我們是客家工程師 
，由一位軟體程式工程師與 UIUX 設計師組成。身為 ENFJ (導師型) 與ENFP (競選者) 的我們都很喜歡分享知識與經驗。未來將會持續分享我們在生活、旅行、求學與軟體工作的點點滴滴。