幫您全面認識敏捷建模思想

1、幫您全面認識敏捷建模思想3那么，當其上的一個或某些條件和你目前的情況有出入的時候，你該怎么辦?試著去改變你目前的情況。缺乏AM的擁護者嗎?那你自己就可以成為一個擁護者。不允許以迭代式和遞增的方式工作，和你的老板們談?wù)劊屗麄兿嘈胚@是一種更好的工作方式，要求他們給你一個機會去證明。沒有足夠的資源?和你的頭兒說明它們的重要性。如果你已經(jīng)盡力改變了所有的情況，但是仍然還有一些條件是你無能為力的，你可以試試以下的選擇：部分的接受AM。你可以盡可能多的接受AM中的原則和實踐，雖然你不會真正的實現(xiàn)AM，但你極有可能成為高效率的開發(fā)人員。一旦你的組織發(fā)現(xiàn)這確不失為一個軟件開發(fā)的好方法，那就有可能會主動的去改

2、變一些必需的要素，從而完全的接受AM。一言以蔽之，循序漸進的實現(xiàn)AM。放棄讓你的組織接受AM。從我個人的角度，我并不喜歡這種選擇，但我不得不承認它是個正確的辦法?，F(xiàn)實就是這樣，AM并不是適合每一個人的，也許你的組織確實是不適合接受AM的。跳槽?？纯赐饷娴氖澜?，還是有很多的組織期望能夠從軟件開發(fā)的競賽中獲勝，他們希望能有積極主動的軟件開發(fā)人員加盟。何時敏捷建模是不適合你的?我猜想敏捷建模在遭遇如下的情形的時候你會陷入麻煩：不滿足以上列出的一個或多個條件。你的組織文化適合采用傳統(tǒng)的開發(fā)流程。許多組織對采用敏捷的軟件開發(fā)方法毫無興趣，他們對目前的狀況感覺很好。這主要是那些政府部門、大型的公司(銀行、

3、保險公司、電信公司)以及專門為這些組織服務(wù)的咨詢公司。這并不是說在這類組織中實施AM完全不可能，但要獲得成功則要付出超乎尋常的努力才行。你的團隊很大，分布在各地。只有那些在同一個工作區(qū)域中相互協(xié)作的團隊才能很好的進行敏捷建模的工作，特別是當開發(fā)人員在一個公共的工作室內(nèi)合作的時候(通常我們稱之為tiger team房間)。你可以嘗試著在一個大型或分散的團隊中應(yīng)用敏捷方法，我在架構(gòu)建模中討論了這種情形，但你很快會發(fā)現(xiàn)你需要挑戰(zhàn)這種方式帶來的溝通問題。我不同意將敏捷方法應(yīng)用于性命攸關(guān)的系統(tǒng)上，例如航空管制系統(tǒng)或醫(yī)療監(jiān)測系統(tǒng)，因為我并沒有相關(guān)的項目經(jīng)驗，無法去研究AM應(yīng)該怎樣應(yīng)用于這些系統(tǒng)。同樣，我也

4、沒有嵌入式系統(tǒng)的相關(guān)經(jīng)驗，因此我也沒有機會將AM技術(shù)應(yīng)用于這種類型的項目。我很懷疑AM是否能夠試用于嵌入式軟件開發(fā)，這是我研究的一部分。我很期待你在敏捷建模的郵件列表中告訴我相關(guān)的經(jīng)驗。(詳情請訪問)8、AM的實踐是如何組合的AM的實踐之間是相互促進的，因為他們彼此支持，彼此激發(fā)。為了使AM更有效率的工作，你需要了解它的實踐是如何組合的。圖1顯示了AM的實踐之間的關(guān)系，它們被分為七類。AM的核心實踐集中在頭四種類別中-驗證，迭代和遞增，團隊協(xié)作，和簡單，你需要完全接受它們才能真正理解敏捷建模。然后，才輪到屬于輔助實踐的文檔，動機，生產(chǎn)率這三個類別。我們先針對核心實踐的四個類別，討論各類中的實踐

5、之間的關(guān)系，然后我們再針對輔助實踐的三個類別，研究各類中實踐之間的關(guān)系，最后我們來討論類別之間的關(guān)系。圖1：AM的實踐是如何組合的核心實踐在團隊協(xié)作類別中有四項實踐-stakeholder的積極參與，和他人一起建模，公開展示模型，和集體所有制。stakeholder的積極參與對你的成功至關(guān)重要，因為你正是為了這些project stakeholder開發(fā)系統(tǒng)，正是為了了解和實現(xiàn)他們的需求。換言之，你需要和你的甲方們密切合作，這就自然的想到了和他人一起建模-這個他人也包括你的stakeholder。當你的建模工作有多人參加時(至少一個project stakeholder和一個除你之外的開發(fā)人員

6、)，你就需要和眾人共同協(xié)作，相互促進，取長補短。一個擅長于業(yè)務(wù)過程建模和業(yè)務(wù)規(guī)則定義的敏捷建模者看不到的方面，一個精通結(jié)構(gòu)化建模技術(shù)(例如UML類圖或數(shù)據(jù)模型)的人極有可能看得到。一樣的道理，系統(tǒng)的直接用戶給你的團隊提供的信息極可能是高級經(jīng)理提供不了的。所以，要有這樣的觀點：你要在項目甲方和開發(fā)團隊中營造一種積極參與的氛圍，只有這樣，才能夠收集各種不同的觀點和經(jīng)驗。集體所有制能夠提升協(xié)作性，因為一個人單獨的進行建模的工作，他很快就會遇到瓶頸，而如果每個人都能夠為建模工作獻計獻策，那么你們就能夠成為一個團隊，輕易的解決問題。公開展示模型能夠使得人們對模型瞻前顧后變得容易了，能夠立刻考慮模型傳達的

7、信息，從而提高團隊的協(xié)作性。當然，我們是假設(shè)模型都在眾人的視線之內(nèi)，或者這些模型都是大家目前正在開發(fā)或相關(guān)的。這方面的主題我在Organizing an Agile Modeling Room中有詳細的討論。迭代和遞增類別中包括了使用合適的artifact，并行創(chuàng)建模型，切換到另外的artifact，小增量建模這幾項實踐。不論哪一個artifact，都有它的長處和短處，任何一個單獨的模型都不足以充分的描述你的項目的各個主要方面(如需求、架構(gòu))。例如你會發(fā)現(xiàn)你為了識別系統(tǒng)的需求，常常需要組合使用用例、業(yè)務(wù)規(guī)則定義、和技術(shù)需求定義。單單靠用例就能令project stakeholder立馬告訴你他

8、們所有的使用需求嗎?這恐怕不太可能。你可以試試換用諸如業(yè)務(wù)規(guī)則之類的artifact來捕獲他們的所有業(yè)務(wù)政策，再換用諸如技術(shù)需求的artifact來捕獲他們的非功能需求。否則，他們會想起點什么就告訴你什么，還會返回去討論先前提過的細節(jié)，甚至是改變他們的原來的主意。你的需求識別工作通常是一個動態(tài)的過程，分析、架構(gòu)、設(shè)計工作也是一樣。我相信物力論中指出了人們以此種方式思考的原因，我們思考的方式明顯是雜亂的。敏捷建模者要認識到人們是以一種動態(tài)的方式在思考，特別是人們處于群體行為時，這樣才能制定對策。敏捷建模者并行創(chuàng)建模型，從而能夠最廣泛的收集信息。這項實踐又是由實踐切換到另外的artifact和小增

9、量建模來支持的-你可能正在使用用例來捕獲使用需求的相關(guān)信息，而當stakeholder開始討論他們對編輯屏幕的要求時，你最好是使用基本用戶界面原型或是傳統(tǒng)用戶界面原型來記錄這些需求。你需要在不同的artifact之間來來回回，每一個artifact最好都需要編碼來驗證，這種方式可以由小增量建模的實踐來實現(xiàn)-最典型的方式就是在這個artifact上做一會兒工作，再換一個artifact，依此類推。簡單這個類別包括了創(chuàng)建簡單的內(nèi)容，簡單地建模，使用最簡單的工具這幾項核心實踐。創(chuàng)建簡單的內(nèi)容和簡單地建模這兩個實踐集中于模型的簡單性，在建模過程中這兩項實踐通產(chǎn)是密不可分的。把精力集中在如何簡單描述，建

10、模者常常會發(fā)現(xiàn)一些使得你手頭的模型簡單化的方法。舉個例子，我曾經(jīng)參加了一項存儲層軟件的開發(fā)工作，軟件的概念類似于EJB的persistence container，封裝了領(lǐng)域?qū)ο蟮囊恍┐鎯Σ僮?。結(jié)果我們架構(gòu)和設(shè)計非常的復(fù)雜，我們試著找到一種辦法：建立一張簡單的圖表，幫助開發(fā)人員理解如何使用存儲層來工作。其間我們還發(fā)現(xiàn)重構(gòu)能夠使我們的設(shè)計易于理解。實踐使用最簡單的工具能夠使得過程變得簡單。工具越簡單就越容易使用，這就降低了他人在你的模型上工作的門檻，也就增加了實際中別人去這么做的機會，這也包括了你的project stakeholder。通過使用最簡單的工具，簡單描述模型也變得更自然了。此外，當

11、你使用一些簡單/低精度的工具，例如索引卡片，即時貼，白板的時候，你就能親身體驗這些簡單工具的效力，你在不知不覺中已經(jīng)強化了一些概念：最簡單的解決方法實際上也能非常有效，對你正在開發(fā)的系統(tǒng)采用簡單的設(shè)計。驗證類別包含了兩個核心實踐：測試性思維和用代碼驗證。有一條哲學(xué)，我常從中受益：如果你無法測試它，你就不應(yīng)該建立它，而你建立的一切都應(yīng)該加以測試。這使得我在系統(tǒng)建模時就考慮測試，也使得我積極的去獲取我的模型的反饋-實際上，我把該條哲學(xué)歸納為考慮你創(chuàng)建的所有artifact的可測試性，以及驗證所有種類的artifact。但這并不僅僅局限于AM的范圍之內(nèi)。通過這種可測試性的考慮，在我建模時，我能夠建立

12、起可測試的模型，而且積極的通過編碼來驗證模型，這樣，我就能夠盡快的證實我的模型是真正可以測試的。輔助實踐文檔類別包括了三項輔助實踐：丟棄臨時模型，合同模型要正式，非到萬不得已不更新。在項目的進行中，需求、對需求的理解、以及對可能的解決方案的理解，都在不斷變化(回憶一下原則擁抱變化)。為了反映這種變化，你需要同步改進你大部分的項目artifact，包括模型和文檔。就像在敏捷文檔討論的那樣，比較好的方法是，不到萬不得已不要更新你的模型和文檔，這種做法才算是敏捷方法。遵循這項實踐，如果你發(fā)現(xiàn)一個模型如果不再需要更新，那就是說這個模型對你的團隊已經(jīng)沒什么價值了，一個沒有價值的模型就可以視為臨時模型，可

13、以丟棄。不過，要注意合同模型。它定義了你的系統(tǒng)和其他系統(tǒng)之間的接口，不太可能經(jīng)常改變，因為它們的重要性是勿庸置疑的。一言以蔽之，如果你有個非合同模型不再更新，那就意味著它已經(jīng)沒有用了。為溝通建模和為理解建模這兩項實踐屬于動機類別。實際上，這兩項實踐并沒有太多的聯(lián)系，有時候你創(chuàng)建模型的目的是為了研究和理解問題，有時候你的目的是為了和其他人交流你的想法，有時候你的目的包括了上述兩者。就像你在圖1中看到的，這兩項實踐常常會一起引出另兩類的實踐，這是下文要討論的主題。最后，生產(chǎn)率類別中包括使用建模標準，逐漸應(yīng)用模式，以及重用現(xiàn)有的資源這幾項實踐。重用現(xiàn)有資源這個實踐要求你盡量利用他人的工作成果并從中受

14、益，這有很多種思考方向：一種是應(yīng)用模式，根據(jù)經(jīng)驗，我認為它是所有重用方法中最有效率的一種，因為你重用的都是其它開發(fā)人員久經(jīng)驗證的解決方案(Ambler,1999)；另一種是遵循建模標準和指南，實際上，不論是標準還是指南，都能夠提高你工作的一致性。是的，你可以自己寫指南，有時你必須要這么做，因為你的實際環(huán)境中會有一些特別的情況。但是你只需要在Internet上稍做搜索就可以找到很多的開發(fā)指南。例如，你可javaCodingStandards找到Java的開發(fā)指南。類別間的聯(lián)系讓我們考慮團隊協(xié)作類別。簡單類別中的實踐增強了實踐stakeholder的積極參與的效果，因為簡單性消除了參與的代溝。迭代

15、和遞增類別中的實踐也使得參與成為可能，尤其是并行創(chuàng)建模型，因為它增大了stakeholder們參加的機會。動機類別中的實踐可以提高集體所有制和和他人一起建模的效果，對問題的理解和溝通通?？梢约ぐl(fā)人們的協(xié)作精神，簡單類別的實踐也也坑達到激發(fā)協(xié)作效果，因為它降低了參與的門檻。公開展示模型的效果可以通過生產(chǎn)力類別中的實踐得到提高。遵循標準，應(yīng)用模式的做法可以增加一致性和可讀性，而重用現(xiàn)有的資源(例如通用架構(gòu))，則給別人開了一個好頭，使別人能夠在你模型的基礎(chǔ)上繼續(xù)。迭代和遞增類的實踐可以支持集體所有制的實行，特別是并行創(chuàng)建模型和切換到另外的artifact，它們使得人們在適當?shù)哪Ｐ蜕瞎餐_發(fā)。簡單類別

16、的實踐由另外幾類的實踐來輔助。使用建模標準和逐漸應(yīng)用模式這兩項實踐支持同一種建模語言(使用標準和容易理解的模式)，從而支持了實踐簡單地建模。文檔類別的實踐也可以支持簡單類別的實踐-只有到萬不得已才更新模型，這樣，你才不會給模型增加不必要的信息。才有可能創(chuàng)建簡單的內(nèi)容以及簡單地建?！，F(xiàn)在再來看迭代和遞增類別。很明顯，團隊協(xié)作類別的實踐支持該類的實踐，由于團隊的參與，針對目前的情況選用正確artifact的機會就增大了，你就可以根據(jù)需要來切換使用不同的artifact。驗證類實踐能夠賦予你使用遞增方法的勇氣，特別是在你用代碼驗證的時候。保證你想法的易測性，你就更有把握同時操作多個artifact，

17、并在它們之間切換，因為測試問題要求你從多個方面來看待它。文檔類實踐同樣可以促進遞增方法，特別是非到萬不得已不更新。但是合同模型要正式這個實踐抑止了遞增方法的應(yīng)用，因為你總是希望能夠盡早的建立和其他系統(tǒng)間的接口標準。切換到另外的artifact和丟棄臨時模型之間也能產(chǎn)生正面的效果，因為一個模型完成目的之后就把工作切換到另一個模型上去。簡單類實踐對這個類別也很重要，通過使用最簡單的工具，你在不同的artifact間來回切換就變得更容易了，你節(jié)省了熟悉工具的時間，只把精力集中在簡單的內(nèi)容和描述上，你也可以較容易記住模型要傳達的信息。最后，動機類實踐可以令你同時進行多個建模工作，因為對于復(fù)雜的系統(tǒng)，你

18、需要從多個方面去溝通，去理解，因此你需要在適當?shù)腶rtifact間來回切換，這樣才能有效的做到這一點。驗證類實踐可由簡單類實踐來支持-創(chuàng)建簡單的內(nèi)容和簡單地建模能使你更容易進行測試性思維。迭代和漸增類實踐也能提高驗證類實踐。例如，在你切換到另外的Artifact時，就可能切換到源代碼，這樣你就可以看到模型確實可以運行。簡單類實踐可以推進生產(chǎn)力類實踐。當你使用簡單模型工作時，逐漸應(yīng)用模式就更容易一些；當你簡單地建模時，使用建模標準也會容易一些，而模型的簡單、易懂，也會使你比較容易的重用現(xiàn)有的資源，例如企業(yè)需求模型或通用的架構(gòu)模型。簡單類實踐以及迭代和漸增類實踐可以支持文檔類實踐的進行。文檔越簡單

19、就越容易使用-如果你的文檔容易理解，這樣你就有把握萬不得已才更新你的文檔，因為你知道做到這一點很簡單；文檔如果很復(fù)雜，你的項目風(fēng)險就很大，因為沒有把握什么時候文檔需要更新。很明顯，非到萬不得已不更新和丟棄臨時模型的運作環(huán)境可以其它的實踐來改善，例如切換到另外的artifact、小增量建模。9、那，你想成為一個敏捷建模者嗎?個性通才還是專才?敏捷建模者的個性Alistair Cockburn指出：很多的方法學(xué)都定義了軟件開發(fā)項目中開發(fā)人員所擔(dān)任的角色，同時還定義個各個角色執(zhí)行的任務(wù)，盡管入席，這些方法并沒有定義這些角色最適合的人選。一個人要想成功的擔(dān)任某個角色，他應(yīng)當很好的適應(yīng)它-雖然這并不需要

20、人們掌握所有的技能，但人們必須要慢慢的熟悉這些技術(shù)。我的經(jīng)驗告訴我，要成為一個成功的敏捷建模者，下面的列出的個性是必要的：團隊競賽第一點，也是最重要的一點，敏捷建模者總是積極的尋求協(xié)作，因為他們意識到他們不是萬事通，他們需要不同的觀點，這樣才能做到最好。軟件開發(fā)可不是游泳，單干是非常危險的。在敏捷的字典中沒有我這個詞。暢所欲言敏捷建模者都有良好的溝通技巧-他們能夠表達出他們想法，能夠傾聽，能夠主動獲取反饋，并且能夠把需要的寫出來。腳踏實地敏捷建模者應(yīng)當腳踏實地他們的精力都集中在滿足用戶的需求上，他們不會在模型上畫蛇添足，即便那雙足是多么的好看。他們滿足于提供可能的方案中最簡單的一種，當然，前提

21、是要能夠完成工作。好奇敏捷建模者樂衷于研究問題，解決問題。凡是都問個為什么敏捷建模者看問題從不會至于表面，而是會打破沙鍋問到底。他們從不會就想當然的認為一個產(chǎn)品或一項技術(shù)和它們的廣告上說的那樣，他們會自己試一試。實事求是敏捷建模者都非常的謙遜，他們從不認為自己是個萬事通，所以他們會在建立好模型之后，用代碼來小心的證明模型的正確。勇氣敏捷建模者應(yīng)當愿意去計劃一個想法，然后做出模型，再想辦法用代碼來驗證。如果結(jié)果不理想，他們就會返工，檢查他們的方法，或是放棄原先的想法。把你的想法告訴你的同伴，再來驗證它的正確，這是需要很大的勇氣的。根據(jù)實驗敏捷建模者應(yīng)當愿意嘗試新的方法，例如一項新的(或是已有的)

22、建模技術(shù)。一般而言，他們也會接受敏捷建模開發(fā)技術(shù)，必要時，為了驗證想法，他們愿意同傳統(tǒng)的思想做斗爭，例如在一個項目中減少文檔數(shù)量。有紀律要堅持不懈的遵循敏捷建模的實踐。對你來說，你可能會在不經(jīng)意間說，加上這個功能吧！無傷大雅?；蚴?，我比project stakeholder更了解。在AM的道路上要想不偏離方向，是需要一定的紀律性的。如果你不具有上面列出的所有個性，那該怎么辦呢，你是不是還想成為一個敏捷建模者呢?不用擔(dān)心，你只需要少量的努力就能夠勝任。相信我，我也沒有辦法做到100%的腳踏實地和實事求是，我也經(jīng)常遇到溝通問題。沒有人能夠擁有所有的個性，大部分人都只能擁有一些個性。每個人都有不同點

23、，這些不同點正是敏捷團隊力量的源泉。某些人可能生來就好奇，另一些人的工作積極性可能比較強。人無完人嘛！通才還是專才?當你要增加團隊成員時，所要處理的一個至關(guān)重要的問題是你希望保持的通才和專才的比率。要回答這個問題，你需要考慮現(xiàn)代軟件開發(fā)環(huán)境。圖1是企業(yè)統(tǒng)一過程(Enterprise Unified Process EUP)的生命周期。(譯注：原文中并沒有提供這副圖，根據(jù)我的猜測，應(yīng)該就是RUP的概述部分的那張生命周期圖，但是因為沒有取得瑞理公司的授權(quán)，所以我暫時也不便引用這張圖，大家可以參閱RUP的相關(guān)資料。)圖左邊的EUP的工作流程暗示著軟件開發(fā)的復(fù)雜-你需要進行業(yè)務(wù)建模，收集需求，分析和設(shè)

24、計系統(tǒng)等等-而這還只是冰山一角。就像圖中列出的那樣，從先啟到產(chǎn)品化的各個階段，預(yù)示著在項目的過程中，不同的時間需要你集中于不同的地方，這需要不同的技能。有一個觀點是很明確的，軟件開發(fā)非常的復(fù)雜，任何一項工作都需要高超的技能和豐富的經(jīng)驗。首要的，要認識到這種復(fù)雜性是軟件開發(fā)與身俱來的，而不是EUP使然的，即便你的團隊采用的是XP方法，抑或是DSDM(Stapleton,1997)方法，或是SCRUM(Beedle&Schwaber,2001)方法，這種復(fù)雜性也還是存在的。盡管這些方法的生命周期看上去并不像EUP那樣的復(fù)雜，但它們?nèi)匀恍枰渲霉芾砘顒?，需要管理活動等等，只是它們處理問題的態(tài)度不同而

25、已。很多的組織對此的第一反應(yīng)就是建立一個專才的團隊。專才的最基本的含義是指那些特別精通某一項任務(wù)的人，因此他們的效率也特別的高。這樣一支團隊，要想高效率的運作，你需要組合這些專才，讓每人負責(zé)一塊任務(wù)，解決之后就把手頭的工作傳給另一個人。這個概念就類似于流水線的想法，如果你是在大量的生產(chǎn)汽車，這種方式會非常的有效，但是以我的經(jīng)驗，在手工的軟件中采用這種方式并不是太合適。而且，這種方式需要一個大團隊的支持-如果軟件開發(fā)中有N中不同的任務(wù)，你至少就需要N位專才才能滿足這種方法的要求。但N是多大?20?50?100?這取決于你對專業(yè)定義的細節(jié)程度，是吧?如果你傾向于每位開發(fā)人員只處理一種artifac

26、t，那單單處理建模工作，就需要20多位的專才，在modeling artifacts essay列出了各種的artifact。如果你傾向于每位開發(fā)人員只負責(zé)一種角色，那再一個EUP的項目中也需要11中角色才能完成所有的工作流程。專才通常都很難同人合作，他們?nèi)鄙僦t遜的品質(zhì)，意識不到其它人的專項技能能夠為他的工作增添價值，他們也意識不到他們的所作所為可能為給后續(xù)的工作造成麻煩，也許他們需要返工，也許他們現(xiàn)在的努力會白費。關(guān)于專才的另一個問題是，即使是在他們擅長的領(lǐng)域，他們的技能也可能根本就沒有那么精熟。IT產(chǎn)業(yè)的技術(shù)高變動率，導(dǎo)致了開發(fā)人員使用了幾個月的新技術(shù)，開始熟悉它，就聲稱自己已經(jīng)是這方面的

27、專家了，因為和他具有同樣層次經(jīng)驗的人畢竟不多。要建立一個專才組成的團隊，這也是一個很明顯的問題。那么，建立一支僅有通才的團隊會怎樣呢?每個人都對軟件開發(fā)有不錯的了解，但是都缺乏足夠詳細的必需知識，完成不了工作。項目需要那些對現(xiàn)階段使用的技術(shù)和技巧都非常熟悉的人。如果你是在使用Enterprise JavaBeans(EJB)，那你既需要對Java編程精通的人，也需要對EJB開發(fā)精通的人。一個使用Oracle的團隊，幕后肯定有一位Oracle數(shù)據(jù)庫管理專家。一個開發(fā)經(jīng)紀人業(yè)務(wù)軟件的團隊，就需要一位能夠了解股票和債券之間的細微差別的人。我的經(jīng)驗是，兩種極端的方式都不可取，你應(yīng)該取它們的中間點。一種

28、方法是團隊中一部分人是通才，一部分人是專才。通才能夠起到團隊的連接劑的作用，通才注重遠景，專才注重項目的具體的難點。這樣做的好處是通才的長處能夠彌補專才的短處，反之也是一樣，由于這種平衡性，通才和專才組對能夠發(fā)揮出極大的優(yōu)勢。一個更好的方法是團隊中主要是通才，僅有一兩個專才。例如，我認為我應(yīng)該算是一個通才，我擅長于處理項目中各項技能之間的配合，而且還精通業(yè)務(wù)應(yīng)用軟件建模，以及對象存儲和Java編程。我的另一位同事也是位通才，特別擅長建模，EJB開發(fā)，以及測試。還有一位堪稱通才的同事則精于網(wǎng)絡(luò)通信和Java編程。這樣一支由通才組成，但又有一項或多項特技的團隊，優(yōu)勢是很明顯的，他們能夠迅速的找到共

29、同點，因為他們畢竟都是通才，而且他們之間有能夠做到優(yōu)勢互補。它的劣勢在于這種人才一般都比較稀缺，動輒都需花費10年甚至20年的時間才能夠培養(yǎng)出這種通才，因此是很難得到的。如果你的團隊中有一些這種人，那你的運氣真是太好了。要認識到新手通常一開始都是專才，這很重要。軟件開發(fā)的新手面對著需要消化的大量知識，往往不知所措，這很正常。大多數(shù)人一開始一開始會把精力集中在開發(fā)的一兩個方面，也許是Java編程，也許是獲取用戶需求，然后以這方面的經(jīng)驗為基礎(chǔ)，再逐漸的拓展知識的覆蓋面。隨著時間的增長，經(jīng)驗在不斷的累積，他們會慢慢的完善自己的技能樹，他們會軟件開發(fā)中各個技能如何配合會更加了解，同時，他們還擅長于一兩

30、門特技。還有一點也很重要，要明白很多的開發(fā)人員的專精反而害了這些人。由于軟件開發(fā)的與身俱來的復(fù)雜性，開發(fā)人員經(jīng)常會落入一個名為單一artifact開發(fā)者的陷阱中去，他們把自己定位為僅僅從事一種artifact的開發(fā)工作，例如代碼，用例模型，或數(shù)據(jù)模型；開發(fā)人員還可能遇到的一個陷阱名為單一角色開發(fā)者，他們的定位是專門從事一種工作的人，例如建模，測試，或編碼。換言之，這些人專精于某一個角色，這種傾向在一些的采用傳統(tǒng)過程的大型組織中特別顯著，問題就出現(xiàn)了，這些陷阱的落入者的視野往往過于狹窄，難以在一個采用敏捷方法的軟件開發(fā)項目中作到高生產(chǎn)率。當然，如果他們原意擴展自己的視野，這個問題就容易得到解決。

31、譯注：想必國內(nèi)的程序員看到這篇文章會很開心吧！畢竟，中國的程序員向來都是以通才自封的。但是，要注意的一點是，這篇文章是針對國外的程序員的，因為國外的程序員通產(chǎn)都只關(guān)注于自己的領(lǐng)域，例如數(shù)據(jù)庫的專家對數(shù)據(jù)庫非常的熟悉，但他可能對測試一竅不通。但是他們對自己領(lǐng)域的了解是非常不得了的?？墒侵袊某绦騿T一般是萬金油，哪兒需要，哪兒就有我的豐姿。只要是軟件領(lǐng)域的，都無所不能，無所不精。但是人的精力都是有限的，不可能什么都精通。樣樣都精，也就是樣樣都庸。這個道理大家務(wù)必要了解。國內(nèi)的很多程序員都算不上是通才，而只能算是庸才。這句話可能不好聽，但是事實如此。如果能夠意識到這一點，好，我想你已經(jīng)不是庸才了，而

32、是在往通才邁進的途中了。本來是不打算譯這篇文章的，因為擔(dān)心有些人看完它后會斷章取義，反而成了一項罪過。但是這篇文章的很多思想值得借鑒，再加上為了保證譯作的完整性，最后還是把它譯了出來，并加上了一段廢話，提醒大家注意。最后，我真誠的希望中國的程序員都能夠成為作者在文中提到的那種既是通才，又是專才的人。10、建模的誤區(qū)走出一般性的設(shè)計誤區(qū)，邁向成功之途無論你遵從的是重量級的方法，比如Enterprise Unified Process(EUP)，還是輕量級的開發(fā)過程，如Extreme Programming(XP)，建模在軟件開發(fā)中都是不可或缺的。但不幸的是其中充斥著各種謬誤與迷思。這來自于各個方

33、面，有從理論家錯誤的研究、數(shù)十年來信息技術(shù)領(lǐng)域內(nèi)的文化沉積、軟件工具開發(fā)商天花亂墜半的市場宣傳以及象Object Management Group(OMG)和IEEE這類組織的標準。這個月，我要揭示建模中的誤區(qū)，指出其相應(yīng)的事實真相。誤區(qū)一：建模就等于是寫文檔這很可能是其中最具破壞力的一條，因為開發(fā)人員可以此為借口而完全放棄建模。許多優(yōu)秀的軟件開發(fā)人員會說他們不想把時間浪費在這些無用的文檔上。他們沉溺于編碼之中，制造著一些脆弱而劣質(zhì)的系統(tǒng)。另外，甚至于許多盡責(zé)的開發(fā)人員現(xiàn)在也認為建模是一件討厭的事，而不愿去學(xué)習(xí)相應(yīng)的建模技術(shù)。事實分析：模型與文檔這二者在概念上是風(fēng)馬牛不相及的-你可以擁有一個不

34、是文檔的模型和不是模型的文檔。一幅設(shè)計圖就是一個模型，而不論是被畫在餐巾紙的背面，或?qū)懺谝粔K白板上，或在Class Responsibility Collaboration(CRC)卡片中，還是根據(jù)記錄在報紙和便簽紙上的流程圖而生成的一個粗略的用戶界面原型。雖然這些都不能說是文檔，但他們卻都是有價值的模型。建模很象是作計劃：作計劃的價值在于計劃編制的過程中，而非計劃本身；價值體現(xiàn)在建模的活動中，而非模型本身。實際上，模型不是你系統(tǒng)中的一部分正式的文檔，而且在完成它們的使命后可以被丟掉。你會發(fā)現(xiàn)值得保留的只有很少的模型，而且它一定是非常完美。誤區(qū)二：從開始階段你可以考慮到所有的一切這種說法流行于

35、二十世紀七十年代到八十年代早期，現(xiàn)今的許多經(jīng)理都是在那個時候?qū)W習(xí)的軟件開發(fā)。對這一點的迷信會導(dǎo)致在前期投入可觀的時間去對所有的一切建模以期把所有一切都弄正確，試圖在編碼開始前就凍結(jié)所有的需求(見誤區(qū)四)，以致于患上分析期麻痹癥要等到模型非常完美之后才敢向前進?；谶@個觀點，項目組開發(fā)了大量的文檔，而不是他們真正想要得到的-開發(fā)滿足需要的軟件。事實分析：怎么才能走出這個誤區(qū)呢?首先，你必須認識到你不能考慮到所有的細枝末節(jié)。第二，認識到編碼員可能會對建模者的工作不以為然(這是可能的，事實上建模者所作的工作在實際價值中只占很少的部分)，他們或許會說模型沒有反應(yīng)出真實的情況。第三，認識到不管你的最初所

36、作的規(guī)格說明書有多好，但注定代碼會很快地與之失去同步，即便是你自己建模自己編碼。一個基本的道理就是代碼永遠只會和代碼保持一致。第四，認識到迭代法(小規(guī)模地建模，編一些代碼，做一些測試，可能還會做一個小的工作版本)是軟件開發(fā)的準則。它是現(xiàn)代重量級的軟件開發(fā)過程(如EUP)，以及輕量級(如XP)的基本原理。誤區(qū)三：建模意味著需要一個重量級的軟件開發(fā)過程走入這個誤區(qū)(經(jīng)常與誤區(qū)一有聯(lián)系)的項目組常常是連建模都徹底地放棄了，應(yīng)為這樣的軟件開發(fā)過程對他們來說太復(fù)雜太沉重了。這不亞于一場天災(zāi)。事實分析：你可以用一種敏捷的方式取而代之。關(guān)于用簡單的工具進行簡單地建模的詳細內(nèi)容可參看Agile Modelin

37、g(AM)。而且，你可以丟棄你的模型當使命完之后，同樣也可以很基本的方式進行建模(比如，從辦公桌起來，來到白板前就開始構(gòu)略草圖)。只要你愿意，你就可以輕松地建模。誤區(qū)四：必須凍結(jié)需求這個要求常常來自高級經(jīng)理，他們確切地想知道他們從這個項目組能得到什么東西。這樣的好處就是在開發(fā)周期的早期確定下需求，就可以確切地知道所要的是一個什么樣的東西；缺點就是他們可能沒有得到實際上所需要的(不全或錯誤的需求，譯者)。事實分析：變化總會發(fā)生的。由于優(yōu)先級的變化和逐漸對系統(tǒng)有了更進一步的理解，都會引起需求的變化。與凍結(jié)需求相反，估計項目成功的風(fēng)險，盡量去接受變化而且相應(yīng)地采取行動，就象XP所建議的一樣。誤區(qū)五：

38、設(shè)計是不可更改的如同誤區(qū)四，要求每一個開發(fā)人員必須嚴格遵從設(shè)計，導(dǎo)致開發(fā)人員為了符合設(shè)計而作了錯誤的事情或以錯誤的方式作正確的事情?；蛘呤呛唵蔚睾雎粤嗽O(shè)計，否定了所有設(shè)計可能帶來的好處。凍結(jié)了設(shè)計，你就不能從在項目進程中所學(xué)到知識進一步獲益。另外一個很大的趨勢就是開發(fā)出大量的文檔而不是實際的軟件，使用面向文檔的CASE工具而不是能給項目帶來實際價值的面向應(yīng)用的工具。事實分析：事實上，設(shè)計會經(jīng)常根據(jù)開發(fā)人員和數(shù)據(jù)庫管理員的反饋進行修改，因為他們是最接近實際應(yīng)用的人，通常他們對技術(shù)環(huán)境的理解要好于建模者。我們必須的面對這樣一個事實：人無完人，他們所作的工作也不可能盡善盡美。難道您真的想將一個并不完

39、善的設(shè)計固定下來而不再去修改其中的錯誤嗎?另外，如果需求并沒有被凍結(jié)，其實就意味著你不能凍結(jié)你的設(shè)計，因為任何需求的修改勢必影響設(shè)計。對之，正確的態(tài)度是：只要你的代碼還在改動，涉及就沒完。誤區(qū)六：必須使用CASE工具建模常常被認為是一項復(fù)雜的工作，因此需要大量地使用CASE工具輔助進行。事實分析：是的，建?？梢允呛軓?fù)雜的。但你完全可以建立一個有效而簡單的模型表述其中關(guān)鍵的信息，而不是將一些無關(guān)緊要的細節(jié)包括進來。比如，我經(jīng)常使用UML建立模型來表示類、它們的屬性及一些關(guān)鍵的業(yè)務(wù)操作，但并不畫出屬性的存取操作(get和set)，以及維護與其它類關(guān)系的框架代碼，或者其他一些瑣碎的實現(xiàn)細節(jié)。我通過建

40、模尋找解決問題的方法，讓我和我的同事能繼續(xù)前進去實現(xiàn)這個模型。以這樣靈活的方式，大多數(shù)情況下我并不需要一個CASE工具來支持建模工作，一塊白板，或者一臺數(shù)字相機足以。這樣，我就不用花時間去評估CASE工具，不用去和工具供應(yīng)商討論許可證的問題，也免去了人員培訓(xùn)開銷。CASE工具只有當它能體現(xiàn)最佳性價比時(相對你自己的情況而言)，才值得購買。大多數(shù)情況下，我都能不用它而達到目的(完成建模)。我經(jīng)常使用的工具有Together/J(因為它能產(chǎn)生數(shù)目可觀的Java框架代碼；還有ERWin()-因為它能規(guī)劃數(shù)據(jù)庫。這兩個工具真正地幫助我實現(xiàn)了軟件開發(fā)的目的制造滿足用戶要求的軟件。但我絕大多數(shù)得建模工作仍然使用的是簡單的工具，而不是CASE工具。誤區(qū)七：建模是在浪費時間許多新手都這樣認為，這主要是因為他們所接受的教育僅僅局限于如何編寫代碼，對于完整的開發(fā)流程鮮有接觸。而且他們的經(jīng)驗也僅限于如何實現(xiàn)代碼，就如初級程序員。他們放棄了提高效率和學(xué)習(xí)技能的機會，這些技能能夠使他們很容易地適應(yīng)不同的項目或組織。他們應(yīng)該為此感到羞愧。事實分析：在大多數(shù)情況下，在開始編碼之前畫一個草圖、開發(fā)一個粗率的原型或者制作一些索引卡片都能提高你的生產(chǎn)效率。高效的開發(fā)者在編碼之前都要進行建模工作。另外，建模是一種很好的在項目組成員與項目負責(zé)人之間溝通途徑。你