幫您全面認(rèn)識(shí)敏捷建模思想

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

17、并在它們之間切換，因?yàn)闇y(cè)試問(wèn)題要求你從多個(gè)方面來(lái)看待它。文檔類(lèi)實(shí)踐同樣可以促進(jìn)遞增方法，特別是非到萬(wàn)不得已不更新。但是合同模型要正式這個(gè)實(shí)踐抑止了遞增方法的應(yīng)用，因?yàn)槟憧偸窍Ｍ軌虮M早的建立和其他系統(tǒng)間的接口標(biāo)準(zhǔn)。切換到另外的artifact和丟棄臨時(shí)模型之間也能產(chǎn)生正面的效果，因?yàn)橐粋€(gè)模型完成目的之后就把工作切換到另一個(gè)模型上去。簡(jiǎn)單類(lèi)實(shí)踐對(duì)這個(gè)類(lèi)別也很重要，通過(guò)使用最簡(jiǎn)單的工具，你在不同的artifact間來(lái)回切換就變得更容易了，你節(jié)省了熟悉工具的時(shí)間，只把精力集中在簡(jiǎn)單的內(nèi)容和描述上，你也可以較容易記住模型要傳達(dá)的信息。最后，動(dòng)機(jī)類(lèi)實(shí)踐可以令你同時(shí)進(jìn)行多個(gè)建模工作，因?yàn)閷?duì)于復(fù)雜的系統(tǒng)，你

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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