如何做好ScrumMaster（1）？

May 17 23:03~May 18 00:13

 

如何做好ScrumMaster？這個問題太大了，不容易回答。一個最簡單卻也可能是最好的方法就是：「多看書，多參考別人的經驗」。幾天前Teddy在「沒有文件」這一篇裡面提到一個案例，鄉民甲發現要使用某個前人所開發的元件但是沒有文件可以參考，於是在retrospective meeting中提出這個議題。最後團隊得到一個很傳統看起來也很正確的結論：「下個sprint排點時間來為這個元件補寫文件」。此時Teddy的腦袋想的卻是另一件事情：「用自動化測試案例來當作文件也是不錯的選擇」。為什麼Teddy會有這樣的直覺反應？不是Teddy天資聰穎，只不過是之前曾經從一些書上看到敏捷方法鼓勵用自動化測試來當作一種形式的軟體說明文件，以及之前的實際採行過這種做法的經驗告訴Teddy這是行得通的方法。

有沒有其他例子？有滴。有一次某個團隊遇到一個問題，這個團隊必須將他們所開發的軟體交付給兩個不同的客戶使用（稱之為客戶A與客戶B）。雖然提供給這兩個客戶的功能基本上是一樣的，但是其中某一個特殊的功能暫時並沒有開放給客戶B使用。現在問題來了，要怎麼做才能讓客戶B無法使用到這個特殊功能？以下為兩個可能的方案：

• 從建構系統上做手腳：讓建構系統可以從單一個code base中分別產生給客戶A與客戶B使用的安裝程式。
• 從程式中做手腳：當程式發現目前的使用者是客戶B的時候，就把那個不開放給客戶B使用的特殊功能給隱藏起來。

如果是鄉民們要做決定，你會選擇哪一個方法？

經過一番討論之後，團隊建議採用第二個方案--「從程式中做手腳」，原因如下：

• 每次只要產生一份安裝程式就好，所以日後送給品管部門測試的時候，就只要送一份。如果採用第一個方案，產生兩份不同的安裝程式，那麼測試的工作就會增加一倍。
• 在建構系統中要設定從單一code base產不同的安裝程式好像很麻煩。
• 從程式中做手腳最快也最簡單，技術風險很低。

上述理由還滿充分的，依照慣例，Teddy又是那個唱反調的人。此時Teddy的腦袋突然冒出Kent Beck在Extreme Programming, 2nd裡面所提到一個觀念，在這本書的第67-68頁，Kent Beck建議開發人員要使用「Single Code Base」（請參考Teddy之前寫的這篇「Single Code Base」）。最後Kent Beck說：

如果你有一些合理的理由讓你必須使用multiple code base，請把這些理由當成是你要挑戰的目標而非看成絕對要遵守的準則。也許團隊可能要花費一番功夫與時間才有可能克服這些原本認為很合理的理由，但是這樣的過程卻可以為另一階段的改善開啟一扇門。

持續改善是一件很困難的工作，而ScrumMaster的一項重大責任就是要協助團隊持續改善。Teddy的經驗告訴自己，該團隊所遇到的問題似乎是一個「建構管理」的問題。也許團隊因為目前對於建構管理的技術能力比較不熟，因此很自然地就會想要避免去碰觸建構管理，而改用自己熟悉的「程式技巧」來解決。廣義的來說，Teddy認為這沒有什麼對錯可言，因為如果在可預見的將來這個產品就只會有客戶A與客戶B這兩種類型的客戶，而且專案的時程又很趕，那麼暫時採用方案二也並無不妥。

但是（通常看到「但是」才是重點所在…XD），身為ScrumMaster，應該要有足夠靈敏的「嗅覺」（還記得嗎，ScrumMaster是一條牧羊犬啊），查覺到團隊「建構管理」力能有待加強這個事實。如果這個事實會持續阻礙團隊所開發軟體的品質與進度，那麼這就是一個值得投資時間加以改善之處。

***

很多人看到Scrum之後的第一個反應都是：「怎麼這麼簡單啊，我也來 隨便 試一下」。這一試之下才發現，Scrum也沒幫我解決什麼問題啊，原本團隊與專案該出現的問題，怎麼導入Scrum之後還都存在，甚至還冒出新的問題出來。

Scrum框架本身很簡單是沒錯，但是軟體團隊要帶的好，專案開發要順利，不是光光知道Scrum框架就搞定了。就像Teddy之前說過的「Scrum 不會幫你解決問題」與「Scrum 不會幫你解決問題（2）」，了解Scrum框架之外，敏捷精神、敏捷實務做法、還有深厚的設計能力才是軟體是否能順利開發的根本啊。

***

扯了這麼多，Teddy今天真正重點只有一個：

要做好ScrumMaster的第一步就是，趕快來報名Teddy負責教課的「Scrum軟體開發流程實作班」吧。

***

友藏內心獨白：在軟體開發中，能夠用錢解決的方法，就是最好的方法。