1、敏捷思維－敏捷思維－架構設計中的方法學架構設計中的方法學(1)從方法論看架構設計從方法論看架構設計林星(iamlinx@)2002年3月方法論對軟件開發(fā)而言意味著什么？我們如何看待軟件開發(fā)中的方法論？方法論能夠成為軟件開發(fā)的救命稻草嗎？在讀過此文后，這些疑惑就會得到解答。在第一篇文章中，我們來了解標題中的一些詞的含義。?方法學是什么？?敏捷是什么？?為什么討論架構？方法論方法論方法論的英文為Methodology，詞典中的解釋為“Ase

2、riesofrelatedmethodstechniques“我們可以把它定義為軟件開發(fā)（針對軟件開發(fā)）的一整套方法、過程、規(guī)則、實踐、技術。關于方法論的出現(xiàn)的問題，我很贊同AlistairCockburn的一句話，“方法論源于恐懼?！俺鲇趯椖康某凇⒊杀臼Э氐鹊纫蛩氐目謶?，項目經(jīng)理們從以前的經(jīng)驗出發(fā)，制定出了一些控制、監(jiān)測項目的方法、技巧。這就是方法論產(chǎn)生的原因。在AgileSoftwareDevelopment一書中，作者提到了方

3、法論的十三個要素，基本能夠函蓋方法論的各個方面：?角色（Roles）?個性（Personality）?技能（Skills）?團隊（Teams）?技術（Techniques）?活動（Activities）?過程（Process）?工件（Wkproducts）?里程碑（Milestones）?標準（Stards）?質量（Quality）?工具（Tools）?團隊價值（TeamValues）它們之間的關系可以用一幅圖來表示：書。在訪談之前，他

4、篤定自己將會發(fā)現(xiàn)高度精確的過程控制是成功的關鍵所在，結果他發(fā)現(xiàn)事實并非如此，他把他的發(fā)現(xiàn)歸結為7條定律。而我在實際中的發(fā)現(xiàn)也包含在這七條定律中，總結起來就只有兩點：溝通和反饋。只要能夠保證良好的溝通和即時的反饋，那么開發(fā)團隊即使并沒有采用先進的方法論，一樣可以成功。相反，那些“高質量“的團隊卻往往由于缺乏這兩個因素而導致失敗（我們這里指的失敗是用戶拒絕使用最終的軟件）。最有效，而成本也最低的溝通方法就是面對面（facetoface）的溝

5、通，而隨著項目團隊的變大，或是另外一些影響因素的加入（比如地理位置的隔絕），面對面的溝通越來越難實現(xiàn)，這導致溝通的的成本逐漸加大，質量也慢慢下降。但這并不是說非面對面的溝通不可，重要的是我們需要知道不同的溝通方式的成本和質量并不相同。XP方法尤為強調面對面的溝通，通過現(xiàn)場客戶、站立會議、結對編程等方式來保證溝通的有效。在我的經(jīng)驗中，一個開發(fā)團隊其實是需要多種溝通方式的結合的。完全的面對面的溝通對某些團隊來說是很難實現(xiàn)的，那么問題的關鍵就

6、在于你如何應用溝通的方式來達到你希望的效果。在前不久結束的歐萊雅創(chuàng)業(yè)計劃大賽上，有一支團隊特別引人注目，他們彼此間素未謀面，僅僅憑借Inter和電話完成了高效的合作。他們雖然沒有使用面對面的溝通方式，但是仍然達成了既定的目標。軟件開發(fā)也是一樣的，面對面的溝通是非常有必要的，但其它的溝通方式也是需要的。再看反饋，不論是控制進度，還是保證客戶的滿意度，這些活動都需要管理成本。軟件開發(fā)中的管理成本的一個通性就是伴隨有中間產(chǎn)出物（interme

7、diatedelivery）。比如說我們的需求規(guī)約、分析文檔、設計文檔、測試計劃，這些都屬于中間產(chǎn)出物。中間產(chǎn)出物的增加將會帶來效率下降的問題，因為開發(fā)人員的時間都花在了完成中間產(chǎn)出物的工作上，花在給軟件新功能上的時間就減少了。而中間產(chǎn)出物的主要目的是兩個，一個是為了保證軟件如客戶所愿，例如需求規(guī)約；另一個是為了作為團隊中的其他成員工作的輸入，例如開發(fā)計劃、測試計劃等。因此，我們也可以針對這兩點來商討對策，一種是采用迭代的思想，提高軟件

8、發(fā)布的頻率，以保證客戶的需求被確實的滿足，另一種就是縮小團隊的溝通范圍，保證成員能夠從其他人那里得到新的思路，而不是撰寫規(guī)范的內部文檔（內部文檔指那些僅為內部開發(fā)人員之間的溝通所需要的文檔）。因此，一個軟件項目的成功和你采用的開發(fā)方法論并沒有直接的關系。重量重量我們根據(jù)把擁有大量artifact（RUP官方翻譯為工件，意思是軟件開發(fā)過程中的中間產(chǎn)物，如需求規(guī)約、設計模型等）和復雜控制的軟件開發(fā)方法稱為重型（HeavyWeight）方法，

9、相對的，我們稱artifact較少的方法為輕型（LightWeight）方法。在傳統(tǒng)的觀念中，我們認為重型方法要比輕型安全許多。因為我們之所以想出重型方法，就是由于在中大型的項目中，項目經(jīng)理往往遠離代碼，他無法有效的了解目前的工程的進度、質量、成本等因素。為了克服未知的恐懼感，項目經(jīng)理制定了大量的中間管理方法，希望能夠控制整個項目，最典型的莫過于要求開發(fā)人員頻繁的遞交各種表示項目目前狀態(tài)的報告。在PlanningXP一書中有一段討論輕重