Retrospective Meeting = 許願池

11/25 22:24~23:55

許願池，常見於各大廟宇以及名勝古蹟之中。不管願望能否實現，丟個銅板，就可以擁有「有夢最美，希望相隨」的片刻。對於出門在外手頭不方便的鄉民而言，順手撈幾個銅板就可以換一個國民便當或是買一張回家的車票，省去攔路要錢的尷尬。Producers 和 Consumers 各取所需，王不見王。從軟體架構的角度來看，此種 decoupling 的特色，相當具有擴充性。

許願池的種種優點，做軟體的朋友們當然也發現了。別說 Teddy 騙廣大的鄉民們，就在 Scrum 中，每個 sprint (iteration，一個固定長度的開發週期，通常介於 2 - 4 週之間) 結束時都要進行的活動 -- retrospective meeting -- 就是開發團隊的許願池啦。

Retrospective meeting 照字面解釋，就是「回顧會議」，這是 Scrum 設計用來改善開發流程的一道關卡，每一個 sprint 結束之前都要過這一關。在這個會議當中，開發團隊討論在這個 sprint 當中，哪些事情作的很好，要繼續維持。哪些作的不好，應該改善，並挑出幾個比較重要的改善項目列出改善的行動方針。以下是幾個例子：

好的部分：

• 導入 Scrum
• 有一個公開的 product backlog
• 有訂定產品的 release plan
• 有持續整合的環境
• 有自動化功能測試案例與測試環境

有待改善： 

• 電腦效能不佳 (都是 Vista 的陰謀啦)
  
• 沒有寫 unit test
• 沒有 pair programming
• Tasks 完成條件定義不清
  
• ezScrum 太慢 (這是真的有人提出... 嗚嗚...)
  

改善行動方針：

• 長期目標：增進工作環境效率
• Action Plan: 增加記憶體到 4G
• Action Plan: 安裝 Vista SP2 (或是 窮得只能超頻?)
• 長期目標: 所有 methods 至少都有三個對應的 unit tests
• Action Plan: 安排1個小時的 workshop 教導 JUnit 使用方法
• Action Plan: 下個 sprint 每個人至少寫 3 個 test cases
• 長期目標：50% 的開發工作都以 pair programming 方式進行
  
•  Action Plan: 因為目前工作環境並不適合 pair programming，因此先改善工作環境。首先向公司申請 22" 螢幕、無線鍵盤、滑鼠。
  

由於開發流程改善是一條很漫長的路，有多長，這 麼 長... 長到你看不到底。所以，很多改善項目需要長時間的關注。例如，光是做測試這件事，就足夠玩個一年半載以上，才能小有成果。所以，為每一個改善項目訂定長期摽，然後列出本次的 action plan (行動計畫，就是下個 sprint 準備採取的改善措施)。這樣，週而復始，無限迴圈卯起來改善流程，便可達到：「人人有事做，月月有錢領」的最高境界 (一直到 stack overflow 為止)。

*****************************************************************************************

眼尖的鄉民看到這裡應該會問：這和許願池有什麼關係。是滴，以往沒有 retrospective meeting，開發團隊可能老早就發現很多問題，但是苦無 call in 管道可以暢所欲言，以至於長期悶在心中，很容易得內傷，影響工作效率。久而久之甚至導致團隊成員移民到其他公司。有了 retrospective meeting 之後，給了各位頭家一個「嗆聲」的機會和管道。就像許願池一樣，錢丟下去，願望會不會實現是另一回事，至少聽到噗通一聲當場爽一下也好，可以減少得內傷的機率。

Teddy 在 retrospective meeting 中看過一些比較有趣的願望包含：

• 冷氣太冷，快得 H1N1 感冒，影響工作效率。
• 要去參觀資訊展，看 show girls 了解一下競爭對手的產品。
• 政躬康泰 ，皇上吉祥
  
• 股市上萬點
  
• 長命百歲
  
• 世界和平
• !#%!@#~
  

總之，每個 sprint 花一、兩個小時來了解民間疾苦、收攏人心、開開競選芭樂票、罵罵老佛爺，比起傳統無聊到爆、火氣很大、忙著找代罪羔羊的大鍋炒會議，這種 C/P 值超高的活動，還不趕快去弄一個來玩。