方法論對軟件開發而言意味著什么？我們如何看待軟件開發中的方法論？方法論能夠成為軟件開發的救命稻草嗎？在讀過此文后，這些疑惑就會得到解答。
在第一篇文章中，我們來了解標題中的一些詞的含義。
方法學是什么？
敏捷是什么？
為什么討論架構？
方法論
方法論的英文為Methodology，詞典中的解釋為"A series of related methods or techniques"我們可以把它定義為軟件開發（針對軟件開發）的一整套方法、過程、規則、實踐、技術。關于方法論的出現的問題，我很贊同Alistair Cockburn的一句話，"方法論源于恐懼。"出于對項目的超期、成本失控等等因素的恐懼，項目經理們從以前的經驗出發，制定出了一些控制、監測項目的方法、技巧。這就是方法論產生的原因。
在Agile Software Development一書中，作者提到了方法論的十三個要素，基本能夠函蓋方法論的各個方面：
角色（Roles）
個性（Personality）
技能（Skills）
團隊（Teams）
技術（Techniques）
活動（Activities）
過程（Process）
工件（Work products）
里程碑（Milestones）
標準（Standards）
質量（Quality）
工具（Tools）
團隊價值（Team Values）
它們之間的關系可以用一幅圖來表示：
圖 1. 方法論的十三個要素
很多的方法論，都涉及了上面列舉的十三要素中的部分要素，因此，我們可以把方法論看作是一個抽象的、無窮的超集，而現實中的方法論都是指超集的一個有限的子集而已。它們之間的關系就好像有理數和1到100之間的整數的關系一樣。不論是XP，還是UI設計經驗之類，都屬于方法論的一個子集，只是這兩個子集之間有大小的差別而已。我們還應該看到，討論一個完備的方法論是沒有意義的，因此這種方法論鐵定不存在，就好像你視圖窮舉出所有的有理數一樣荒唐。因此，我們關于一個通用的方法論的說法也是無意義的。好的方法論，比如說XP、水晶系列，它們都有一個適合的范圍，因為它們了解一點，自己并不是一個無所不能的方法論。
在現實中，我們其實不斷的在接觸方法論。比如說，為了控制項目的進度，項目經理要求所有的開發人員每周遞交一份詳細的進度報告，這就是一種方法、一種技巧。如果把開發過程中的這些技巧系統的組織起來，就能夠成為一種方法論。你可能會說，那一種方法論的產生也太容易了吧。不，這樣產生的方法論并沒有太大的實用價值，沒有實用價值的方法論根本就沒有存在的必要。因此，一個成功的方法論是要能夠為多個的項目所接受，并且能夠成功實現軟件的交付的方法論。
我和我的同事在實踐中做了一些試驗，希望能夠把一些好的方法論應用于開發團隊。試驗的結果很無奈，方法論實施的效果并不理想，一開始我們認為是方法本身的原因，到后來，我們發現事情并不是這么簡單。在試驗的過程中，開發人員一致認同方法論的優勢所在，但是在實施過程中，鮮有堅持的下來的。在Agile Software Development中，我發現作者遇到了和我們一樣的問題。
Alistair Cockburn在和大量的項目團隊的訪談之后，寫成了Agile Software Development一書。在訪談之前，他篤定自己將會發現高度精確的過程控制是成功的關鍵所在，結果他發現事實并非如此，他把他的發現歸結為7條定律。而我在實際中的發現也包含在這七條定律中，總結起來就只有兩點：溝通和反饋。
只要能夠保證良好的溝通和即時的反饋，那么開發團隊即使并沒有采用先進的方法論，一樣可以成功。相反，那些"高質量"的團隊卻往往由于缺乏這兩個因素而導致失�。ㄎ覀冞@里指的失敗是用戶拒絕使用最終的軟件）。最有效，而成本也最低的溝通方法就是面對面（face to face）的溝通，而隨著項目團隊的變大，或是另外一些影響因素的加入（比如地理位置的隔絕），面對面的溝通越來越難實現，這導致溝通的的成本逐漸加大，質量也慢慢下降。但這并不是說非面對面的溝通不可，重要的是我們需要知道不同的溝通方式的成本和質量并不相同。XP方法尤為強調面對面的溝通，通過現場客戶、站立會議、結對編程等方式來保證溝通的有效。在我的經驗中，一個開發團隊其實是需要多種溝通方式的結合的。完全的面對面的溝通對某些團隊來說是很難實現的，那么問題的關鍵就在于你如何應用溝通的方式來達到你希望的效果。在前不久結束的歐萊雅創業計劃大賽上，有一支團隊特別引人注目，他們彼此間素未謀面，僅僅憑借Inte.net和電話完成了高效的合作。他們雖然沒有使用面對面的溝通方式，但是仍然達成了既定的目標。軟件開發也是一樣的，面對面的溝通是非常有必要的，但其它的溝通方式也是需要的。
再看反饋，不論是控制進度，還是保證客戶的滿意度，這些活動都需要管理成本。軟件開發中的管理成本的一個通性就是伴隨有中間產出物（intermediate delivery）。比如說我們的需求規約、分析文檔、設計文檔、測試計劃，這些都屬于中間產出物。中間產出物的增加將會帶來效率下降的問題，因為開發人員的時間都花在了完成中間產出物的工作上，花在給軟件新功能上的時間就減少了。而中間產出物的主要目的是兩個，一個是為了保證軟件如客戶所愿，例如需求規約；另一個是為了作為團隊中的其他成員工作的輸入，例如開發計劃、測試計劃等。因此，我們也可以針對這兩點來商討對策，一種是采用迭代的思想，提高軟件發布的頻率，以保證客戶的需求被確實的滿足，另一種就是縮小團隊的溝通范圍，保證成員能夠從其他人那里得到新的思路，而不是撰寫規范的內部文檔（內部文檔指那些僅為內部開發人員之間的溝通所需要的文檔）。
因此，一個軟件項目的成功和你采用的開發方法論并沒有直接的關系。
重量
我們根據把擁有大量artifact（RUP官方翻譯為工件，意思是軟件開發過程中的中間產物，如需求規約、設計模型等）和復雜控制的軟件開發方法稱為重型（Heavy Weight）方法，相對的，我們稱artifact較少的方法為輕型（Light Weight）方法。在傳統的觀念中，我們認為重型方法要比輕型安全許多。因為我們之所以想出重型方法，就是由于在中大型的項目中，項目經理往往遠離代碼，他無法有效的了解目前的工程的進度、質量、成本等因素。為了克服未知的恐懼感，項目經理制定了大量的中間管理方法，希望能夠控制整個項目，最典型的莫過于要求開發人員頻繁的遞交各種表示項目目前狀態的報告。
在Planning XP一書中有一段討論輕重型方法論的精辟論述，它把重型方法論歸結為一種防御性的姿態（defensive posture），而把輕型方法論歸結為一種渴望成功（Plan to win）的心態。如果你是采用了防御性姿態，那么你的工作就集中在防止和跟蹤錯誤上，大量的工作流程的制定，是為了保證項目不犯錯誤，而不是項目成功。而這種方法也不可謂不好，但前提是如果整個團隊能夠滿足前面所提到的兩個條件的話，項目也肯定會成功，但是重型方法論的一個弊端就在于，大家都在防止錯誤，都在懼怕錯誤，因此人和人之間的關系是很微妙的，要達到充分的溝通也是很難的。最終，連對人的評價也變成是以避免錯誤的多寡作為考評的依據，而不是成就。我們在做試驗的時候，一位項目經理開玩笑說，"方法論源自項目經理的恐懼，這沒錯。但最糟糕的是整個團隊只有項目經理一個人恐懼，如果能夠做到人人的恐懼，那大家也就沒有什么好恐懼的了。"這句話提醒了我們，如果一個團隊的精神就是力求成功，那么這支團隊的心態就和其它的團隊不同了，尤其是對待錯誤的心態上。根本就沒有必要花費大量的精力來預防錯誤，錯誤犯了就犯了，即時改正就可以了。這其實就是渴望成功的心態。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
