隱喻在專案管理中的應用 隱喻是極限程式設計方法學中的重要概念。但隱喻比較晦澀，它表示什麼意思?在專案中如何應用?這值得我們深入**。
xp專案管理流程圖。xp的分析設計比起rup會少很多，因為每一次迭代的粒度不太大，每個階段的分析與設計相對簡單一些，並且在迭代的過程中可以逐步改進。
專案規模決定規劃
首先，軟體工程是從建築領域引申進來的，「設計模式」便是起源於建築大師亞歷山卓所寫的《建築的永恆之道》一書。
我們可以把乙個開發專案比喻成建造房子。很明顯，建造摩天大廈和建造一層樓的準備工作是截然不同的。建造摩天大廈需要前期經過非常仔細的規劃，比如成本核算、時間核算、設計模型、設計圖紙等。因為如果前期不規劃好，我們不可能建到一半推倒重建，它的成本太高了。這就是我們軟體工程裡面「瀑布模型」的由來。其實這和軟體開發專案是一一對應的，專案也要經過類似的成本時間估算、分析模型、設計模型這些過程。
而建造一層樓就不同了，因為它涉及的成本更低，前期所做的規劃肯定簡單一些。但不管如何，必要的成本核算、時間核算、設計模型、設計圖紙等前期規劃還是需要的。那麼再更進一步，如果想建乙個狗窩，我們會去做仔細的規劃嗎?我想不會。在專案開發中，我們同樣必須根據專案的規模大小，去衡量我們所需要做的前期規劃的詳細程度。
其次，無論建造什麼房子—摩天大廈也好，一棟樓房也好，在前期核算、設計等準備工作完成以後，必須先打地基，只有紮實的地基，才能支撐起整棟房子。程式開發也同樣如此。在編碼構建階段開始的時候，我們必須在cvs上先搭建好整個開發環境，確定整個系統的**目錄結構，確定介面、類、方法、引數的名稱以及它們之間的互動關係。如果採用uml統一建模語言來描述，設計階段必須產生包關係圖、類關係圖這兩種製品。我們在編碼初始階段必須根據這兩種製品產生相應的**骨架，為接下來的構建打下堅實的基礎。我們以前開發的時候就吃過這樣的虧，在設計階段和編碼初始階段，沒有定義好這些程式架構，先由各程式設計師自行定義，後來重新定義的時候要耗費大量的人力物力進行**遷移。因此無論是建房子還是程式開發，打地基都是相當重要的。
再次，建造房子的時候，經過前面所說的核算、設計、打地基，接下來會一層一層地建造房子，建造每一層之前我們可能會進一步細化、優化這一層的設計藍圖。這個過程就類似於軟體開發過程的迭代開發，先集中精力對若干個特徵或功能點進行詳細設計和**構建。這次開發完成以後，再過渡到另外的若干個功能點，形成一次一次的迭代。
迭代粒度的奧秘
從上面可以看到，迭代對軟體開發來講是非常重要的，其實程式演算法中的「分治法」也是這個道理。毫無疑問，rup(rational unified process，統一軟體開發過程)和xp(extreme programming，極限程式設計)都是強調迭代的，但為什麼xp更輕量級、更加不注重詳細的分析與設計，而rup更加重量級，需要各種文件和詳細的分析設計呢?
同樣是建造一棟摩天大廈，在rup開發方法學裡面，它是從一次建造一層樓的粒度來進行迭代開發的，因此每一次迭代仍然需要相對詳細的分析與設計。而xp的方法則不同。它會以一套房子或者以乙個房間的粒度去建造整棟摩天大廈，每一次迭代開發的功能點不會太多，因此所需要做的前期規劃自然要少得多。軟體大師robert c.martin在他的《敏捷軟體開發—原則、模式與實踐》中提到，xp理想的乙個迭代週期為2周，每6次迭代形成乙個可發行版本。因此，迭代粒度的大小是rup和xp本質的區別之一。
rup更適合大型的開發專案，因為針對每乙個專案，從跨越整個專案的廣度上來講，它制定了九大規程，每個規程對應若干個角色，每個角色需要產生若干個製品;從每一次迭代的深度上來講，它強調把專案開發分成若干次迭代，每一次迭代都分成初始階段、細化階段、編碼構建階段和移交使用者階段，每乙個階段都強調形成若干製品，都對應多種不同的角色。
初始階段要求生成專案計畫、風險評估、需求模型等製品，這個階段基本不需要經歷幾次階段本身的迭代;細化階段主要進行分析設計工作，需要生成分析模型、設計模型、迭代計畫等製品，這個階段可以根據專案情況進行1～3次小的迭代;編碼構建階段主要是進行編碼，需要生成測試計畫、本次迭代的可執行版本等製品，這個階段也可以根據專案情況進行1～3次小的迭代;移交使用者階段主要是進行測試並提交給使用者試用的階段，需要生成產品測試文件、使用者支援文件等製品，這個階段可能由於效能測試不通過、出現bug、使用者不滿意，會有1～3次小的迭代。
從上面可以看到，如果要完全實現rup的專案管理流程相當繁瑣。這是它的乙個缺點。但如果是大型專案，比如乙個專案組超過30人，我們按照xp的做法，更多地強調人與人之間的溝通來代替rup的各種製品和文件，它的溝通成本可能會遠遠高於撰寫各種製品和文件的成本。所以這種情況下我們必須更多地採用rup的方式來進行專案組織管理。
但如果乙個比較小的專案組，xp的開發方法學就比較適用。國外某著名研究機構的研究資料表明，如果乙個開發團隊小於或等於12人，團隊將能夠保證成員間充分的溝通。
在開發過程中分析設計文件非常重要，但如果迭代的粒度足夠細，比如，xp創始人kent beck研究認為，乙個15人的專案組其迭代粒度為2～4周比較合理，按照這麼細的粒度，就像前面講的建房子的隱喻一樣，那麼，我們所需要的前期準備工作，包括分析設計的工作量肯定會大大減少。
在xp的「穿刺」過程中，如果按照現在採用的rup的「用例驅動原則」，我們可以抽出裡面對使用者具有足夠價值的若干個用例形成第一次迭代的內容。因為該次迭代涉及到的業務邏輯相對比較簡單，開發人員可以更好地理解，因此在做分析設計時，我們完全可以更加簡化各種文件，並通過迭代過程中人員之間的良好溝通，「隱喻」的運用，在迭代中對簡化了的分析設計模型的逐步修改，來減少編碼之前的工作量。
用例須正確和穩定
不過這裡有兩個問題：第一，在每一次迭代期間，我們必須對所選擇的用例進行詳細分析，盡量保證它的正確性。《**大全》中講到，ibm、hp公司發表的研究文章表明，在需求階段的乙個缺陷沒有被發現，在設計階段的修復成本會是需求階段發現該缺陷的3倍，在構建階段會是5～10倍，在使用者移交階段會是10～100倍。可見隨著時間的推移，不正確的用例的修復成本會越來越高。第二，迭代期間用例必須保持穩定。因為本次迭代的計畫、人員任務分配都是根據它來制定的，迭代期間的用例如果任意改變，就會使得計畫無法完成。採用粗粒度的迭代無法保證迭代期間用例的穩定性，因為需求總會不斷改變，但細粒度的迭代比如以兩周為週期的迭代則完全可以做到這一點。
另外，在迭代期間出於優化程式結構、增強程式擴充套件性等目的，設計模型應該是允許修改的，**是允許重構的，因為它對我們迭代計畫的完成影響較小。
知識庫
隱喻是讓專案參與人員都必須對一些抽象的概念理解一致，也即我們常說的行業術語。因為業務本身的術語開發人員不熟悉，軟體開發的術語客戶不理解，因此要先明確雙方使用的隱喻，避免歧義。
瀑布模型(wate***ll model)是royce在2023年提出的，他把大型軟體開發分為分析與程式設計兩部分。像工廠流水線一樣，把軟體開發過程分成各種工序，並且每個工序可以根據軟體產品的規模、參與人員的多少，進一步細分成更細的工序。該模型非常符合軟體工程學的分層設計思路，所以成為軟體開發企業使用最多的開發模型。
敏捷軟體開發是乙個開發軟體的管理新模式，用來替代以檔案驅動開發的瀑布開發模式。它也稱輕量級開發方法。
極限程式設計要求加強開發者與使用者的溝通，讓客戶全面參與軟體的開發設計過程，保證變化的需求及時得到修正。
光環國際**pm圈子網
極限程式設計中的系統隱喻到底在隱喻什麼？
系統隱喻作為極限程式設計中的乙個工程實踐，就是用通俗易懂的語言將原本晦澀難懂的概念或開發過程闡發布來，達到 一說就懂，一聽就會 的效果。極限程式設計中的系統隱喻到底在隱喻什麼？隱喻就如同小分隊交接的暗號，只有同一陣營中的成員才能明白隱喻指代的是什麼。在電影 智取威虎山 中，解放軍楊子榮就利用土匪間通...
極限程式設計中的系統隱喻到底在隱喻什麼？
系統隱喻作為極限程式設計中的乙個工程實踐，就是用通俗易懂的語言將原本晦澀難懂的概念或開發過程闡發布來，達到 一說就懂，一聽就會 的效果。隱喻就如同小分隊交接的暗號，只有同一陣營中的成員才能明白隱喻指代的是什麼。在電影 智取威虎山 中，解放軍楊子榮就利用土匪間通用的黑話徹底打消了幾個匪徒的懷疑，順利地...
專案管理在LIMS系統實施中的應用
為了讓大家更詳細地了解lims，一起來看下專案管理在lims系統實施中的應用吧。隨著社會的發展，科技的進步，計算機的應用在社會各領域中都得到了普及，越來越多的人都感受到利用計算機進行各類管理的科學和便捷，認識到資訊管理系統對於管理工作的重要性。21世紀是資訊時代，最具發展潛力行業當屬資訊管理。乙個具...