2010年11月29日
10:07
一個人寫軟件可以僅僅面對屏幕，奮力敲入代碼就好。而團隊開發模式下需要方法論指導大家的協作，以便達到共同的產品目標。方法論是必要的。
一個項目經理在推進團隊“更快的解決Bug”過程中有些經驗。他說：“我們在採用一種叫做‘青蛙王子’的方法來推動大家積極的解決Bug。方法是把一段時間捉蟲最多最好的程序員叫做青蛙王子，並且給予獎勵”。
在談及“青蛙王子”的時候，這位項目經理一直在強調“特定時期，特定目標”。就是說，它能夠解決問題，但是針對性很強。推動“青蛙王子”之前，組員覺得Bug是改不完，也不願意改。通過這樣的方法，讓大家改變心態，積極修改Bug，並且通過定期的公佈總Bug數量，剩餘Bug數量、項目經理的評價的方式，讓每一個在這段時間內集中精力做好一件事。現在的Bug少了，這個方法也就很久沒有用過了。
在差不多同一時期，我們也出現了很多這樣的小型方法，專注於解決特定時期的問題，它們都有一定的成效，但是缺點也比較明顯——只能解決特定問題。和這些我們自己的方法論相比，Scrum可以在任何一個項目的完整週期中使用，並提供比較全面的過程指導。
Scrum可以促進大家的溝通，讓開發更有樂趣。我們的一個老闆曾經說，程序員都是些沒有多少感覺的傢伙。他爲此舉例，“本來大家都是面對面的，一句話就可以把問題講清楚了，但是很多人會通過即時通訊工具發消息，而不是直接溝通”。程序員的工作一天到晚的對着電腦，編寫沒有人看得懂的代碼，也顯得毫無樂趣可言。而Scrum過程要求大家做更多例行的溝通，包括每日演示、設計討論、提出問題和找到幫助者、定期總結，從而促進大家的溝通、快速的解決問題。
Scrum可以幫助每個成員把握項目的進度。以前分配了任務，程序員就分頭做自己的工作，可能兩週甚至一月才集成一次，而當真正集成的時候必然產生一堆問題，比如重複編碼，做了不該做的。這樣的進度管理是比較粗放的。而關於Scrum的做法則是每天集成，不管什麼問題，都會很快的表現出來，而不會等到做了一堆無用功後在去返工。Scrum的每日集成，讓問題更加容易被發現，把風險分擔到每天內，而不是等到問題積累到很嚴重後再去解決。
和重型的軟件方法論相比，Scrum可以是拿來就用的。它對工具要求都是很基礎的，不外乎是白板、即時貼（我們另外一個項目用了牆上卡片）、簡單的Scrum工具（比如 ScrumWorks）。不需要看很多書、不需要太多的實施指導、也不需要諮詢公司的支持。