方法論的英文為Methodology，程式設計的方法論應該是指軟體開發的一整套方法、過程、規則、實踐、技術。不過我們一般提到的方法論都偏重於專案、過程和人員。《敏捷軟體開發》的作者Alistair Cockburn提出方法論具有以下要素：角色、個性、技能、團隊、技術、活動、過程、產品、里程碑、標準、質量、工具、團隊價值，它們的關係可以用一幅圖來表示：
 

對於方法和方法論的區別，我們要注意的是方法更多的是針對具體的事情的處理方式和步驟。而方法論探討的是一個團隊在處理一個較大的過程的時候，在面臨一種特定的場景時候應該採用的方法組合和協同。

方法論既可以是啟發和參與式的，又可以是標準化的。對於一個不斷成長的知識體系，方法論的一部分由啟發轉化為標準化，成為典型問題的標準解決方案。這類似於在我們的知識管理中，當我們的隱形的知識轉換為顯性的時候，就可以標準化到具體的過程中，方法論和過程是經驗的一種良好載體。

方法論的設計是和專案本身的特點密切相關的，這裡麵包括了人員，專案的規模，研發產品的特點和對質量的要求，研發團隊的工作模式等。方法論是一個全集，當面臨一個特定的專案的時候我們需要定義和專案特徵匹配的軟體開發生命週期模型和軟體過程。因此在這個過程中涉及到了需要考慮方法論的重量，大小，規模，精度，可見性，穩定性等一系列問題。

在方法論的設計過程中一定要考慮到人的變化，跨專案的變化，專案週期的變化和技術的變化對方法論的影響。在初次設計方法論的時候我們經常犯的錯誤就是所有專案都採用同樣大小的方法論，不考慮方法論的重量和靈活性，完全主觀按照自己的意願去設計，或者自己去採用沒有經過實踐的業績最佳實踐等。因此在這裡我們的重點是去分析和學習可用於設計和評價方法論的七條原則：

1.互動面對面的交流是費用最低，最高效和快速的資訊交換方式

在這裡要注意的是團隊隨著規模的擴大，溝通渠道呈現指數倍增加。因此規模擴大後要強調劃分開發小組，或者是通過提升個人技能避免不必要的規模擴大。交流的過程最好是結合白板的溝通，圖形往往更容易讓他人理解。交流的結果必須要有記錄，可以是錄影的方式或者是文件化。

2.方法論超重的後果是高昂的代價

對於方法論超重可以看做是對管理者虛榮心的一種滿足，或者是可以讓團隊讓外界看起來更美，或者體現了管理者對團隊和人員信任的下降，他們希望看到更多的中間輸出。一個專案的運作的重點不是滿足過程，而是要實現目標，沒有達到專案的目標在華麗的過程都沒有用。

團隊成員的重點需要時刻放在產品開發和對產品質量的關注上。方法論的重量要體現到對特定專案目標的貢獻度上面。方法論越重我們往往越難去解決複雜的問題，一個小團隊往往能夠用較輕的方法解決更大的問題。

3.更大的團隊需要一些更重一些的方法

對於一個4-6個人的小團隊，讓他們坐在有白板的辦公室裡面工作是可行的，這樣在他們進行創造和交流的協作遊戲時，交談中會產生資訊對流。但是隨著團隊大小的增加，溝通，協調，干擾，交疊和重複都是需要考慮的問題，我們必須要針對這些問題制定其它形式的協調和交流。

4.專案危險程度越高，對方法論的正規度要求也越高

對於太空梭等大型軟體系統的開發，我們必須有嚴格和高度正規的方法論定義。這種專案容不得一絲一毫的錯誤。而對於中小型資訊系統的開發，專案的目標不僅僅是質量，還有進度和成本，我們必須要在這些要素之間進行權衡。

因此如果我們簡單的照搬大型軟體工程的開發方法論到小規模敏捷團隊中，很顯然是得不償失的。我們有通過溝通協作等更輕量的方法來保證質量和避免犯錯誤。

5.增加反饋和交流，減少對中間工件的需求

最終產品的質量和使用者對產品的滿意度是衡量專案是否成功的一個關鍵要素，而中間的任何工件更多的是為了符合專案團隊內部管理和監督的需要。我們相互間越不信任，往往就越需要更多的中間輸出。

我們用中間工件的完成進度來衡量專案的進展是毫無意義的，因此在快速開發團隊中大型瀑布的開發模式必須用迭代增量的模式進行代替。 通過這種快速迭代的交付既可以降低風險，又可以使進度真正有意義。

6.紀律，技能和理解 VS 過程，形式和文件

首先過程不是紀律，過程只是讓人們遵守規範和指令，而紀律要求人們選擇一致的方法去工作。在這個過程中，紀律的效力更強。其次，不要混淆文件和理解，在軟體開發過程中仍然有很多隱性知識，文件只能表達這些知識的一小部分，更多的是需要通過溝通後的理解。最後，形式始終都是表面性的東西，制定了UML規範和學習了UML並不代表你能夠有足夠的技能進行面向物件的設計。

輕量級的方法論更加看重理解，紀律和技能，而不是文件，過程和形式。因此他們適用於探索性的情況。而重量級的方法論看重的是文件，過程和形式，它們設計的目的是讓人們在不需要適應變化的環境下工作，只需要成本最優化。

7.從非瓶頸活動中需要效率

約束理論常用於關鍵鏈專案管理中，而關鍵鏈專案管理的重點就是說明了專案的進度是取決於專案中核心和瓶頸資源的約束的。為了讓專案進度有保證，我們需要考慮的就是讓瓶頸資源更加高效率的運作，而要做到這一點就是讓非瓶頸資源儘可能提前的做好各種工作，以保證輸入到瓶頸資源的工件有更高的質量，減少瓶頸資源的返工。

從非瓶頸活動中需要效率需要我們考慮，當專案進展受到瓶頸資源約束的時候，我們閒置的非瓶頸資源應該如何利用。一個專案進展我們最怕的就是由於瓶頸的約束讓團隊中更多的人顯得無所事事。