隱喻在項目管理中的應(yīng)用

1、隱喻在項目管理中的應(yīng)用隱喻是極限編程方法學中的重要概念。 但隱喻比較晦澀， 它表示什么意思？在項目中如何應(yīng)用？這值得我們深入探討。XP 項目管理流程圖。 XP 的分析設(shè)計比起 RUP 會少許多， 因為每一次迭代的粒度不太大， 每個階段的分析與設(shè)計相對簡潔 一些，并且在迭代的過程中可以逐步改進。最近閱讀了代碼大全其中的一章“隱喻” ，對隱喻在項 目管理中的應(yīng)用有了一定體會： 它能夠促進分析人員、 設(shè)計人員、 開發(fā)人員之間的溝通與對項目業(yè)務(wù)的理解。項目規(guī)模打算規(guī)劃 首先，軟件工程是從建筑領(lǐng)域引申進來的， “設(shè)計模式”便 是起源于建筑大師亞歷山大所寫的建筑的永恒之道一書。我們可以把一個開發(fā)項目比方成

2、建筑房子。 很明顯， 建筑摩 天大廈和建筑一層樓的預備工作是截然不同的。 建筑摩天大廈需 要前期經(jīng)過特別認真的規(guī)劃， 比如成本核算、 時間核算、設(shè)計模 型、設(shè)計圖紙等。因為假如前期不規(guī)劃好， 我們不可能建到一半 推倒重建，它的成本太高了。 這就是我們軟件工程里面 “瀑布模 型”的由來。 其實這和軟件開發(fā)項目是一一對應(yīng)的， 項目也要經(jīng) 過類似的成本時間估算、分析模型、設(shè)計模型這些過程。而建筑一層樓就不同了， 因為它涉及的成本更低， 前期所做的規(guī)劃確定簡潔一些。 但不管如何，必要的成本核算、 時間核算、 設(shè)計模型、設(shè)計圖紙等前期規(guī)劃還是需要的。那么再更進一步， 假如想建一個狗窩， 我們會去做認真的

3、規(guī)劃嗎？我想不會。 在項 目開發(fā)中， 我們同樣必需依據(jù)項目的規(guī)模大小， 去衡量我們所需 要做的前期規(guī)劃的具體程度。其次，無論建筑什么房子摩天大廈也好，一棟樓房也好， 在前期核算、設(shè)計等預備工作完成以后，必需先打地基，只有扎 實的地基，才能支撐起整棟房子。 程序開發(fā)也同樣如此。在編碼 構(gòu)建階段開頭的時候，我們必需在 CVS 上先搭建好整個開發(fā)環(huán) 境，確定整個系統(tǒng)的代碼目錄結(jié)構(gòu)，確定接口、類、方法、參數(shù) 的名稱以及它們之間的交互關(guān)系。假如采用 UML 統(tǒng)一建模語言 來描述，設(shè)計階段必需產(chǎn)生包關(guān)系圖、 類關(guān)系圖這兩種制品。 我 們在編碼初始階段必需依據(jù)這兩種制品產(chǎn)生相應(yīng)的代碼骨架， 為 接下來的構(gòu)建

4、打下堅實的基礎(chǔ)。 我們以前開發(fā)的時候就吃過這樣 的虧，在設(shè)計階段和編碼初始階段，沒有定義好這些程序架構(gòu)， 先由各程序員自行定義， 后來重新定義的時候要耗費大量的人力 物力進行代碼遷移。 因此無論是建房子還是程序開發(fā)， 打地基都 是相當重要的。再次，建筑房子的時候，經(jīng)過前面所說的核算、設(shè)計、打地 基，接下來會一層一層地建筑房子， 建筑每一層之前我們可能會 進一步細化、 優(yōu)化這一層的設(shè)計藍圖。 這個過程就類似于軟件開 發(fā)過程的迭代開發(fā)， 先集中精力對若干個特征或功能點進行具體 設(shè)計和代碼構(gòu)建。 這次開發(fā)完成以后， 再過渡到另外的若干個功能點，形成一次一次的迭代。迭代粒度的奧秘從上面可以看到， 迭代

5、對軟件開發(fā)來講是特別重要的， 其實 程序算法中的“分治法”也是這個道理。毫無疑問，RUP（ Rational Unified Process ， 統(tǒng) 一 軟 件 開 發(fā) 過 程 ） 和 XP （ eXtreme Programming ，極限編程）都是強調(diào)迭代的，但為什么 XP 更 輕量級、更加不注意具體的分析與設(shè)計，而 RUP 更加重量級， 需要各種文檔和具體的分析設(shè)計呢？同樣是建筑一棟摩天大廈，在 RUP 開發(fā)方法學里面，它是 從一次建筑一層樓的粒度來進行迭代開發(fā)的， 因此每一次迭代仍 舊需要相對具體的分析與設(shè)計。而 XP 的方法則不同。它會以一 套房子或者以一個房間的粒度去建筑整棟摩天大

6、廈， 每一次迭代 開發(fā)的功能點不會太多， 因此所需要做的前期規(guī)劃自然要少得多。 軟件大師 Robert C.Martin 在他的機敏軟件開發(fā)原則、模 式與實踐中提到，XP抱負的一個迭代周期為 2周，每6次迭 代形成一個可發(fā)行版本。因此，迭代粒度的大小是 RUP 和 XP 本質(zhì)的區(qū)分之一。RUP 更適合大型的開發(fā)項目，因為針對每一個項目，從跨 越整個項目的廣度上來講， 它制定了九大規(guī)程， 每個規(guī)程對應(yīng)若 干個角色， 每個角色需要產(chǎn)生若干個制品； 從每一次迭代的深度 上來講， 它強調(diào)把項目開發(fā)分成若干次迭代， 每一次迭代都分成 初始階段、細化階段、 編碼構(gòu)建階段和移交用戶階段， 每一個階 段都強調(diào)

7、形成若干制品，都對應(yīng)多種不同的角色。NextPage初始階段要求生成項目計劃、風險評估、需求模型等制品， 這個階段基本不需要經(jīng)歷幾次階段本身的迭代； 細化階段主要進 行分析設(shè)計工作，需要生成分析模型、 設(shè)計模型、 迭代計劃等制 品，這個階段可以依據(jù)項目狀況進行13次小的迭代；編碼構(gòu)建階段主要是進行編碼， 需要生成測試計劃、 本次迭代的可運行 版本等制品，這個階段也可以依據(jù)項目狀況進行13 次小的迭代；移交用戶階段主要是進行測試并提交給用戶試用的階段， 需 要生成產(chǎn)品測試文檔、 用戶支持文檔等制品， 這個階段可能由于 性能測試不通過、出現(xiàn) bug 、用戶不滿足，會有 1 3 次小的迭 代。從上面

8、可以看到，假如要完全實現(xiàn) RUP 的項目管理流程相 當繁瑣。這是它的一個缺點。 但假如是大型項目， 比如一個項目 組超過 30 人，我們根據(jù) XP 的做法，更多地強調(diào)人與人之間的 溝通來代替 RUP 的各種制品和文檔，它的溝通成本可能會遠遠 高于撰寫各種制品和文檔的成本。 所以這種狀況下我們必需更多 地采用 RUP 的方式來進行項目組織管理。但假如一個比較小的項目組， XP 的開發(fā)方法學就比較適用。 國外某聞名研究機構(gòu)的研究數(shù)據(jù)表明， 假如一個開發(fā)團隊小于或 等于 12 人，團隊將能夠保證成員間充分的溝通。在開發(fā)過程中分析設(shè)計文檔特別重要， 但假如迭代的粒度足 夠細，比如， XP 創(chuàng)始人 Ke

9、nt Beck 研究認為，一個 15 人的項 目組其迭代粒度為 2 4 周比較合理，根據(jù)這么細的粒度，就像 前面講的建房子的隱喻一樣， 那么，我們所需要的前期預備工作，包括分析設(shè)計的工作量確定會大大削減在 XP 的“穿刺” 過程中， 假如根據(jù)現(xiàn)在采用的 RUP 的“用 例驅(qū)動原則” ，我們可以抽出里面對用戶具有足夠價值的若干個 用例形成第一次迭代的內(nèi)容。 因為該次迭代涉及到的業(yè)務(wù)規(guī)律相 對比較簡潔，開發(fā)人員可以更好地理解，因此在做分析設(shè)計時， 我們完全可以更加簡化各種文檔， 并通過迭代過程中人員之間的 良好溝通，“隱喻”的運用，在迭代中對簡化了的分析設(shè)計模型 的逐步修改，來削減編碼之前的工作量

10、。用例須正確和穩(wěn)定不過這里有兩個問題： 第一， 在每一次迭代期間， 我們必需 對所選擇的用例進行具體分析，盡量保證它的正確性。 代碼大 全中講到， IBM 、 HP 公司發(fā)表的研究文章表明，在需求階段 的一個缺陷沒有被發(fā)覺， 在設(shè)計階段的修復成本會是需求階段發(fā) 覺該缺陷的3倍，在構(gòu)建階段會是 510倍，在用戶移交階段 會是10100倍?？梢婋S著時間的推移，不正確的用例的修復 成本會越來越高。第二，迭代期間用例必需保持穩(wěn)定。 因為本次 迭代的計劃、 人員任務(wù)安排都是依據(jù)它來制定的， 迭代期間的用 例假如任意轉(zhuǎn)變， 就會使得計劃無法完成。 采用粗粒度的迭代無 法保證迭代期間用例的穩(wěn)定性， 因為需求

11、總會不斷轉(zhuǎn)變， 但細粒 度的迭代比如以兩周為周期的迭代則完全可以做到這一點。另外， 在迭代期間出于優(yōu)化程序結(jié)構(gòu)、 增加程序擴展性等目 的，設(shè)計模型應(yīng)當是允許修改的， 代碼是允許重構(gòu)的， 因為它對 我們迭代計劃的完成影響較小。學問庫 隱喻是讓項目參與人員都必需對一些抽象的概念理解全都， 也即我們常說的行業(yè)術(shù)語。 因為業(yè)務(wù)本身的術(shù)語開發(fā)人員不熟識， 軟件開發(fā)的術(shù)語客戶不理解， 因此要先明確雙方使用的隱喻， 避 免歧義。瀑布模型 (Waterfall Model) 是 Royce 在 1970 年提出的， 他把大型軟件開發(fā)分為分析與編程兩部分。像工廠流水線一樣， 把軟件開發(fā)過程分成各種工序， 并且每個工序可以依據(jù)軟件產(chǎn)品