小型軟件團(tuán)隊(duì)過(guò)程改進(jìn)方法 (一)

小型軟件團(tuán)隊(duì)過(guò)程改進(jìn)方法

一、從方法到編碼

軟件管理與軟件開(kāi)發(fā)是截然區(qū)分的嗎？

關(guān)于項(xiàng)目經(jīng)理來(lái)說(shuō)，其職責(zé)是軟件項(xiàng)目的管理，而關(guān)于架構(gòu)師、

編碼人員來(lái)說(shuō)，其職責(zé)是軟件設(shè)計(jì)與開(kāi)發(fā)。盡管在一些小型的團(tuán)隊(duì)中，

這兩種職責(zé)有的時(shí)侯候是同一個(gè)人擔(dān)任的，但兩種角色的區(qū)分是必要

的。從事過(guò)軟件開(kāi)發(fā)的人都能或者多或者少的感受到軟件管理與軟件

開(kāi)發(fā)之間客觀存在的溝壑。

我常常聽(tīng)到來(lái)自兩個(gè)方面的聲音。一邊埋怨說(shuō)設(shè)計(jì)師、編程人員

陽(yáng)奉陰違，難以管束，導(dǎo)致已訂立的軟件過(guò)程形同虛設(shè)。另一邊埋怨

軟件過(guò)程存在諸多不恰當(dāng)?shù)牡胤?，變成了軟件開(kāi)發(fā)的絆腳石。

現(xiàn)代的方法學(xué)理論與相應(yīng)的過(guò)程實(shí)踐為我們奠定了軟件開(kāi)發(fā)科

學(xué)管理的基礎(chǔ)，個(gè)中的翹楚包含RUP與XP,縱觀這些方法、過(guò)程，

都非常強(qiáng)調(diào)過(guò)程的流暢、生命周期的連續(xù)c而在實(shí)際的應(yīng)用中，我們

卻常常能夠看見(jiàn)對(duì)它們的不恰當(dāng)?shù)亩?，不正確的使用。特別是那些

希望在自己的軟件團(tuán)體中引入新型的方法過(guò)程新手們。關(guān)于他們來(lái)

說(shuō)，最容易犯的一個(gè)錯(cuò)誤就是忽視了如何利用一個(gè)軟件過(guò)程來(lái)制造一

個(gè)成功的軟件。

關(guān)于如何建立一個(gè)軟件過(guò)程的資料很多，但是這些資料并沒(méi)有把

為什么需要過(guò)程，過(guò)程的目的是什么之類的問(wèn)題說(shuō)清晰。而這些資料

的讀者們，往往需要花費(fèi)大量的時(shí)間，親自進(jìn)行實(shí)踐之后，才能獲得

這些問(wèn)題的答案，而付出的代價(jià)是教訓(xùn)與挫折。同樣的，我與我的伙

伴們也經(jīng)歷了這樣一個(gè)過(guò)程。因此，我希望把我在過(guò)程應(yīng)用、過(guò)程改

造中涉及到的問(wèn)題例舉出來(lái)（使用過(guò)程模式的方式）。假如大家能夠

利用到這些經(jīng)驗(yàn)（哪怕是一些），那本文的目的也就達(dá)到了。因此，

本文并不是一篇專門討論如何建立過(guò)程的文章，也沒(méi)有涉及建模、設(shè)

計(jì)、編碼等方面的內(nèi)容。但是本文中所討論的內(nèi)容都能夠?qū)σ陨系幕?/p>

動(dòng)起到部分的指導(dǎo)作用。

敏捷？敏捷！

從開(kāi)始研究軟件工程，我就對(duì)敏捷過(guò)程的概念情有獨(dú)衷，但是隨

著學(xué)習(xí)的深入（所犯錯(cuò)誤的增多），我發(fā)現(xiàn)敏捷是無(wú)處不在的，她是

一種尺度，一種處于"混亂〃與“死板”之間的平衡藝術(shù)。有句俏皮話說(shuō)

的是"一放就亂，一管就死”，這句話很好的點(diǎn)出了軟件過(guò)程的一種無(wú)

奈性。假如沒(méi)有嚴(yán)格的規(guī)定，軟件開(kāi)發(fā)就陷入一種混亂、無(wú)序的狀態(tài),

但是假如制定了過(guò)于嚴(yán)格的規(guī)定，軟件人員的思路又受到極大的約

束，管理成本也隨之上升。敏捷正是一種處于兩個(gè)極端之間微妙平衡

的藝術(shù)。這種藝術(shù)難以完全表述，但是能夠通過(guò)一些指導(dǎo)，來(lái)幫助大

家達(dá)到這種境地。

因此，我們能夠推想的到，敏捷是見(jiàn)仁見(jiàn)智的。每一個(gè)軟件團(tuán)體

都有自身的特性，其敏捷過(guò)程必定都不盡相同。如何設(shè)計(jì)出成功的敏

捷過(guò)程，來(lái)保證軟件團(tuán)體的成功呢？本文通過(guò)一些過(guò)程模式的討論，

掀開(kāi)了問(wèn)題的一角C關(guān)于過(guò)程設(shè)計(jì)的完整的討論，大家能夠參考敏捷

軟件開(kāi)發(fā)［AlistairCockburn］一書(該書近來(lái)將有中文版面世)，

該書全面的描述了過(guò)程設(shè)計(jì)的來(lái)龍去脈，與如何根據(jù)組織的特點(diǎn)來(lái)選

擇適當(dāng)?shù)倪^(guò)程。

因此，盡管本文中并沒(méi)有特別提到敏捷的字眼，但是所討論的內(nèi)

容無(wú)不在敏捷思維的范圍之內(nèi)。

MDA推動(dòng)軟件可重用框架的建立

我有一個(gè)夢(mèng)想，希望有一天能夠不用在諸多的平臺(tái)之間搖來(lái)擺

去。雖說(shuō)Java語(yǔ)言的口號(hào)就是跨平臺(tái)。但事實(shí)上，我們還是無(wú)法完

全擺脫平臺(tái)的束縛C

在UML2.0的規(guī)范中，提到了一個(gè)MDA(ModelDriven

Architecture)的概念。在眾多的軟件平臺(tái)中不知該如何選擇，已經(jīng)

演變?yōu)楫?dāng)今軟件開(kāi)發(fā)的要緊難題。MDA的存在目的就是為熟悉決這個(gè)

問(wèn)題。通過(guò)MDA技術(shù)，一個(gè)UML的模型能夠是平臺(tái)無(wú)關(guān)的，稱之PIM

(Platform-IndependentModel),也能夠是與特定平臺(tái)有關(guān)的，稱

之PSM(Platform-SpecificModel)o利用平臺(tái)技術(shù)的軟件商，能

夠?qū)Ｗ⒂谧约旱念I(lǐng)域，集中描述業(yè)務(wù)功能，業(yè)務(wù)規(guī)則，而無(wú)須考慮特

定的技術(shù)，構(gòu)建出一個(gè)PIM,然后，通過(guò)支持MDA的工具，將PIM轉(zhuǎn)

換(通過(guò)不一致Profile進(jìn)行映射)為一個(gè)或者多個(gè)PSM。這時(shí)候的

模型仍然是UML的c但是，這個(gè)轉(zhuǎn)換過(guò)程盡管有工具的輔助，但仍然

需要外力的介入.接下來(lái)，開(kāi)發(fā)工具將會(huì)從PSM中產(chǎn)生可執(zhí)行代碼°

這就是MDA的思路，它把以往以程序?yàn)橹行牡拈_(kāi)發(fā)模式轉(zhuǎn)變?yōu)橐栽O(shè)計(jì)

為中心的開(kāi)發(fā)模式C

Finance

以往的重用，往往是基于代碼的，比如算法的重用、界面組件的

重用，卻往往沒(méi)有將重用提升到設(shè)計(jì)的層次上。MDA為我們建立可重

用的框架提供了一個(gè)很好的指導(dǎo)。注意上面的這副圖，最外面的兩層

就表達(dá)了MDA能夠用于設(shè)計(jì)重用的基本理念。倒數(shù)第二層的含義是利

用MDA來(lái)進(jìn)行通用軟件（比如事務(wù)、目錄服務(wù)）的模型設(shè)計(jì)，倒數(shù)第

一層則表示MDA能夠用于特定業(yè)務(wù)領(lǐng)域的設(shè)計(jì)建模。能夠想象，今后

軟件公司中的最有價(jià)值的資產(chǎn)，就是這些設(shè)計(jì)模型。

本文并不打算全面討論MDA,除了簡(jiǎn)單的介紹MDA的思路之外，

更重要的一點(diǎn)是企業(yè)可重用框架的建立。軟件企業(yè)的核心在于知識(shí)，

如何有效的將人腦中的知識(shí)存儲(chǔ)起來(lái)，并不斷的使用與進(jìn)展，是軟件

企業(yè)成功的關(guān)鍵.本文提到的可重用框架，指的就是將軟件開(kāi)發(fā)有關(guān)

知識(shí)存儲(chǔ)起來(lái)的框架。這個(gè)思路是本文的一個(gè)核心思路。在本文看來(lái),

可重用框架不但包含了設(shè)計(jì)模型，還包含了過(guò)程與方法。軟件開(kāi)發(fā)是

在這個(gè)框架之內(nèi)運(yùn)作的，同時(shí)反過(guò)來(lái)影響著框架的完善與改進(jìn)。

過(guò)程塑造模式語(yǔ)言

下述的模式都是從軟件開(kāi)發(fā)過(guò)程中，圍繞著可重用框架的建立

整理出來(lái)的一些經(jīng)驗(yàn)，之因此整理為模式的形式，是由于這種方式

有利于類似情況的鑒別與對(duì)其進(jìn)行必要的擴(kuò)展。在軟件開(kāi)發(fā)中會(huì)遇

到各類各樣的問(wèn)題，以上模式中討論到的問(wèn)題都是我們?cè)趯?shí)踐中，

或者是與其他開(kāi)發(fā)團(tuán)隊(duì)溝通中反復(fù)遇到的。因此堅(jiān)定了我們將之整

理為模式的信心。目前我們得到的模式并不多，但是隨著經(jīng)驗(yàn)的增

力口，我們會(huì)得到更多的積存。

本文介紹的模式都比較注重權(quán)衡的藝術(shù)。我們認(rèn)為這是敏捷思維

的必定結(jié)果。世界上并沒(méi)有什么絕對(duì)的情況，特別是目前多變的社會(huì)

中，昨天的標(biāo)準(zhǔn)并不適合于今天的環(huán)境。因此，我們的平衡點(diǎn)也在不

斷的變化。

?將實(shí)現(xiàn)與接口分離，即把如何做隱藏起來(lái)，而把做什么展示給

客戶。

?繼承與多態(tài)使得我們能夠在一個(gè)抽象的層次上（基類與接口）

思考問(wèn)題，并能夠根據(jù)現(xiàn)實(shí)的需求進(jìn)行靈活的調(diào)整（子類與實(shí)

現(xiàn)）。

?通過(guò)設(shè)計(jì)模式與設(shè)計(jì)技巧的應(yīng)用，能夠有效的降低系統(tǒng)的不一

致部分之間的耦合度。特別是簡(jiǎn)化客戶端的代碼。

在使用與比較過(guò)幾種開(kāi)發(fā)語(yǔ)言與開(kāi)發(fā)環(huán)境之后，我們發(fā)現(xiàn)，事實(shí)

上最關(guān)鍵的并不是使用什么樣的面向?qū)ο笳Z(yǔ)言（或者環(huán)境），關(guān)鍵的

是你運(yùn)用面向?qū)ο笏季S的能力，或者者說(shuō)對(duì)現(xiàn)實(shí)世界的懂得、抽象、

映射的能力。這種能力決定了你的開(kāi)發(fā)水平的高低，而語(yǔ)言與環(huán)境只

是一種重要的實(shí)現(xiàn)手段與工具而已。而這種思維能力，盡管能夠通過(guò)

例子與討論來(lái)進(jìn)行介紹，但更關(guān)鍵的還是在實(shí)踐中進(jìn)行練習(xí)。在本文

討論的模式中，我們會(huì)夾帶的對(duì)這些內(nèi)容進(jìn)行討論。由于我們認(rèn)為，

開(kāi)發(fā)思想與開(kāi)發(fā)過(guò)程是無(wú)法區(qū)分的，否則，你的開(kāi)發(fā)過(guò)程就沒(méi)有靈魂。

這也是我們的主題所要強(qiáng)調(diào)的：從方法到編碼，鑄造起一個(gè)敏捷的、

流暢的過(guò)程，才能夠保證開(kāi)發(fā)過(guò)程的成功，開(kāi)發(fā)軟件的成功。

此外，本篇是總論性文章，在撰寫此文時(shí)，該篇事實(shí)上是最后完

工的，因此，建議大家在看過(guò)全文之后，假如還有耐心，能夠重看此

篇，相信會(huì)有另外一番收獲。

現(xiàn)在請(qǐng)大家進(jìn)入我們的模式之旅。

在軟件過(guò)程中，我們?nèi)绾伪ＷC信息能夠得到正確的傳遞呢？我們

用什么方法來(lái)避免信息傳遞的失真呢？我們?nèi)绾卧谶@樣一個(gè)過(guò)程中

處理人與人之間的交互呢？在正確傳遞信息的情況下，我們又如何保

證投入的最小化呢？

1、意圖

軟件開(kāi)發(fā)過(guò)程是知識(shí)傳遞、知識(shí)轉(zhuǎn)換的過(guò)程。注重知識(shí)轉(zhuǎn)換中的

完整性，保證知識(shí)通過(guò)各個(gè)階段與活動(dòng)，順利的轉(zhuǎn)換為軟件是極為重

要的。

2、示例

元朗公司是國(guó)內(nèi)某銀行的下屬企業(yè)。從年初開(kāi)始，公司就投入了

大量的人力為銀行開(kāi)發(fā)新版本的國(guó)際收支系統(tǒng)。考慮到這是一個(gè)非常

龐大的系統(tǒng)，因此公司把原先的軟件開(kāi)發(fā)團(tuán)隊(duì)擴(kuò)大了一倍，補(bǔ)充的人

員有些來(lái)自于其它的項(xiàng)目組，有些人員來(lái)自別的公司。為了保證開(kāi)發(fā)

的順利進(jìn)行，項(xiàng)目經(jīng)理引入了軟件過(guò)程。但是從一開(kāi)始，煩惱的情況

就出現(xiàn)了。項(xiàng)目組中的技術(shù)人員與銀行的領(lǐng)域?qū)＜抑g不斷出現(xiàn)意見(jiàn)

相左的情況。要緊的問(wèn)題是后加入的員工對(duì)目標(biāo)領(lǐng)域不熟悉，難以配

合領(lǐng)域?qū)＜业墓ぷ鳌阕钤愀獾氖?，某些領(lǐng)域?qū)＜疑硖幃惖兀虼嗽谛?/p>

求分析的中期，開(kāi)發(fā)團(tuán)隊(duì)邀請(qǐng)這些異地的領(lǐng)域?qū)＜襾?lái)到開(kāi)發(fā)所在地，

進(jìn)行了為期兩天的討論會(huì)。結(jié)果并不理想，討論會(huì)上充滿了對(duì)原先已

定稿的需求的反對(duì)性意見(jiàn)，技術(shù)專家、領(lǐng)域?qū)＜页吵梢粓F(tuán)。需求分析

階段不得不在原先的基礎(chǔ)上延長(zhǎng)了50%的時(shí)間。在進(jìn)入設(shè)計(jì)與編碼階

段之后，問(wèn)題少了許多。但在設(shè)計(jì)到編碼的過(guò)程中仍是出了一些煩惱,

原因是新加入的人員不熟悉開(kāi)發(fā)團(tuán)隊(duì)的設(shè)計(jì)風(fēng)格。通過(guò)一番周折，問(wèn)

題基本解決了。可等到項(xiàng)目進(jìn)入到測(cè)試階段，矛盾一下子就凸現(xiàn)出來(lái)

了。測(cè)試報(bào)告指出，軟件中存在著大量的問(wèn)題，大部分的問(wèn)題都被定

性為無(wú)法滿足需求的嚴(yán)重錯(cuò)誤。通過(guò)對(duì)錯(cuò)誤的復(fù)審，排除了其中1796

的嚴(yán)重錯(cuò)誤。通過(guò)分析，發(fā)現(xiàn)其中70%的錯(cuò)誤都是發(fā)生在后加入人員

負(fù)責(zé)的模塊中。而產(chǎn)生大量錯(cuò)誤的一個(gè)要緊原因是在編碼階段，由于

銀行啟用了新的會(huì)計(jì)制度，導(dǎo)致大量模塊被修改，由于時(shí)間緊迫，因

此沒(méi)有進(jìn)行正規(guī)的需求調(diào)研?，F(xiàn)在看來(lái)，領(lǐng)域?qū)＜遗c技術(shù)專家對(duì)同一

個(gè)問(wèn)題的懂得并不相同。最后，項(xiàng)目的開(kāi)發(fā)周期延長(zhǎng)了40%。

3、分析

軟件過(guò)程每經(jīng)歷一個(gè)階段，就會(huì)發(fā)生一次知識(shí)轉(zhuǎn)換的情況。這種

轉(zhuǎn)換是由人來(lái)完成的，這就是像是接力一樣，一個(gè)人把腦中的知識(shí)以

某種方式傳遞給另一個(gè)人，再有另一個(gè)人傳遞下去，直至編碼人員把

這些知識(shí)固化在最終的軟件中。在軟件成型之前，知識(shí)的要緊載體是

文檔與模型。我們稱它們?yōu)楣ぜ?Artifact)o比如，需求階段時(shí)，

領(lǐng)域?qū)＜以诩夹g(shù)專家的幫助下，將自己腦中對(duì)領(lǐng)域的認(rèn)識(shí)傳遞給技術(shù)

人員，并最終形成需求規(guī)格書或者是用例模型。而在分析設(shè)計(jì)階段，

技術(shù)專家借助需求規(guī)格書，把腦中對(duì)軟件的初始認(rèn)識(shí)進(jìn)一步轉(zhuǎn)換為分

析模型、設(shè)計(jì)模型、數(shù)據(jù)模型等工件。最后，在編碼階段，編碼人員

把這些工件中隱藏的知識(shí)轉(zhuǎn)化為軟件的形式。通過(guò)測(cè)試與部署，軟件

將會(huì)交付到用戶手中。這是非常典型的軟件開(kāi)發(fā)過(guò)程，再簡(jiǎn)單的軟件

開(kāi)發(fā)也需要經(jīng)歷上述的這些階段。

能夠看到，在上述的軟件開(kāi)發(fā)過(guò)程中，知識(shí)形式發(fā)生了兩次的重

要轉(zhuǎn)換，知識(shí)所屬角色也改變了兩次。知識(shí)完成第一次的形式轉(zhuǎn)換之

后，將成為需求規(guī)格書（或者同類工件）的形式，知識(shí)從領(lǐng)域?qū)＜业?/p>

腦中轉(zhuǎn)換到技術(shù)專家的腦中。然后，知識(shí)開(kāi)始了第二次的形式轉(zhuǎn)換，

形成設(shè)計(jì)模型（與同類工件）。隨著知識(shí)從技術(shù)專家轉(zhuǎn)移到編碼人員，

知識(shí)轉(zhuǎn)換為其最終的軟件形式。在這些轉(zhuǎn)換的過(guò)程中，最容易出現(xiàn)信

息遺漏、信息失確實(shí)情況。保證轉(zhuǎn)換過(guò)程中知識(shí)的完整性與正確性，

對(duì)軟件開(kāi)發(fā)具有重要的意義。

4、問(wèn)題

假如保證轉(zhuǎn)換時(shí)知識(shí)的完整性與正確性？

5、方法

知識(shí)轉(zhuǎn)換的主體是人，因此我們要緊的計(jì)策也是針對(duì)人來(lái)展開(kāi)

的。我們明白，軟件過(guò)程的特點(diǎn)就是：越早埋下禍根對(duì)項(xiàng)目的殺傷力

越大。因此我們首先需要重點(diǎn)防范的對(duì)象應(yīng)該是在初始需求分析階

段。需求分析階段涉及的知識(shí)非常的多，大家假如有興趣能夠參看我

的文章一需求的實(shí)踐。但這里我們重點(diǎn)的任務(wù)是找出需求分析階段中

發(fā)生知識(shí)轉(zhuǎn)移的關(guān)鍵點(diǎn)。

領(lǐng)域?qū)＜遗c技術(shù)專家是需求階段中最重要的兩種人，不論你的項(xiàng)

目與團(tuán)隊(duì)規(guī)模屬于哪一種層次，一定都包含這兩種角色。假如你的團(tuán)

隊(duì)中領(lǐng)域?qū)＜遗c技術(shù)專家是同一種人，那么恭喜你，你能夠不用閱讀

這一段的內(nèi)容了。惋惜在強(qiáng)調(diào)分工協(xié)作與軟件規(guī)模不斷擴(kuò)大的今天，

這種人已經(jīng)非常難找了。領(lǐng)域?qū)＜沂侵R(shí)的最初持有者，其職責(zé)是為

項(xiàng)目提供準(zhǔn)確的、完整的需求信息c技術(shù)專家的職責(zé)則是幫助領(lǐng)域?qū)?/p>

家完成這一項(xiàng)工作c因此，首先請(qǐng)保證領(lǐng)域?qū)＜遗c技術(shù)專家是能夠溝

通的，示例中的項(xiàng)目的第一個(gè)問(wèn)題就是團(tuán)隊(duì)的新成員與領(lǐng)域?qū)＜抑g

存在溝通壁壘。在我們的經(jīng)驗(yàn)中，就發(fā)生過(guò)一位優(yōu)秀的技術(shù)人員與一

位資深的領(lǐng)域?qū)＜覡?zhēng)吵的情況。剖析原因之后，我們發(fā)現(xiàn)，最要緊的

原因是他們兩個(gè)人都太優(yōu)秀了，技術(shù)人員有一定的領(lǐng)域經(jīng)驗(yàn)，領(lǐng)域?qū)?/p>

家有一定的開(kāi)發(fā)經(jīng)驗(yàn)，這導(dǎo)致了雙方在討論中的強(qiáng)硬立場(chǎng)。因此，假

如遇到類似的情況，請(qǐng)對(duì)你的組織進(jìn)行崗位調(diào)整。但在執(zhí)行這項(xiàng)工作

之前，請(qǐng)小心你的說(shuō)辭，不要傷害到任何一個(gè)人。”我們的某個(gè)小組

有煩惱，那邊非常需要你的經(jīng)驗(yàn)與能力”會(huì)是一句不錯(cuò)的說(shuō)辭。其次,

技術(shù)專家不應(yīng)該提出任何可能影響領(lǐng)域?qū)＜业膯?wèn)題。只有領(lǐng)域?qū)＜也?/p>

能夠提出需求，技術(shù)專家起到的只是輔助作用。因此請(qǐng)杜絕這種情況。

再次，假如你的領(lǐng)域?qū)＜也恢灰粋€(gè)人，那么你需要考慮領(lǐng)域?qū)＜抑g

可能出現(xiàn)的不一致。為領(lǐng)域團(tuán)隊(duì)指定一位領(lǐng)導(dǎo)者是一種不錯(cuò)的做法。

在我們的一個(gè)項(xiàng)目中，就曾邀請(qǐng)對(duì)方公司的財(cái)務(wù)總監(jiān)擔(dān)任這一角色。

理由有二：1、財(cái)務(wù)總監(jiān)具有權(quán)威性；2、財(cái)務(wù)總監(jiān)熟悉公司的全部運(yùn)

作。此外，假如領(lǐng)域?qū)＜曳植荚诓灰恢碌攸c(diǎn)的話，你需要在該階段的

某個(gè)時(shí)期，安排需求討論會(huì)，并考慮一種能夠溝通的方式，以便隨時(shí)

能夠熟悉身處異地的領(lǐng)域?qū)＜业囊庖?jiàn)。這種情況關(guān)于那些擁有分公司

的公司（比如銀行、證券、保險(xiǎn)、銷售公司等等）而言非常的普遍。

因此，我們?cè)谛枨蠓治鲭A段，首先要處理好領(lǐng)域?qū)＜遗c技術(shù)專家之間

的關(guān)系。應(yīng)該說(shuō)，這里提到的內(nèi)容不僅僅適用于需求階段，在整個(gè)的

開(kāi)發(fā)過(guò)程中都有用處。

需求不是實(shí)現(xiàn)C需求表示的是有什么(What),并不關(guān)心如何做

(How)o假如在需求分析階段把精力分散到了如何實(shí)現(xiàn)需求上，那

么需求分析的效果就會(huì)受到影響。這表達(dá)在需求的完整性與正確性兩

個(gè)方面。領(lǐng)域?qū)＜遗c技術(shù)專家都可能犯類似的錯(cuò)誤。領(lǐng)域?qū)＜彝?/p>

能夠針對(duì)自己的工作來(lái)描述需求，而他會(huì)很容易的把自己關(guān)于需求實(shí)

現(xiàn)看法參雜到需求描述中。從項(xiàng)目的整體范圍來(lái)看，這種需求描述有

的時(shí)候候是有問(wèn)題的。假如你開(kāi)發(fā)的是一個(gè)定制應(yīng)用，那問(wèn)題還不大,

假如你開(kāi)發(fā)的是一個(gè)產(chǎn)品，那么問(wèn)題就很嚴(yán)重了。領(lǐng)域?qū)＜颐枋龅男?/p>

求一定是你需要的內(nèi)容嗎？比如，你打算開(kāi)發(fā)一個(gè)配送的管理應(yīng)用，

但是領(lǐng)域?qū)＜野汛罅康木ㄔ诹怂谠鹊墓局腥绾螌?shí)現(xiàn)配送

的流程上，這個(gè)過(guò)程可能適合于他的公司，但是關(guān)于產(chǎn)品而言，可能

就不合適，由于并非所有的配送公司都使用這種流程的。好吧，你想

要的內(nèi)容與你不想要的內(nèi)容混合在一起，這使得你不得不花費(fèi)精力對(duì)

需求進(jìn)行進(jìn)一步的整理。因此，好的做法是，一開(kāi)始就明確領(lǐng)域?qū)＜?/p>

應(yīng)該提供什么，而且，盡可能的提供需求，而不是需求實(shí)現(xiàn)。多問(wèn)一

些諸如"假如環(huán)境發(fā)生變化，你該如何做”之類的問(wèn)題，否則你會(huì)發(fā)現(xiàn),

用戶的需求變化將會(huì)對(duì)你的軟件造成很大的影響。再說(shuō)技術(shù)專家，技

術(shù)專家常常犯的毛病是把分析參雜到需求調(diào)研中來(lái)，從需求描述中精

練出一些業(yè)務(wù)實(shí)體(或者進(jìn)行CRC討論)是能夠的，但是過(guò)早的考慮

實(shí)現(xiàn)方式將會(huì)限制你的思維。因此，請(qǐng)確保需求只是需求，這樣才能

夠盡可能保證需求的完整性與正確性。

需求復(fù)審是非常重要的檢查點(diǎn)。請(qǐng)確保你正確的使用它。需求復(fù)

審需要領(lǐng)域?qū)＜遗c技術(shù)專家、與管理者的參與。需求復(fù)審是保證需求

完整性與正確性的最后一道防線。在很多的文章（包含我的需求的實(shí)

踐一文）、過(guò)程都對(duì)需求復(fù)審進(jìn)行了論述，我們這里就不贅述了c在

實(shí)踐過(guò)程中，我們發(fā)現(xiàn)，需求復(fù)審還有一個(gè)好的方式，為了能夠通過(guò)

需求復(fù)審，需求分析人員（包含領(lǐng)域?qū)＜遗c技術(shù)專家）會(huì)非常努力的

找出需求中的問(wèn)題。因此，在你的過(guò)程中加入這個(gè)檢查點(diǎn)是非常有必

要的。

好的，假如這一切都進(jìn)行順利的話，最后的需求規(guī)格書應(yīng)該是比

較完美的，而技術(shù)專家也已經(jīng)從領(lǐng)域?qū)＜夷抢锸煜さ搅俗銐虻男畔ⅲ?/p>

能夠開(kāi)始下一階段的開(kāi)發(fā)了。這里，我們?cè)倩ㄒ恍┕P墨來(lái)討論迭代過(guò)

程中，我們?nèi)绾翁幚硇枨?。?shí)踐中，我們認(rèn)為迭代次數(shù)并不是越多越

好，應(yīng)該根據(jù)項(xiàng)目規(guī)模與團(tuán)隊(duì)特點(diǎn)進(jìn)行區(qū)分，每一次的迭代都可能有

自己的目標(biāo)。比如首次迭代的周期可能比較短，其要緊的目標(biāo)定為提

供軟件原型、驗(yàn)證要緊設(shè)計(jì)思路等。第二次的迭代的周期能夠長(zhǎng)一些,

目標(biāo)能夠定位為實(shí)現(xiàn)要緊功能。假如軟件規(guī)模比較大，也能夠?yàn)槊看?/p>

迭代設(shè)定需求范圍（或者要緊場(chǎng)景），這樣就能夠防止需求擴(kuò)散的情

況。這已經(jīng)超出了本文的范圍，因此我們這里只是簡(jiǎn)單的提一下。

很難嚴(yán)格的區(qū)分分析階段與設(shè)計(jì)階段，至少我是這么覺(jué)得的。他

們的差別僅僅是在分析的全面程度上（有點(diǎn)類似于以往的概要設(shè)計(jì)與

全面設(shè)計(jì)）。在實(shí)踐中，我們發(fā)現(xiàn)，并沒(méi)有必要嚴(yán)格的區(qū)分它們，但

是你需要保證模型已經(jīng)完整的描述了需求。這里能夠設(shè)置檢查點(diǎn)來(lái)驗(yàn)

證，也能夠在設(shè)計(jì)模型出來(lái)之后再進(jìn)行檢查，這取決于具體的項(xiàng)目。

因此，我們?cè)诜治鲭A段與設(shè)計(jì)階段結(jié)束之前需要進(jìn)行設(shè)計(jì)復(fù)審。

從MartinFowler提出分析模式的概念之后（現(xiàn)在他的第二本分

析模式正在寫作中），它就成為分析建模的有利助手之-----對(duì)領(lǐng)域

概念進(jìn)行分析與建模，并描述它們之間的關(guān)系（我在點(diǎn)空間上的一篇

讀書筆記反應(yīng)了需求與分析之間的關(guān)系）,但是請(qǐng)千萬(wàn)注意，不要誤

用與濫用分析模式,由于任何分析模式的提出，都是基于某個(gè)上下文

環(huán)境中的需求的，假如上下文環(huán)境不一致，那么模式就需要改進(jìn)或者

改造。因此，分析模式是一個(gè)好的開(kāi)始，但需要你針對(duì)實(shí)際需求具體

分析。在應(yīng)用模式方面，F(xiàn)rankBuschmann的ApplyingPatterns是

一篇不錯(cuò)的參考文章，其中文版公布在點(diǎn)空間上。

在軟件過(guò)程中設(shè)立反饋活動(dòng)，能夠有效的減少項(xiàng)目的偏差。就像

我們騎自行車，很少能夠走一條直線，通常我們是根據(jù)對(duì)目標(biāo)的偏差

進(jìn)行忽左忽右的調(diào)整。這就是反饋的機(jī)理。原型法是一種不錯(cuò)的反饋

機(jī)制，根據(jù)我們的經(jīng)驗(yàn)，視覺(jué)刺激對(duì)用戶是最為關(guān)鍵的，因此不論你

的需求文檔做的如何的優(yōu)秀，仍然比不上一個(gè)能夠看得見(jiàn)的軟件原型

有效。這一實(shí)踐很多的軟件工程資料中都有敘述，我們就不深入熟悉

To另一種反饋機(jī)制是漸進(jìn)交付。把軟件產(chǎn)品分為多個(gè)迭代周期，每

個(gè)周期交付一個(gè)可運(yùn)行的軟件，在獲得用戶的反饋意見(jiàn)之后，在下一

個(gè)迭代周期進(jìn)行改進(jìn)，最后一個(gè)迭代周期交付的就是完整的軟件了。

6、對(duì)可重用框架的改進(jìn)

在找到了適合軟件企業(yè)自身的知識(shí)接力方法之后，應(yīng)當(dāng)將其作為

規(guī)范或者指導(dǎo)意見(jiàn)，加入到現(xiàn)有的軟件過(guò)程中。比如，在需求分析完

成之后強(qiáng)制要求進(jìn)行需求評(píng)審。加入到過(guò)程中的方法，小心不要流于

形式。這樣，既付出了成本，又收不到應(yīng)用的效果。使用工具也是保

持知識(shí)順利交接的重要方法。比如，使用自動(dòng)產(chǎn)生源代碼的工具，模

型設(shè)計(jì)工具、幫助產(chǎn)生工具、對(duì)象-關(guān)系映射工具等等。假如這些工

具對(duì)你的過(guò)程起到了潤(rùn)滑的作用，請(qǐng)規(guī)范與普及工具的使用。

7、小結(jié)

.請(qǐng)確保領(lǐng)域?qū)＜遗c技術(shù)專家之間的順暢溝通。

.完整、準(zhǔn)確的描述需求。

?進(jìn)行需求復(fù)審與設(shè)計(jì)復(fù)審。

?保證分析模型（設(shè)計(jì)模型）能夠完整的描述需求。

?保持需求信息到設(shè)計(jì)信息到代碼注釋的一致。

.使用反饋機(jī)制。

過(guò)程的最終目的是代碼，開(kāi)發(fā)過(guò)程中的所有活動(dòng)都圍繞著這一目

的而展開(kāi)。假如沒(méi)有最后的用于交付的代碼，軟件就無(wú)法成為軟件。

因此，務(wù)必保證過(guò)程能夠產(chǎn)出代碼，而且是優(yōu)秀的代碼。

1、意圖

不管哪一種過(guò)程，其最終目的都是為了產(chǎn)生出可執(zhí)行、同時(shí)可用

的軟件。因此軟件過(guò)程中的各類活動(dòng)應(yīng)該圍繞著快速、準(zhǔn)確的實(shí)現(xiàn)這

一目的而展開(kāi)的。

2、示例

維力亞軟件公司是一家合資公司，由于有外資背景，公司內(nèi)部很

早就引入了軟件工程，并嚴(yán)格的對(duì)人員角色進(jìn)行分工。包含領(lǐng)域建模

人員、架構(gòu)設(shè)計(jì)師、高級(jí)程序員、程序員、界面設(shè)計(jì)師等等多種角色。

每個(gè)人各司其職，充分發(fā)揮出了分工的特點(diǎn)。但是隨著公司開(kāi)發(fā)項(xiàng)目

的逐步增多，這種方式也顯露出其弊端來(lái)。每個(gè)人的要緊目標(biāo)都是為

了通過(guò)評(píng)審，而有的時(shí)候候，就算是通過(guò)評(píng)審的工件，依然可能存在

問(wèn)題。但這時(shí)候扯皮就出現(xiàn)了。項(xiàng)目中存在的一些中空地帶。與交錯(cuò)

地帶，常常發(fā)生無(wú)人問(wèn)津的情況。開(kāi)發(fā)過(guò)程的效率開(kāi)始下降，開(kāi)發(fā)成

本開(kāi)始上升。問(wèn)題盡管不是一下子出現(xiàn)的，但是已經(jīng)逐步變得嚴(yán)重起

來(lái)了。

3、分析

我們?cè)谶M(jìn)行過(guò)程設(shè)計(jì)，或者引入一個(gè)過(guò)程理論的時(shí)候，是否具有

思考過(guò)該過(guò)程的每一個(gè)階段、每一個(gè)活動(dòng)的目的是什么，它們對(duì)生成

最后的軟件有什么樣的幫助，這些幫助關(guān)于我們所在的組織有意義

嗎。很多情況下，我們并沒(méi)有這么做，或者者隨著軟件過(guò)程的定型，

就不再思考這類的問(wèn)題。一開(kāi)始并沒(méi)有什么了不起的，但是當(dāng)軟件過(guò)

程演變成了一種政治體系的時(shí)候，那么問(wèn)題就會(huì)慢慢嚴(yán)重起來(lái)。

4、問(wèn)題

如何讓過(guò)程圍繞著產(chǎn)出軟件的核心目標(biāo)而不斷演進(jìn)？

5、方法

從上一篇介紹的內(nèi)容中，我們明白軟件過(guò)程的每一個(gè)階段都是知

識(shí)轉(zhuǎn)換的過(guò)程，知識(shí)轉(zhuǎn)換的終點(diǎn)就是軟件C問(wèn)題在于，我們?nèi)绾伪ＷC

這種轉(zhuǎn)換的效率呢？

現(xiàn)代軟件的進(jìn)展的趨勢(shì)是重用。我們開(kāi)發(fā)一個(gè)軟件已經(jīng)很少會(huì)從

最底層開(kāi)始編寫了。我們使用各類各樣的技術(shù)與平臺(tái)。包含數(shù)據(jù)庫(kù)、

分布式體系、UI機(jī)制、業(yè)務(wù)元素等等。因此現(xiàn)在的軟件編寫往往都

是站在巨人的肩膀上開(kāi)始的。不一致的軟件組織，肩膀的高低也不一

樣。比如有的軟件組織使用J2EE平臺(tái)，有的軟件組織則使用.NET平

臺(tái)。但是能夠確信的一點(diǎn)是，每個(gè)軟件組織都或者多或者少的擁有自

己的平臺(tái)體系開(kāi)發(fā)經(jīng)驗(yàn)。這些經(jīng)驗(yàn)的表現(xiàn)形式也不盡相同，可能是儲(chǔ)

存在某些高級(jí)技術(shù)人員的腦中，也可能是儲(chǔ)存為文檔、模型或者代碼

的形式。

關(guān)于單個(gè)的項(xiàng)目而言，其過(guò)程一定是從需求開(kāi)始，以部署（與后

續(xù)保護(hù)）為終結(jié)的。但是關(guān)于長(zhǎng)時(shí)間存在的軟件組織而言，更重要的

是項(xiàng)目經(jīng)驗(yàn)、技術(shù)經(jīng)驗(yàn)、管理經(jīng)驗(yàn)的積存。這樣說(shuō)可能過(guò)于抽象，我

們舉一個(gè)具體的例子。在完成了一個(gè)庫(kù)存管理項(xiàng)目之后，我們把庫(kù)存

管理的領(lǐng)域知識(shí)制作為商業(yè)組件的形式，而把項(xiàng)目中學(xué)習(xí)到的一些編

碼的技巧整理為模式的形式，并把項(xiàng)目過(guò)程中積存的過(guò)程方法添加到

現(xiàn)有的軟件過(guò)程中c這些經(jīng)驗(yàn)的堆積就是在一開(kāi)始我們提出的可重用

框架。對(duì)一個(gè)軟件團(tuán)隊(duì)的來(lái)說(shuō)，它的所有軟件項(xiàng)目都應(yīng)該是圍繞著這

一個(gè)可重用框架而展開(kāi)的。

迄今為止，我們見(jiàn)過(guò)的大多數(shù)的可重用框架表現(xiàn)形式都能夠總結(jié)

為：以開(kāi)發(fā)平臺(tái)為基礎(chǔ)，積存自己的商業(yè)組件，并以此為中心訂立開(kāi)

發(fā)活動(dòng)。這種形式是不是最好并沒(méi)有定論，但我們是抱著學(xué)習(xí)的態(tài)度

來(lái)研究它的。

以開(kāi)發(fā)平臺(tái)為基礎(chǔ)的意思是軟件組織務(wù)必有自己所熟悉的開(kāi)發(fā)

平臺(tái)，其大部分的項(xiàng)目都是在此基礎(chǔ)上進(jìn)行的。目前最流行的兩種軟

件開(kāi)發(fā)平臺(tái)是J2EE與.NET,但是就算是同一個(gè)平臺(tái)，不一致的軟件

組織對(duì)平臺(tái)內(nèi)部的側(cè)重也是不一致的（同樣關(guān)于J2EE技術(shù)，有的軟

件組織可能把JSP與Servlet作為核心選擇，而另一些軟件組織則把

重點(diǎn)放在EJB上）。選擇一種廣泛應(yīng)用的、具有生命力的平臺(tái)技術(shù)是

非常重要的。由于你的框架將會(huì)以此為基礎(chǔ)進(jìn)行，而框架的轉(zhuǎn)移戌本

是非常之高的。盡管我們?cè)谝婚_(kāi)始介紹的MDA思路為我們繪制了一副

平臺(tái)無(wú)關(guān)設(shè)計(jì)的美好愿景，但是在目前階段，我們?nèi)匀灰鎸?duì)不一致

軟件平臺(tái)造成的嚴(yán)重隔閡。

務(wù)必指出的是，我們上面提到的開(kāi)發(fā)平臺(tái)指的是在操作系統(tǒng)這個(gè)

層次之上的平臺(tái)，也就是俗稱的中間件平臺(tái)。但是從中間件到最終的

產(chǎn)品之間是否具有過(guò)渡的平臺(tái)呢。事實(shí)上可重用框架就扮演了這一角

色。軟件市場(chǎng)上已經(jīng)出現(xiàn)了商業(yè)化的可重用框架了。IBM的

SanFrancisco框架就是這種概念的代表。

平臺(tái)技術(shù)僅僅只是提供了一個(gè)技術(shù)，而軟件組織要生存與進(jìn)展，

還需要積存與進(jìn)展自己的商業(yè)組件。并將商業(yè)組件進(jìn)展成為可重用框

架。商業(yè)組件的好壞，直接與軟件組織的能力、經(jīng)驗(yàn)，與平臺(tái)技術(shù)有

關(guān)。商業(yè)組件可能直接表現(xiàn)為代碼的形式（Bean.類、COM組件等），

也可能只是描述性的記錄（文檔）。商業(yè)紐件是經(jīng)驗(yàn)積存而成的,請(qǐng)

注意，商業(yè)組件的設(shè)計(jì)并不完全等同于面向?qū)ο箝_(kāi)發(fā)，由于面向?qū)ο?/p>

只是一種技術(shù)手段，但是商業(yè)組件設(shè)計(jì)的優(yōu)劣，更重要的是對(duì)業(yè)務(wù)的

懂得程度。舉一個(gè)最淺顯的例子，一個(gè)熟知面向?qū)ο箝_(kāi)發(fā)、面向組件

開(kāi)發(fā)的設(shè)計(jì)師，讓他介入他完全不熟悉的行業(yè)組件設(shè)計(jì)，他的表現(xiàn)將

會(huì)大打折扣。

到目前為之，大家所認(rèn)識(shí)的框架仍然是技術(shù)型的框架。但事實(shí)并

非如此，框架還包含了外延的一系列軟件活動(dòng)。這才是一個(gè)完整的框

架。結(jié)合之前我們討論的軟件交付為開(kāi)發(fā)目標(biāo)。我們把這種開(kāi)發(fā)方式

稱之以可重用框架為核心，以交付為目標(biāo)的軟件開(kāi)發(fā)。這事實(shí)上并不

是什么了不起的概念，大部分的軟件組織都已經(jīng)這么做了，只是沒(méi)有

意識(shí)到自己的方式而已。熟悉這一點(diǎn)，能夠幫助軟件組織有效的改進(jìn)

自身的構(gòu)架。

平臺(tái)技術(shù)與組件開(kāi)發(fā)并不是本文的重點(diǎn)，因此我們?cè)诖_信了兩者

的重要性之后，把精力轉(zhuǎn)移到軟件活動(dòng)上。

在擁有一個(gè)框架核心（平臺(tái)與商業(yè)組件）之后，框架需要包含這

樣的活動(dòng)（或者活動(dòng)集）：收集項(xiàng)目需求，并將需求映射到核心構(gòu)架

上來(lái)。這事實(shí)上就是需求階段到設(shè)計(jì)階段要做的情況。但是由于我們

的活動(dòng)是以軟件交付為目標(biāo)的，因此我們需要明確的指出活動(dòng)中的注

意事項(xiàng)。

?為映射工作設(shè)計(jì)需求描述規(guī)格。需求并不是一件容易的事。最

難的莫過(guò)于尺度的把握了，比如需求要多全面。使用現(xiàn)成的技

術(shù)來(lái)定義需求描述規(guī)格，并根據(jù)核心框架的特點(diǎn)進(jìn)行必要的擴(kuò)

展。比如，我們使用成熟的用例技術(shù)來(lái)描述需求，同時(shí)我們要

求需求按照不一致類的商業(yè)組件進(jìn)行分類索引。用例技術(shù)的推

薦讀物是AlistairCockburn的WritingEffectiveUseCases

一書，該書目前已有英文影印版。

原型方法能夠有效的幫助最終軟件的成功。所謂原型方法，就是

選取系統(tǒng)的某個(gè)部分（最直接或者風(fēng)險(xiǎn)最高的部分，通常是界面原

型），實(shí)現(xiàn)并呈現(xiàn)給用戶，以獲得反饋，為后續(xù)的活動(dòng)提供指導(dǎo)。

原型方法最大的好處是能夠幫助用戶認(rèn)識(shí)軟件，消除用戶的疑慮，并

發(fā)掘潛藏的需求。圍繞著是否拋棄原型這一根本問(wèn)題，原型方法能夠

分為漸進(jìn)原型方法與舍棄型原型方法。前者是在一個(gè)軟件原型的基礎(chǔ)

上不斷的演進(jìn)，并最終進(jìn)展為可用的軟件，后者則是在開(kāi)發(fā)出原型之

后就將它舍棄。漸進(jìn)原型方法充分利用了原型，但是由于缺乏前期設(shè)

計(jì)，可能會(huì)導(dǎo)致最終產(chǎn)品存在性能或者設(shè)計(jì)問(wèn)題。舍棄型原型克服了

這個(gè)問(wèn)題，但是它浪費(fèi)了原型開(kāi)發(fā)的那段時(shí)間。不論使用何種方法，

最重要的是在項(xiàng)目一開(kāi)始就決定使用哪一種原型方法。模棱兩可的使

用兩種方法是兵家大忌。最終你無(wú)法利用任何一種方法的優(yōu)點(diǎn)，而所

有的缺點(diǎn)都將降臨到你身上。相較而言，漸進(jìn)型原型方法更適合于應(yīng)

用在小型項(xiàng)目上，由于項(xiàng)目并不復(fù)雜的話，設(shè)計(jì)的改進(jìn)比較容易。關(guān)

于一個(gè)擁有構(gòu)架的團(tuán)隊(duì)而言，把原型方法納入構(gòu)架之中是很有意義

的。假如構(gòu)架足夠成數(shù)，迅速開(kāi)發(fā)出一個(gè)原型并不是什么很困難的情

況。這樣就能夠在投入最小化的情況下獲得原型方法的優(yōu)勢(shì)。假如情

況是這樣的話，舍棄型原型方法大概更適合一些。

.從需求模型中生成同意測(cè)試。該活動(dòng)把需求映射到測(cè)試上。在

這個(gè)活動(dòng)中，不但要注意功能性需求（如完成的功能），還需

要注意非功能性需求（性能要求）。同樣的，同意測(cè)試也需要

同意復(fù)審。能夠按照需求的組織方式來(lái)組織同意測(cè)試。

?設(shè)計(jì)模型完成之后，同意測(cè)試已經(jīng)細(xì)化到模型的各個(gè)元素上了

（比如包、類）。該項(xiàng)活動(dòng)與將需求映射到設(shè)計(jì)的活動(dòng)是同步

進(jìn)行的。由于它們處理的信息是非常類似的。與同意測(cè)試一樣,

這兩個(gè)活動(dòng)都需要由團(tuán)隊(duì)來(lái)保證。

?在進(jìn)入編碼階段之后，開(kāi)發(fā)人員根據(jù)同意測(cè)試與設(shè)計(jì)模型，將

會(huì)為自己負(fù)責(zé)的部分設(shè)計(jì)編寫單元測(cè)試。單元測(cè)試的編寫順序

是否優(yōu)先于編碼，這取決于各人的看法。關(guān)于這方面的討論，

能夠參看XP的單元測(cè)試實(shí)踐。從我個(gè)人的經(jīng)驗(yàn)來(lái)看，先寫單元

測(cè)試，再寫代碼不失為一個(gè)很好的辦法，另一種做法是，讓兩

個(gè)緊密合作的開(kāi)發(fā)人員相互為對(duì)方編寫單元測(cè)試。

其次，我們需要保證測(cè)試的最小單元一單元測(cè)試的成功。所謂皮

之不存，毛將焉附。單元測(cè)試沒(méi)有組織好，最后的軟件是不可能戌功

的：

?需要注意單元測(cè)試的覆蓋率。這里的覆蓋率指的是是否能夠完

全檢測(cè)出錯(cuò)誤所在。比如邊界條件的測(cè)試等。開(kāi)發(fā)團(tuán)隊(duì)中的架

構(gòu)師之類的角色需要為此負(fù)責(zé)，假如無(wú)法檢查所有的單元測(cè)試,

那么能夠進(jìn)行抽查與代碼復(fù)審會(huì)議的形式。后者是一種很優(yōu)秀

的做法。從代碼中抽取出一段，開(kāi)發(fā)人員一起分析單元測(cè)試存

在什么問(wèn)題，會(huì)使得大家編寫單元測(cè)試的功力不斷的增長(zhǎng)。

.單元測(cè)試一定要是自動(dòng)化的。Junit就是一個(gè)不錯(cuò)的自動(dòng)化測(cè)

試框架。保證單元測(cè)試的自動(dòng)化，同時(shí)避免單元測(cè)試與特定環(huán)

境有關(guān)，這樣就能夠順利的進(jìn)行回歸測(cè)試。這關(guān)于迭代式的軟

件開(kāi)發(fā)是非常必要的。同時(shí)，我們也應(yīng)該認(rèn)識(shí)到，單元測(cè)試的

穩(wěn)固性取決于設(shè)計(jì)的穩(wěn)固性。我們能夠想象，假如測(cè)試的類方

法的參數(shù)、命名都發(fā)生改變，那么測(cè)試是確信需要重新組織的。

因此，面向?qū)ο蟮某橄笏季S關(guān)于現(xiàn)代軟件開(kāi)發(fā)而言是費(fèi)產(chǎn)重要

的。為了做到測(cè)試的自動(dòng)化，盡量避免將邏輯硬編碼在界面中，

并小心的處理數(shù)據(jù)庫(kù)。能夠嘗試著建立測(cè)試數(shù)據(jù)庫(kù)。

?假如測(cè)試的內(nèi)容需要并入核心構(gòu)架，那么這部分的測(cè)試工作需

要增加，并對(duì)構(gòu)架可能的修改進(jìn)行測(cè)試。因此，學(xué)習(xí)開(kāi)源軟件

的做法，將構(gòu)架的穩(wěn)固版本與開(kāi)發(fā)版本相區(qū)分是比較保險(xiǎn)的。

讓測(cè)試活動(dòng)隨著軟件開(kāi)發(fā)的進(jìn)行而進(jìn)行，讓測(cè)試活動(dòng)貫穿整個(gè)開(kāi)

發(fā)周期。這有點(diǎn)類似于全面質(zhì)量管理的思想。由于軟件開(kāi)發(fā)過(guò)程的失

敗并不是突然而至的，而是在平常的不經(jīng)意間一點(diǎn)一點(diǎn)的積存起來(lái)

的。使用測(cè)試活動(dòng)來(lái)消除這種微小的不穩(wěn)固性，能夠大幅度的提高最

終軟件的質(zhì)量。但是，在一個(gè)團(tuán)隊(duì)中引入正規(guī)的。頻繁的測(cè)試活動(dòng)是

需要耐心的。能夠先從單元測(cè)試著手，慢受的普及這種做法。

測(cè)試活動(dòng)能夠衍生為日創(chuàng)建與冒煙測(cè)試。關(guān)于有復(fù)數(shù)的開(kāi)發(fā)人員

參與的軟件項(xiàng)目，就無(wú)法避免正視集成測(cè)試的局面。有過(guò)類似經(jīng)驗(yàn)的

人都能夠想象的到這種集成測(cè)試的難度。專門有一句話是描述這種局

面的：”我們已經(jīng)花了90%的時(shí)間來(lái)完成90%的軟件，但我們還需要

90%的時(shí)間來(lái)完成剩下的10%\現(xiàn)代的軟件往往都包含成百上千的文

件，這些文件的編譯鏈接的過(guò)程是很復(fù)雜的。而日創(chuàng)建的思想就是每

天進(jìn)行一次這樣的過(guò)程，形成一個(gè)可執(zhí)行文件°但這只是日創(chuàng)建第一

部分內(nèi)容。日創(chuàng)建還需要對(duì)軟件進(jìn)行冒煙測(cè)試，測(cè)試的要緊內(nèi)容就是

單元測(cè)試中所編寫的內(nèi)容，保證軟件能夠通過(guò)所有的測(cè)試。

日創(chuàng)建需要留下一些調(diào)試的時(shí)間，特別是在軟件開(kāi)發(fā)初期，不一

致開(kāi)發(fā)人員的代碼整合在一起出現(xiàn)問(wèn)題的可能性極大。隨著對(duì)這項(xiàng)實(shí)

踐的熟悉程度，問(wèn)題會(huì)逐步減少°日創(chuàng)建能夠很明顯的提高產(chǎn)品質(zhì)量,

與提升團(tuán)隊(duì)的士氣c盡管日創(chuàng)建活動(dòng)需要付出額外的一些成本，但是

相關(guān)于集成測(cè)試的不可控，這些成本還是值得的。

6、小結(jié)

?投資于框架能夠保證軟件開(kāi)發(fā)的成功。

?應(yīng)用有效的實(shí)踐活動(dòng)來(lái)完善框架。

?將需求映射到核心框架上來(lái)。

?使用原型法。

?注意測(cè)試活動(dòng)。

?假如可能，使用日創(chuàng)建，并進(jìn)行冒煙測(cè)試。

規(guī)則不一致于指南。規(guī)則是目標(biāo)受眾所務(wù)必遵守的，而指南是建議目

標(biāo)受眾遵守的。

一致性原則是軟件開(kāi)發(fā)中重要原則，也是最令人困惑的原則。做

到完全的一致性將會(huì)導(dǎo)致高昂的成本，而不一致又會(huì)導(dǎo)致項(xiàng)目出現(xiàn)各

類各樣的問(wèn)題。能夠想到，這又是一個(gè)需要權(quán)衡的問(wèn)題°

1、意圖

軟件過(guò)程中的大部分工件都需要保持其相互之間的一致性。但

是，工件越多，保持一致性的開(kāi)銷也就越大。我們需要在一致性與成

本之間保持平衡。

2、示例

天利軟件公司的項(xiàng)目經(jīng)理正在為開(kāi)發(fā)過(guò)程中出現(xiàn)的大量的不一致

問(wèn)題頭疼不已。從軟件過(guò)程一開(kāi)始的需求階段，版本問(wèn)題就一直困擾

著項(xiàng)目組的成員。項(xiàng)目組的成員并非沒(méi)有經(jīng)驗(yàn)，只是這一次的項(xiàng)目規(guī)

模超過(guò)了以往的項(xiàng)目，因此公司決定使用嚴(yán)格的過(guò)程，以保證軟件質(zhì)

量。開(kāi)發(fā)過(guò)程中每個(gè)活動(dòng)都務(wù)必產(chǎn)出文檔。第一次的不一致發(fā)生在需

求調(diào)研中期的一次研討會(huì)上，當(dāng)時(shí)的會(huì)議上發(fā)現(xiàn)了三種不一致版本的

需求規(guī)格書。之后情況越來(lái)越糟，文檔的數(shù)量不斷增多，由于所有的

開(kāi)發(fā)人員都需要編寫文檔、使用文檔，因此發(fā)生了各類原先沒(méi)有料到

的情況，包含新文檔被覆蓋；設(shè)計(jì)人員手中的需求規(guī)格書不是最新的

版本；設(shè)計(jì)書變更之后，代碼卻沒(méi)有相應(yīng)的變更；代碼中的方法說(shuō)明

與設(shè)計(jì)模型中的方法說(shuō)明不一致。為了對(duì)文檔進(jìn)行操縱，公司不得不

從項(xiàng)目組中抽調(diào)了兩名開(kāi)發(fā)人員來(lái)操縱文檔，并加強(qiáng)了文檔的管理。

但是隨之而來(lái)的是開(kāi)發(fā)周期的延長(zhǎng)。

3、分析

一致性包含兩個(gè)方面：一是不一致工件之間的一致性，二是使

用同樣的方法來(lái)處理問(wèn)題。

軟件過(guò)程的每個(gè)階段都需要產(chǎn)出不一致的工件。典型的比如需求

分析階段將產(chǎn)出需求規(guī)格書、用例模型、非功能需求等，設(shè)計(jì)階段產(chǎn)

出設(shè)計(jì)模型、類圖。而在軟件開(kāi)發(fā)中，我們常常會(huì)遇到需求的變更的

情況，因此我們需要依次對(duì)我們的需求模型、分析模型、設(shè)計(jì)模型、

代碼進(jìn)行修改，以保持它們之間的一致性。假如項(xiàng)目處于前期階段，

這種修改量并不大，由于工件較少，假如項(xiàng)目進(jìn)行到后期。需求的改

變將會(huì)涉及到大量的工件。關(guān)于期限比較緊張的項(xiàng)目而言（這大概是

所有項(xiàng)目共同的特征），這種成本幾乎是無(wú)法同意的。

另一方面，在同一個(gè)軟件組織中，解決同樣的問(wèn)題有著不一致的

辦法。不一致的人有著不一致的編碼習(xí)慣、不一致的目錄組織方式、

不一致的類庫(kù)、不一致的框架。盡管我們并不反對(duì)同一問(wèn)題的不一致

解法，但是當(dāng)這種情況對(duì)項(xiàng)目的進(jìn)展起到負(fù)面的效果的時(shí)候，我們就

有必要來(lái)思考這個(gè)問(wèn)題了。

4、問(wèn)題

我們?nèi)绾卧谝恢滦耘c一致性帶來(lái)的成本之間做好平衡？我們?nèi)绾?/p>

保證不一致工件之間的一致性，又該如何保證項(xiàng)目中解決方法的一致

性。

5、方法

首先，我們應(yīng)該確信，一致性這個(gè)問(wèn)題并沒(méi)有標(biāo)準(zhǔn)的答案。不一

致的項(xiàng)目對(duì)一致性有著不一致的要求。關(guān)于要求嚴(yán)格、規(guī)模龐大、涉

及到一些重要領(lǐng)域的項(xiàng)目來(lái)說(shuō)，一致性的要求是極為嚴(yán)格的。而關(guān)于

一個(gè)小型的、較為無(wú)關(guān)緊要的項(xiàng)目來(lái)說(shuō)，一致性的要求就低了許多。

因此，與前面介紹的模式類似的，一致性的正確的答案只能夠從讀者

自己的項(xiàng)目中去尋找。而這里提供的，是尋找該項(xiàng)標(biāo)準(zhǔn)的建議。

我們先從后者一解決方法一致性入手。

在項(xiàng)目一開(kāi)始的時(shí)候，不要過(guò)分注意工件的修飾。比如，我們選

擇的用例模板要求每一個(gè)用例都需要包含6種元素，包含要緊角色、

級(jí)別、前置條件、要緊流程、備選流程、優(yōu)先級(jí)。并規(guī)定引用其它用

例的地方需要做出鏈接。但是在一開(kāi)始需求調(diào)研的時(shí)候就按照這種標(biāo)

準(zhǔn)完善用例將會(huì)提高成本，由于需求尚未穩(wěn)固，我們要緊的工作是盡

可能完整的收集用例，而不是把時(shí)間花費(fèi)在修飾用例上。因此一開(kāi)始

任何形式的用例描述都是同意的。你能夠使用幾句話來(lái)描述用例（事

實(shí)上，利用自然語(yǔ)言來(lái)描述用例有著圖形無(wú)法比擬的優(yōu)勢(shì)），并用著

重號(hào)標(biāo)記出其中可能與其它用例有關(guān)聯(lián)的詞匯。這樣就已經(jīng)足夠了，

修飾的工作能夠等到下一步來(lái)做。其它的工件也是一樣的。這時(shí)候的

一致性的要求并不十分嚴(yán)格。

因此，我們應(yīng)該根據(jù)項(xiàng)目進(jìn)行的不一致時(shí)期來(lái)保證工件的一致

性。比如，在實(shí)現(xiàn)階段的初期，設(shè)計(jì)尚未定性，花費(fèi)大量的時(shí)間在設(shè)

計(jì)文檔上就沒(méi)有什么必要，只需要準(zhǔn)備一份草稿，在設(shè)計(jì)的時(shí)候隨手

記錄下設(shè)計(jì)思路就能夠了。注意，不要不做任何記錄，人的經(jīng)歷是最

不可靠的，過(guò)目不忘只出現(xiàn)在小說(shuō)中。而當(dāng)項(xiàng)目逐步成數(shù)的時(shí)候，我

們就能夠?yàn)槠渲谐墒斓脑O(shè)計(jì)進(jìn)行文檔化的工作了。這些能夠根據(jù)需要

公布給用戶，也能夠整合到構(gòu)架中。

再來(lái)看第一個(gè)問(wèn)題，如何保證不一致工件之間的一致性。

同時(shí)保護(hù)3個(gè)工件的工作量,要比同時(shí)保護(hù)10個(gè)工件的工作量

小的多。因此，我們應(yīng)該盡可能的減少在每個(gè)關(guān)鍵點(diǎn)中需要保證一致

性的工件數(shù)量。同時(shí)，我們需要區(qū)分，哪一些工件屬于務(wù)必保持一致

性的工件，什么屬于不需要隨時(shí)更新的工件。比如，我們?cè)谛枨蠓治?/p>

中使用了CRC卡片，但是它的要緊目的是為了順利的進(jìn)行溝通，并得

到基本的分析類。這樣的工件，保持它的一致性并沒(méi)有太大的意義。

這種思路類似于CMM中的KPI的思路，從軟件開(kāi)發(fā)過(guò)程中找出關(guān)鍵的

工件，把有限的力量投入到保持這些關(guān)鍵工件的一致性上。盡管一致

性狂熱者未必認(rèn)同這種做法，但是關(guān)于一個(gè)軟件組織來(lái)說(shuō)，最重要的

是在有限的資源下的盡量提高軟件開(kāi)發(fā)能力。

另一種工具是版本操縱系統(tǒng)，是否使用版本操縱系統(tǒng)與項(xiàng)目大小

無(wú)關(guān)。再小的項(xiàng)目同樣存在著版本問(wèn)題，只是嚴(yán)重程度不一致而已。

因此將工件納入到版本操縱系統(tǒng)中來(lái)是較好的做法。關(guān)于小型的項(xiàng)目

而言，并沒(méi)有必要限制權(quán)限，但關(guān)于大一些的項(xiàng)目權(quán)限操縱就有必要

了。

一致性的組織保證

首先，假如不進(jìn)行任何的管理，項(xiàng)目一定是不一致的。這與人的

基因有關(guān)系。因此我們需要為一致性制定專門的人選。比如，需求的

一致性應(yīng)該由架構(gòu)師與領(lǐng)域?qū)＜邑?fù)責(zé)，模型的一致性由開(kāi)發(fā)人員負(fù)

責(zé)。但是最終需要一位總的負(fù)責(zé)人，他負(fù)責(zé)所有工件的一致性，包含

技術(shù)與領(lǐng)域兩方面，并決定是否將項(xiàng)目中的經(jīng)驗(yàn)并入構(gòu)架中。

不要讓一致性為難你的開(kāi)發(fā)人員。一致性是很容易濫用的，因此

請(qǐng)確保正確的使用了它們。比如，制定縮進(jìn)或者留白之類的一致性標(biāo)

準(zhǔn)并沒(méi)有太大的意義，由于它的成本遠(yuǎn)遠(yuǎn)超出了它的意義，同時(shí)會(huì)遭

到開(kāi)發(fā)人員的嚴(yán)重反對(duì)。另外的例子包含過(guò)于嚴(yán)苛的編碼規(guī)則、與模

式的濫用。這些都是經(jīng)常會(huì)犯的錯(cuò)誤。它并不可能帶來(lái)生產(chǎn)率的上升，

只會(huì)另開(kāi)發(fā)人員反感。避免它們的辦法是，在制定一致性規(guī)則之前，

先思考，該條規(guī)則的成本是否大過(guò)它的利益，開(kāi)發(fā)人員是否愿意同意。

一旦定義了一致性規(guī)則之后，就需要進(jìn)行培訓(xùn)。最好是通過(guò)例子

來(lái)開(kāi)始。比如，教授新的模式。假如你進(jìn)行類似的培訓(xùn)，你就會(huì)發(fā)現(xiàn),

把正式的培訓(xùn)與非正式的指導(dǎo)相結(jié)合是很好的做法。因此，我們往往

習(xí)慣把培訓(xùn)課程分為理論培訓(xùn)與實(shí)踐兩個(gè)部分。實(shí)踐能夠安排在課程

結(jié)束就開(kāi)始，也能夠安排在項(xiàng)目進(jìn)行中。

最后，一致性規(guī)則需要在整個(gè)開(kāi)發(fā)過(guò)程中被不擇不扣的執(zhí)行。這

是務(wù)必的。此外，治需要評(píng)估一致性規(guī)則的實(shí)際運(yùn)作情況，假如有不

充分或者是不完善的情況，則需要改進(jìn)它c(diǎn)假如效果不佳，則要考慮

廢止該規(guī)則。

6、小結(jié)

?使用構(gòu)架來(lái)保證大原則的一致性。

?在情況未確定之前，工件能夠是不一致的，但是在關(guān)鍵點(diǎn)時(shí)，

工件務(wù)必是一致的。

?盡量減少需要保持一致性的工件數(shù)量。

.使用工具來(lái)保護(hù)一致性。

.指定一致性的負(fù)責(zé)人。

?一致性規(guī)則務(wù)必合理。

?嚴(yán)格執(zhí)行一致性，并根據(jù)實(shí)際情況改進(jìn)一致性規(guī)則。

軟件工程需要在科學(xué)與藝術(shù)之間求得權(quán)衡，科學(xué)的一面包含了軟

件開(kāi)發(fā)規(guī)范、準(zhǔn)則、實(shí)踐、過(guò)程、方法；而藝術(shù)的一面則囊括了人員

的激勵(lì)、協(xié)調(diào)，組織的設(shè)計(jì)等因素。因此我們需要審視我們的規(guī)則、

過(guò)程、方法，它們是否能夠發(fā)揮出人的創(chuàng)新性？或者是它是否足以約

束人的行為？

1、意圖

對(duì)開(kāi)發(fā)人員的行為進(jìn)行約束是必要的，但同時(shí)卻限制了開(kāi)發(fā)人員

的創(chuàng)意。我們?nèi)绾卧谶@兩的極端之間取得平衡呢？

2、示例

成達(dá)公司在以往的項(xiàng)目開(kāi)發(fā)中，通常都不限制開(kāi)發(fā)人員的行為，

公司中開(kāi)發(fā)人員都有各自的編碼習(xí)慣，使用不一致的開(kāi)發(fā)工具，更不

用說(shuō)遵循什么開(kāi)發(fā)過(guò)程了。因此一旦有人員離職，接手的人員往往都

需要花費(fèi)大力氣來(lái)熟悉原先的系統(tǒng)，由于原先的人員幾乎沒(méi)有留下文

檔，或者是僅有一些舊的、不能使用的文檔。公司中也有軟件人員向

管理者提出過(guò)這方面的建議。但是由于軟件開(kāi)發(fā)并不是公司的要緊盈

利機(jī)構(gòu)，公司不太注重這件事c因此這種情況就一直保持下去c由于

公司中的軟件人員大多數(shù)都有著多年的開(kāi)發(fā)經(jīng)驗(yàn)，因此日常的運(yùn)作也

算是基本正常。從今年開(kāi)始，情況發(fā)生了改變，由于經(jīng)營(yíng)策略的改變,

公司換了一位老總，新老總對(duì)軟件部門非常重視，并投入資金，為軟

件部分引入了一套嚴(yán)格的規(guī)定，制定了統(tǒng)一的編碼規(guī)則、開(kāi)發(fā)環(huán)境，

嚴(yán)格的作息制度、匯報(bào)機(jī)制。有位員工這樣形容新過(guò)程，”就差沒(méi)有

制定上洗手間的時(shí)間了”。過(guò)程實(shí)施以來(lái)，員工怨聲不斷，由于個(gè)人

原先熟悉的開(kāi)發(fā)方式被打破，軟件開(kāi)發(fā)速度大大降低?？蛻舻耐对V也

明顯增加，甚至出現(xiàn)了項(xiàng)目中止的情況。過(guò)程實(shí)施6個(gè)月之后，發(fā)生

了3位資深的開(kāi)發(fā)人員離職的事件。最后，管理層不得不廢止新過(guò)程,

回到原先的開(kāi)發(fā)方式上去。

3、分析

開(kāi)發(fā)過(guò)程有兩種極端。我們能夠看看下面的兩種情況，你更愿意

在哪一種環(huán)境中工作。

項(xiàng)目組的三個(gè)程序員分別開(kāi)發(fā)項(xiàng)目的三個(gè)模塊。需求僅僅持續(xù)了

3天的時(shí)間。原定干劃是1周，但是由于項(xiàng)目甲方人手緊缺，調(diào)走了

需求調(diào)研的領(lǐng)域?qū)＜摇Ｈ齻€(gè)程序員悶頭開(kāi)發(fā)，彼此隔絕。每位程序員

都有自己的類庫(kù)與開(kāi)發(fā)包。沒(méi)有文檔，沒(méi)有測(cè)試用例。突然，程序員

甲喊道，”昨天我放在這里的需求說(shuō)明書呢？就是那張上頭有腳印的

打印紙。”界面開(kāi)發(fā)一半之后，用戶發(fā)現(xiàn)大概不一致模塊的界面相差

極大，按鈕的位置、菜單風(fēng)格、窗口布局，沒(méi)有一處相同的。更為糟

糕的是，大概程序員對(duì)用戶需求的懂得又錯(cuò)了。

程序員乙正在嘀嘀咕咕的修改他的代碼，由于架構(gòu)師在檢查了他

的代碼之后，指出？100多處與標(biāo)準(zhǔn)規(guī)則不一致的地方。包含變量命

名、注釋規(guī)則等等?！盁┧懒耍?程序員丙伸了個(gè)懶腰，他正在修飾他

的設(shè)計(jì)類圖。上次也是這樣，模型已經(jīng)畫的盡善盡美了，結(jié)果又由于

設(shè)計(jì)發(fā)生變化不得不重來(lái)一次。看來(lái)今天有沒(méi)什么時(shí)間寫代碼了。項(xiàng)

目經(jīng)理正在審查昨天各個(gè)開(kāi)發(fā)小組提交上來(lái)的文檔，”這幾份文檔的

格式都有問(wèn)題！"他皺了皺眉頭，看來(lái)在下午的例會(huì)上，他還要著重

強(qiáng)調(diào)統(tǒng)一規(guī)格的問(wèn)題。

3、問(wèn)題

能夠看到，上述的兩種情形正是我們的模式名稱的后半部分所描

述的：混亂與死板。那么，我們?nèi)绾芜_(dá)成模式名稱的前半部分一活躍

而且嚴(yán)謹(jǐn)呢？

4、方法

這又是一個(gè)需要權(quán)衡的問(wèn)題。正是這種問(wèn)題讓人頭疼不已。造成

軟件過(guò)程無(wú)效或者束縛開(kāi)發(fā)人員的結(jié)果有兩種不一致來(lái)源的因素。一

是在過(guò)程選擇與創(chuàng)建的時(shí)候，我們忽略了一些問(wèn)題，一種是過(guò)程實(shí)施

后的操縱上我們沒(méi)有認(rèn)確實(shí)思考。

軟件過(guò)程的迷思

很明顯的，上面所討論的兩種極端都不是優(yōu)秀的軟件過(guò)程。

然而，就像我們看寓言故事一樣，在取笑寓言故事中的人物的時(shí)候,

可曾想過(guò)自己也犯過(guò)類似的錯(cuò)誤，只是輕重程度不一致而已。盡管

我們不可能犯上例中所有的錯(cuò)誤，但是確實(shí)會(huì)出現(xiàn)其中的一些情形。

那么，我們?cè)诮④浖^(guò)程的時(shí)候，如何防止出現(xiàn)上述的一些情境

呢？

以我們自己為例子。在建立過(guò)程的時(shí)候，我們選擇是以RUP為基

礎(chǔ)。為什么不選擇XP之類的敏捷方法呢？原因有二：i)敏捷方法的

實(shí)踐很優(yōu)秀，但是作為完整的過(guò)程，它仍然有其不充分的地方。ii)XP

中有很多優(yōu)秀的實(shí)踐，但另一些我們并不完全贊同。在選擇了RUP之

后，為了保證過(guò)程的靈活，我們刪減了大量的活動(dòng)與工件，僅保留了

一些關(guān)鍵的。但是我們清晰，假如現(xiàn)有的團(tuán)隊(duì)規(guī)模發(fā)生變化，刪除的

這些活動(dòng)與工件可能需要重新添加到過(guò)程中來(lái)。此外，我們引入了

XP中的一些優(yōu)秀的實(shí)踐。比如測(cè)試優(yōu)先、重構(gòu)與結(jié)對(duì)編程。關(guān)于結(jié)

對(duì)編程這項(xiàng)實(shí)踐，我們沒(méi)有完全采納XP的建議，而是在一些關(guān)鍵的

活動(dòng)上，比如指導(dǎo)、模塊設(shè)計(jì)、單元測(cè)試，使用了結(jié)對(duì)編程實(shí)踐。

不要過(guò)于在乎你的過(guò)程過(guò)輕或者過(guò)重，只需要關(guān)注它是否合適，

開(kāi)發(fā)人員能否同意,新的過(guò)程是否要求開(kāi)發(fā)人員改變?cè)鹊牧?xí)慣，而

他們的反應(yīng)如何？很多時(shí)候，正是對(duì)舊習(xí)慣的挑戰(zhàn)導(dǎo)致了開(kāi)發(fā)過(guò)程的

失敗或者不順利。這里需要非常小心的處理。

在引入軟件過(guò)程的時(shí)候，不要花費(fèi)大量的時(shí)間來(lái)編寫描述過(guò)程的

文檔，盡量利用現(xiàn)成的。有編寫文檔的時(shí)間，倒不如用來(lái)對(duì)開(kāi)發(fā)人員

進(jìn)行培訓(xùn)，并獲取他們的支持.在實(shí)踐中，我們發(fā)現(xiàn)，人們往往不可

能去真正閱讀并懂得大量的文檔。文檔過(guò)多也將使得工作失去重點(diǎn)。

從一些比較簡(jiǎn)單的、容易見(jiàn)效的、最好是能夠結(jié)合現(xiàn)有的一些流行技

術(shù)的（程序員們都喜歡）。比如，使用用例技術(shù)來(lái)改進(jìn)需求、使用

UML來(lái)改進(jìn)設(shè)計(jì)。這樣做的好處還在于，這些技術(shù)往往都有較多的資

料，利用這些資料能夠節(jié)約編寫指南的時(shí)間。

?在關(guān)鍵的檢查點(diǎn)上保證文檔的完整性與一致性。上文中我們提

到了檢查點(diǎn)的概念。就像在需求復(fù)審這個(gè)檢查點(diǎn)上，我們需要

保證需求模型完整的再現(xiàn)了用戶或者領(lǐng)域?qū)＜业乃悸?，而在設(shè)

計(jì)復(fù)審這個(gè)檢查點(diǎn)上，我們則需要保證設(shè)計(jì)模型與需求模型的

一致性，并確保開(kāi)發(fā)人員與設(shè)計(jì)人員都同意當(dāng)前的設(shè)計(jì)模型。

只在檢查點(diǎn)上同步文檔能夠大大減少文檔的負(fù)擔(dān)，但文檔需要

進(jìn)行同步的檢查點(diǎn)則要好好的考慮。比如，幫助文件需要同步

的檢查點(diǎn)，界面原型需要同步的檢查點(diǎn)。

總之，小心的處理文檔，不要讓文檔成為開(kāi)發(fā)人員怒氣的焦點(diǎn)，

不要讓編寫文檔變成一種應(yīng)付了事的工作。這樣的話，既花費(fèi)了精力，

又得不到應(yīng)有的效果。

最后一點(diǎn)，千萬(wàn)不要相信過(guò)程能夠解決一切。"我們使用了最先

進(jìn)的過(guò)程，我們一定能夠成功的"這種話無(wú)異于癡人說(shuō)夢(mèng)。開(kāi)發(fā)軟件

的是人，而不是過(guò)程。好的過(guò)程關(guān)于軟件的成功來(lái)說(shuō)，只是一個(gè)必要

條件，而不是充分備件。永遠(yuǎn)依靠你的開(kāi)發(fā)人員。當(dāng)人的行為與過(guò)程

沖突或者不一致的時(shí)候，想想過(guò)程的目的，再做最后的定論C

5、小結(jié)

?在創(chuàng)建軟件過(guò)程時(shí)，從現(xiàn)有的軟件過(guò)程中選擇一個(gè)適合自己的。

-水無(wú)常形，軟件過(guò)程也是一樣，確保它隨著時(shí)勢(shì)而變。

?注意引入軟件過(guò)程的開(kāi)始階段，讓開(kāi)發(fā)人員參與到軟件過(guò)程中

來(lái)。

?重點(diǎn)關(guān)注檢查點(diǎn)。

?保持文檔活動(dòng)的敏捷性。

.過(guò)程不是仙丹，人才是。

軟件過(guò)程的改進(jìn)是一個(gè)長(zhǎng)期的過(guò)程，屬于長(zhǎng)期的利益。假如長(zhǎng)期

利益與短期利益相沖突的時(shí)候我們應(yīng)該如何處理。我們有什么辦法來(lái)

令短期利益與長(zhǎng)期利益結(jié)合起來(lái)呢？

1、意圖

權(quán)衡短期利益與長(zhǎng)期利益。

2、示例

金商軟件是一家專門針對(duì)小型企業(yè)銷售軟件產(chǎn)品與定制開(kāi)發(fā)的

公司。他們銷售的軟件來(lái)自于國(guó)內(nèi)的一家知名軟件廠商。而公司內(nèi)部

的軟件人員要緊從事定制開(kāi)發(fā)，一方面是滿足用戶的一些特殊需要，

另一方面是為了進(jìn)展自己的軟件開(kāi)發(fā)力量，以圖日后開(kāi)發(fā)出自己的產(chǎn)

品。這種策略剛實(shí)施了半年的時(shí)間，目前公司的開(kāi)發(fā)人員只有5個(gè)人。

由于公司的銷售能力很強(qiáng)，因此公司總是能夠得到大量的訂單。由于

公司目前已經(jīng)擁有開(kāi)發(fā)力量，因此得到的訂單也不像從前，以產(chǎn)品為

主，定制為輔。而是一些完整的開(kāi)發(fā)項(xiàng)目。從10月份開(kāi)始，公司已

經(jīng)簽了4個(gè)項(xiàng)目，按照公司的習(xí)慣，通常都承諾在3個(gè)月內(nèi)完成項(xiàng)目。

但是根據(jù)軟件部分的估算，目前的任務(wù)，大概需要60個(gè)人月的時(shí)間。

到了n月，開(kāi)發(fā)部的所有人員已經(jīng)連續(xù)加班1個(gè)月了。其中2個(gè)項(xiàng)

目由于增加需求，同意把項(xiàng)目的開(kāi)發(fā)周期延長(zhǎng)一個(gè)月，但是與60個(gè)

人月的工作量比起來(lái)，這點(diǎn)時(shí)間大概是杯水車薪。在時(shí)間的強(qiáng)大壓力

之下，開(kāi)發(fā)人員不得不犧牲軟件質(zhì)量，而軟件的最后完工看起來(lái)是那

么的遙不可及。

3、分析

自從加入到面向?qū)ο箝_(kāi)發(fā)地陣營(yíng)以來(lái)，我們深為這門開(kāi)發(fā)藝術(shù)所

感動(dòng)。編碼工作在面向?qū)ο笏枷氲闹笇?dǎo)下顯得那么具有美感。以往過(guò)

程式編碼失控之后的那種無(wú)力感再也找不到了。面向?qū)ο髱Ыo我們的

是極大限度的重用性，當(dāng)然，我們需要付出前期投入的成本。從學(xué)習(xí)

面向?qū)ο笠詠?lái)，我們學(xué)會(huì)了使用一種抽象的方式看待世界，思考問(wèn)題。

有些時(shí)候，我們同一些仍然保持傳統(tǒng)編程習(xí)慣的軟件公司交流時(shí)，我

們發(fā)現(xiàn)大概面向?qū)ο蟛](méi)有表達(dá)出太大的優(yōu)勢(shì)：

"面向?qū)ο蠹夹g(shù)能夠極大的重用現(xiàn)有的構(gòu)架，大大提高開(kāi)發(fā)速度。”

”我們現(xiàn)在通過(guò)增加人手與加班的方式，也能夠很快的完成一個(gè)項(xiàng)

目?！?/p>

”面向?qū)ο蠹夹g(shù)能夠減少軟件的保護(hù)成本?！?/p>

"通常我們會(huì)指定一些開(kāi)發(fā)新手來(lái)保護(hù)公司以往的項(xiàng)目，這方面的

成本并不高。”

”面向?qū)ο竽軌虿粩嗟姆e存項(xiàng)目經(jīng)驗(yàn)，為后續(xù)的項(xiàng)目開(kāi)發(fā)提供保證。

II

”通過(guò)雇傭有經(jīng)驗(yàn)的開(kāi)發(fā)人員，我們能夠直接獲得開(kāi)發(fā)經(jīng)驗(yàn)，而不

用自己積存”

"面向?qū)ο笫俏磥?lái)軟件開(kāi)發(fā)的主流。"

”保證項(xiàng)目及時(shí)完成是管理層最關(guān)心的，等到市場(chǎng)上的面向?qū)ο蟪?/p>

序員足夠多之后我們?cè)偈褂妹嫦驅(qū)ο蟀?。?/p>

"此外，現(xiàn)在使用面向?qū)ο螅藛T需要全新的培訓(xùn)，我們沒(méi)有多余

的人手；由于沒(méi)有經(jīng)驗(yàn)，直接把面向?qū)ο笥糜陧?xiàng)目實(shí)施存在風(fēng)險(xiǎn)，而

我們的項(xiàng)目時(shí)間都太少了”

這一段對(duì)話點(diǎn)出了面向?qū)ο蠹夹g(shù)的困惑，但也反映了軟件開(kāi)發(fā)中

短期利益與長(zhǎng)期利益的沖突。

4、問(wèn)題

如何在軟件開(kāi)發(fā)的短期利益與長(zhǎng)期利益中尋求平衡點(diǎn)？

5、方法

面向?qū)ο蟮拿运?/p>

我們的不明白是從面向?qū)ο箝_(kāi)始的。歸結(jié)其原因，是我們并沒(méi)有

真正的認(rèn)識(shí)面向?qū)ο蟆?/p>

"面向?qū)ο蠓犀F(xiàn)實(shí)世界的特性，因此會(huì)更加簡(jiǎn)單。”

"我們決定從這個(gè)項(xiàng)目開(kāi)始使用面向?qū)ο蠹夹g(shù)，并安排了為期2周

的學(xué)習(xí)時(shí)間?！?/p>

”由于使用了先進(jìn)的面向?qū)ο蠹夹g(shù)，我們把開(kāi)發(fā)周期縮短1/3。”

假如你對(duì)面向?qū)ο笥猩鲜龅亩玫脑?，說(shuō)明你對(duì)面向?qū)ο蠹夹g(shù)的

懂得存在誤區(qū)。首先，面向?qū)ο笈c面向過(guò)程的不一致在于思維方式的

根本不一致，因此，轉(zhuǎn)向面向?qū)ο蠹夹g(shù)決不是一個(gè)一蹴而就的過(guò)程，

而是需要不斷的學(xué)習(xí)，不斷的磨練。假如需要為這個(gè)學(xué)習(xí)過(guò)程制定一

個(gè)時(shí)間的話，我想也應(yīng)該是在8?14個(gè)月之間。其次，在剛開(kāi)始使用

面向?qū)ο蠹夹g(shù)時(shí)，并不能夠節(jié)約項(xiàng)目的開(kāi)發(fā)時(shí)間，相反，由于學(xué)習(xí)與

嘗試面向?qū)ο蠹夹g(shù)的需要，項(xiàng)目的所需時(shí)間會(huì)大幅度延長(zhǎng)。面向?qū)ο?/p>

技術(shù)的威力在通過(guò)一段時(shí)間的積存之后會(huì)變慢的顯露出來(lái)，你會(huì)發(fā)現(xiàn)

一個(gè)新的軟件只需要對(duì)現(xiàn)有的類進(jìn)行重用，編寫少量的代碼，甚至使

用代碼生成器就能夠完成。這使得軟件的開(kāi)發(fā)成本大幅度的降低。這

個(gè)時(shí)候，軟件開(kāi)發(fā)將會(huì)進(jìn)入良性循環(huán)的周期。

為什么面向?qū)ο蠹夹g(shù)會(huì)有如此大的威力呢？原因在于面向?qū)ο?/p>

的抽象思維。

熟悉了面向?qū)ο蟮闹R(shí)之后，我們發(fā)現(xiàn)事實(shí)上面向?qū)ο蟮囊o威

力是它使用一種特定的方法，將一些不斷重復(fù)的情況簡(jiǎn)化了。問(wèn)題在

于，要讓軟件組織學(xué)會(huì)使用這種方式是需要代價(jià)的。那么，你是否愿

意付出這種代價(jià)？今天付出1塊錢，明天能夠收回10塊錢的情況每

個(gè)人都會(huì)做。但是讓你每天投入10000塊錢，堅(jiān)持2年，這樣你會(huì)在

未來(lái)獲得10倍的回報(bào)。這種情況就未必會(huì)有人做了。研究面向?qū)ο?/p>

技術(shù)，進(jìn)展軟件組織的技術(shù)框架需要很大的前期投入，而效益卻是慢

慢顯現(xiàn)的。這就造成了短期利益與長(zhǎng)期利益的矛盾。事實(shí)上，除了面

向?qū)ο蠹夹g(shù)之外，軟件組織中還存在很多同種性質(zhì)的矛盾：

?所有人都明白項(xiàng)目管理的必要性，甚至言必談項(xiàng)目管理，但是

真正按照項(xiàng)目關(guān)聯(lián)方式執(zhí)行的又有多少人呢？

?軟件質(zhì)量是軟件組織最看重的，但是由于人員與時(shí)間的壓力而

犧牲質(zhì)量的案例多如牛毛。

?計(jì)劃制定與執(zhí)行是軟件過(guò)程中最核心的部分，但是計(jì)劃趕不上

變化也是目前最流行的口頭禪。

由于我們要緊討論的仍是經(jīng)驗(yàn)，關(guān)于項(xiàng)目管理的原理、案例、數(shù)

據(jù)的資料有很多書籍都有介紹，因此我們就不用再次的重復(fù)它們了。

而我們的出發(fā)點(diǎn)，仍然是圍繞著前述的核心矛盾，介紹一些實(shí)踐。這

些實(shí)踐并不需要很大的成本，但是確實(shí)能夠起到很好的效果，當(dāng)然，

它們最能夠發(fā)揮作用的前提條件是「堅(jiān)持”。從下面的介紹來(lái)看，其

目的都是為了補(bǔ)充或者