l

2008年9月12日 星期五

喝看看就知道

看過維大露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: 最近因為三聚氰胺的新聞,赫然發現,飲料還是不能亂喝。

沒有留言:

張貼留言