喝看看就知道

看過維大露P的廣告嗎? 一位外國朋友問蔡振南： "這飲料好喝嗎?" 蔡振南回答："你自己喝看看就知道"。的確，飲料好不好，喝了就知道，再多的言語也無法取代親自嘗試。很多軟體開發的作法 (practices) 也是如此，好不好，動手試了就知道。

這幾個月在幫忙某個軟體開發團隊導入Scrum，經過了好幾個 sprints 之後，我嘗試導入 pair programming (自找麻煩，我知道...)。在苦口婆心說明了 pair programming 的好處之後，原本希望 programmers 可以被我的三寸不爛之舌給說動，可惜用講的效果不彰，沒有人主動採用。後來，我親自下海 (我承認是我偷懶，一開始就應該自己帶頭做)，"趴"在幾個 programmers 身邊一起 pair。這樣試了兩個 sprints，到了第三個 sprint 之後，所有的 programmers 都已經接受了 pair programming。現在幾乎大部分的工作都採用這種方式進行。Pair programming 帶來的效益實在太多，例如：增進學習機會、藉由合作來改善軟體設計、減少加班 (因為太累了，沒體力加班)、趕走瞌睡蟲等等。

同樣的效果也出現在"寫測試"這件事情上面。實施 pair programming 之前，programmers 也被要求 (嚴格講起來是"被期待") 要用 JUnit 寫測試。的確有些人也作的不錯，但是這些由個別 programmer 所寫的測試效果如何，並沒有其他人再加以驗證。實施 pair programming 之後，對於撰寫測試的討論與花在撰寫測試的時間越來越多。此外，由於配對的關係，對於程式碼品質與設計的討論也增多，自然而然地，programmers 也經常利用 refactoring 來改善設計。由於 refactoring 之後需要執行測試案例來確保沒有把原本可以動的軟體弄壞，因此測試的重要性與效益變的越來越高， programmers 也變的越來越喜歡寫測試 (也許還沒到喜歡的地步，但至少意願與動機提高很多)。

我越來越相信，改善軟體開發，幫團隊成員洗腦固然重要，但一定要動手去做。如果要等所有人都認同再動手，有可能永遠都等不到這一天。

在你決定嘗試這些 practices 之前，最好能找到ㄧ個好的 Scrum Master，確保你所嘗試的方向與作法是正確的。我曾經聽說，有團隊宣稱採用 XP 開發一個軟體專案，在過程中曾經花了幾個月的時間在做 refactoring，最後專案以失敗收場。他們得到的結論是，agile methods 不可行。我真的很想問他們："你們確定這是 XP，還是戴著 XP 帽子，但實質上是不知道什麼亂七八糟方法的軟體開發?"

PS: 最近因為三聚氰胺的新聞，赫然發現，飲料還是不能亂喝。