在現實中，我們其實不斷的在接觸方法論。比如說，為了控制項目的進度，項目經理要求所有的開發人員每周遞交一份詳細的進度報告，這就是一種方法、一種技巧。如果把開發過程中的這些技巧系統的組織起來，就能夠成為一種方法論。你可能會說，那一種方法論的產生也太容易了吧。不，這樣產生的方法論并沒有太大的實用價值，沒有實用價值的方法論根本就沒有存在的必要。因此，一個成功的方法論是要能夠為多個的項目所接受，并且能夠成功實現軟件的交付的方法論。
我和我的同事在實踐中做了一些試驗，希望能夠把一些好的方法論應用于開發團隊。試驗的結果很無奈，方法論實施的效果并不理想，一開始我們認為是方法本身的原因，到后來，我們發現事情并不是這么簡單。在試驗的過程中，開發人員一致認同方法論的優勢所在，但是在實施過程中，鮮有堅持的下來的。在Agile Software Development中，我發現作者遇到了和我們一樣的問題。
Alistair Cockburn在和大量的項目團隊的訪談之后，寫成了Agile Software Development一書。在訪談之前，他篤定自己將會發現高度精確的過程控制是成功的關鍵所在，結果他發現事實并非如此，他把他的發現歸結為7條定律。而我在實際中的發現也包含在這七條定律中，總結起來就只有兩點：溝通和反饋。
只要能夠保證良好的溝通和即時的反饋，那么開發團隊即使并沒有采用先進的方法論，一樣可以成功。相反，那些"高質量"的團隊卻往往由于缺乏這兩個因素而導致失�。ㄎ覀冞@里指的失敗是用戶拒絕使用最終的軟件）。最有效，而成本也最低的溝通方法就是面對面（face to face）的溝通，而隨著項目團隊的變大，或是另外一些影響因素的加入（比如地理位置的隔絕），面對面的溝通越來越難實現，這導致溝通的的成本逐漸加大，質量也慢慢下降。但這并不是說非面對面的溝通不可，重要的是我們需要知道不同的溝通方式的成本和質量并不相同。XP方法尤為強調面對面的溝通，通過現場客戶、站立會議、結對編程等方式來保證溝通的有效。在我的經驗中，一個開發團隊其實是需要多種溝通方式的結合的。完全的面對面的溝通對某些團隊來說是很難實現的，那么問題的關鍵就在于你如何應用溝通的方式來達到你希望的效果。在前不久結束的歐萊雅創業計劃大賽上，有一支團隊特別引人注目，他們彼此間素未謀面，僅僅憑借Inte.net和電話完成了高效的合作。他們雖然沒有使用面對面的溝通方式，但是仍然達成了既定的目標。軟件開發也是一樣的，面對面的溝通是非常有必要的，但其它的溝通方式也是需要的。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
