敏捷思維軟件架構(gòu)設(shè)計(jì)方法論

1、敏捷思維－敏捷思維－架構(gòu)設(shè)計(jì)中的方法學(xué)架構(gòu)設(shè)計(jì)中的方法學(xué)(1)從方法論看架構(gòu)設(shè)計(jì)從方法論看架構(gòu)設(shè)計(jì)林星(iamlinx@)2002年3月方法論對(duì)軟件開(kāi)發(fā)而言意味著什么？我們?nèi)绾慰创浖_(kāi)發(fā)中的方法論？方法論能夠成為軟件開(kāi)發(fā)的救命稻草嗎？在讀過(guò)此文后，這些疑惑就會(huì)得到解答。在第一篇文章中，我們來(lái)了解標(biāo)題中的一些詞的含義。?方法學(xué)是什么？?敏捷是什么？?為什么討論架構(gòu)？方法論方法論方法論的英文為Methodology，詞典中的解釋為“Ase

2、riesofrelatedmethodstechniques“我們可以把它定義為軟件開(kāi)發(fā)（針對(duì)軟件開(kāi)發(fā)）的一整套方法、過(guò)程、規(guī)則、實(shí)踐、技術(shù)。關(guān)于方法論的出現(xiàn)的問(wèn)題，我很贊同AlistairCockburn的一句話(huà)，“方法論源于恐懼。“出于對(duì)項(xiàng)目的超期、成本失控等等因素的恐懼，項(xiàng)目經(jīng)理們從以前的經(jīng)驗(yàn)出發(fā)，制定出了一些控制、監(jiān)測(cè)項(xiàng)目的方法、技巧。這就是方法論產(chǎn)生的原因。在AgileSoftwareDevelopment一書(shū)中，作者提到了方

3、法論的十三個(gè)要素，基本能夠函蓋方法論的各個(gè)方面：?角色（Roles）?個(gè)性（Personality）?技能（Skills）?團(tuán)隊(duì)（Teams）?技術(shù)（Techniques）?活動(dòng)（Activities）?過(guò)程（Process）?工件（Wkproducts）?里程碑（Milestones）?標(biāo)準(zhǔn)（Stards）?質(zhì)量（Quality）?工具（Tools）?團(tuán)隊(duì)價(jià)值（TeamValues）它們之間的關(guān)系可以用一幅圖來(lái)表示：書(shū)。在訪談之前，他

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

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

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

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

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

9、相對(duì)的，我們稱(chēng)artifact較少的方法為輕型（LightWeight）方法。在傳統(tǒng)的觀念中，我們認(rèn)為重型方法要比輕型安全許多。因?yàn)槲覀冎韵氤鲋匦头椒?，就是由于在中大型的?xiàng)目中，項(xiàng)目經(jīng)理往往遠(yuǎn)離代碼，他無(wú)法有效的了解目前的工程的進(jìn)度、質(zhì)量、成本等因素。為了克服未知的恐懼感，項(xiàng)目經(jīng)理制定了大量的中間管理方法，希望能夠控制整個(gè)項(xiàng)目，最典型的莫過(guò)于要求開(kāi)發(fā)人員頻繁的遞交各種表示項(xiàng)目目前狀態(tài)的報(bào)告。在PlanningXP一書(shū)中有一段討論輕重