【正文】 RUP 的貢獻和如何應(yīng)用 RUP。只是從項目管理和項目計劃的角度探討如何應(yīng)用 RUP 的迭代方法開發(fā)項目計劃。筆者在多個項目中應(yīng)用 RUP 進行軟件項目的開發(fā)和管理，在本文中將結(jié)合實踐闡述 RUP 迭代計劃的兩種開發(fā)方法，對于指導(dǎo)項目經(jīng)理裁剪和應(yīng)用 RUP 有實際的參考意義。本文還將與讀者分享在實際項目中應(yīng)用 RUP 如何開發(fā)迭代目標(biāo)、如何開發(fā)迭代計劃以及介紹了兩種不同的迭代計劃的模板參考示例。迭代計劃的特點迭代開發(fā)是 RUP 的核心思想，但是大家在剛開始使用 RUP 時你會發(fā)現(xiàn)這么多的并行工作流對項目管理同時也帶來很大挑戰(zhàn)和難度。因此使用 RUP 來完成項目，開發(fā)迭代計劃是實施的主要難點之一。迭代計劃的特點： 一個迭代是總體項目計劃的一個階段 需要明確的交付目標(biāo)（或可以運行的系統(tǒng)） 多個比較明確的角色的參與 可以串行也可以并行 體現(xiàn)了 RUP 架構(gòu)驅(qū)動、關(guān)注風(fēng)險的特點 實現(xiàn)快速交付，縮短大項目的交付周期 提高客戶參與度和項目的可視化 迭代計劃的開發(fā)考慮的因素： 總體項目計劃 項目規(guī)模大小、周期 需求明確程度和技術(shù)風(fēng)險 團隊成熟度和規(guī)模 項目所處的階段，在同一個項目的不同的階段可以采用不同的迭代計劃方法 迭代目標(biāo)的設(shè)置上面提到迭代計劃是實施 RUP 的難點之一，那么設(shè)置迭代目標(biāo)就是解決這個難點的重點。應(yīng)用 RUP 開發(fā)項目的迭代目標(biāo)主要是以項目開發(fā)周期中該迭代結(jié)束后所發(fā)布的交付物為主。 RUP 的迭代交付物通常以可以運行的系統(tǒng)，包括需求驗證原型，架構(gòu)驗證原型，功能驗證原型，測試系統(tǒng)，最終上線產(chǎn)品等。通常在項目前期的迭代中以發(fā)布原型系統(tǒng)和原型架構(gòu)為主，在項目的中期以發(fā)布的增量的功能Feature、業(yè)務(wù)模塊為主，而在項目的后期以增量業(yè)務(wù)功能、測試系統(tǒng)、非功能需求、缺陷修改為主。當(dāng)然，對于不同的項目類型，迭代的目標(biāo)的設(shè)置也不同，比如系統(tǒng)軟件產(chǎn)品的開發(fā)項目與應(yīng)用軟件開發(fā)項目，新軟件產(chǎn)品開發(fā)與軟件系統(tǒng)升級項目的差別就非常大。另外影響迭代目標(biāo)的另外一個重要因素是項目的需求和架構(gòu)的成熟程度，需求的明確程度，個性化需求和共性需求的比例，是影響項目風(fēng)險和迭代開發(fā)目標(biāo)的重要因素。還有就是采用的架構(gòu)和技術(shù)，也是影響的重要因素之一，因此迭代目標(biāo)的設(shè)置需要結(jié)合和考慮項目的總體目標(biāo)和采用的不同的架構(gòu)方法論，比如 IBM SO A項目的 SOMA（ServiceOriented Modeling and Architecture）面向服務(wù)的建模和架構(gòu)。概括來說，項目范圍或需求、架構(gòu)及決策、項目總體目標(biāo)是設(shè)置迭代目標(biāo)的重要的輸入。比如原型迭代開發(fā)的迭代目標(biāo)可以這樣定義： 開發(fā)架構(gòu)驗證框架 完成 2 個關(guān)鍵業(yè)務(wù)用例的實現(xiàn) 完成對架構(gòu)決策中 3 個關(guān)鍵技術(shù)的驗證實現(xiàn) 迭代計劃的開發(fā)方法RUP 的開發(fā)過程模型對項目管理和項目計劃提出了更高的要求，迭代計劃的好壞直接影響到項目目標(biāo)的實現(xiàn)，項目風(fēng)險和生產(chǎn)效率。如何更好地平衡和組織項目中眾多的并行活動和分配不同的項目專業(yè)角色，對項目管理提出了很大的挑戰(zhàn)。根據(jù)筆者在眾多的項目中應(yīng)用和實踐 RUP 中，總結(jié)出了兩種迭代計劃的開發(fā)方法。當(dāng)然這兩種方法并不是相互獨立和分開使用的。在不同的項目或者同一個項目的不同的階段，會交替使用甚至組合使用。下面就分別介紹這兩種方法的內(nèi)容、區(qū)別和適用情況。以時間為軸線的迭代計劃以時間為軸線的迭代計劃也是使用 RUP 開發(fā)整體項目計劃的主要的方法。根據(jù)項目的周期分為軟件開發(fā)的初始階段（Inception Phase）、精化階段（Elaboration Phase）、構(gòu)建階段（Construction Phase）和產(chǎn)品化階段（Transition Phase）。一般來說，這四個階段作為項目開發(fā)生命周期的主要里程碑，而細(xì)化后的迭代階段作為項目的二級里程碑。迭代計劃就是在每個里程碑下以時間順序設(shè)置不同的開發(fā)迭代以滿足里程碑的要求，達到里程碑的目標(biāo)。比如在初始階段一般有 12 個迭代周期，精化階段一般會有 24 個迭代周期。當(dāng)然迭代周期的個數(shù)要根據(jù)項目的類型、項目的規(guī)模和項目的特點不同來選擇。一般對于需求不明確的應(yīng)用軟件的開發(fā)項目，往往精化階段會有更多個迭代，而在產(chǎn)品移交階段的迭代會比較少。而對于軟件系統(tǒng)升級項目，往往在構(gòu)建階段的迭代會比較多。迭代周期（Duration）也是制定迭代目標(biāo)要考慮的因素，迭代周期也是根據(jù)項目整體的周期長短來確定合理的周期。一般來說 2 個周到 2 個月是比較合理的選擇。迭代周期的長短在同一個項目中是可以不同的，但是一般經(jīng)驗來看，相對固定的設(shè)置從項目管理和項目團隊的工作來看更適合，可以保持比較好的項目的工作節(jié)奏。確定迭代個數(shù)和迭代周期，往往與設(shè)置迭代目標(biāo)是相輔相成的。綜合考慮，在完成了迭代目標(biāo)、周期后，項目管理人員就可以開發(fā)項目的迭代計劃了。在以時間為軸線的迭代計劃一般會將多個工作流（Work Flows）集成在一個計劃中，項目團隊內(nèi)部有分工，但是不強調(diào)過于明顯的分工。這種方法一般適合項目早期、人員較少的情況下。 在項目的中后期，往往會結(jié)合以軟件工程流程和角色為軸線的計劃方法。 在這種方法下，對于一個迭代開發(fā)周期中，更像一個小的瀑布模型。 各個迭代之間沒有重合（Overlap），是串行執(zhí)行的。 具體例子參照如下：圖 1. 以時間為軸線的迭代計劃圖 2. 以時間為軸線的迭代計劃示例以軟件工程流程或者角色為軸線的迭代計劃當(dāng)項目規(guī)模比較大，團隊內(nèi)部角色分工比較明確的情況下，迭代開發(fā)的活動組織在一個計劃中往往難以管理和監(jiān)控。這個時候項目一般會采取以軟件工程流程或者開發(fā)角色為軸線來組織迭代開發(fā)計劃。根據(jù) RUP 的工程流程，項目中會有如下活動類型：業(yè)務(wù)建模，需求分析，分析設(shè)計，實施開發(fā)，測試，部署，配置和變更管理，項目管理，環(huán)境。理論上每種軟件工程流程都會對應(yīng)一個單獨的計劃，而且每個軟件工程流程會定義自己的迭代周期和迭代次數(shù)。當(dāng)然這個單獨的計劃只是相對獨立的，一方面要與總體的項目集成計劃保持一致，另一方面還要考慮與其他軟件工程流程的計劃的依賴關(guān)系。項目經(jīng)理的非常重要的職責(zé)之一就是識別和管理這些依賴關(guān)系，使之保證項目開發(fā)的順利進行。對于如上九種軟件工程流程，并不是一定要對應(yīng)九個單獨的子計劃，在一般的應(yīng)用軟件的開發(fā)項目中，一般根據(jù)角色的團隊的情況分為如下幾個單獨的計劃： 業(yè)務(wù)需求開發(fā)計劃 軟件設(shè)計計劃 軟件開發(fā)計劃 測試計劃 管理和集成計劃 軟件開發(fā)計劃可能還會存在多個，比如一個項目有多個子系統(tǒng)的開發(fā)，開發(fā)團隊比較大，一般又會分為子系統(tǒng) 1 開發(fā)計劃、子系統(tǒng) 2 開發(fā)計劃，分別組織實施。在這種情況下各個迭代計劃之間是有重合（Overlap）的，項目計劃活動的執(zhí)行是并行進行的。具體的例子如下所示：圖 3. 以軟件工程流程為軸線的迭代計劃圖 4. 以軟件工程流程為軸線的迭代計劃示例回頁首兩種計劃方法的總結(jié)下表對比兩種方法，總結(jié)不同的方法在不同的適用場景下的適用情況，作為項目管理人員選擇和采用的依據(jù)：表 1. 兩種方法的對照總結(jié)兩種方法的對照總結(jié)適合情景 時間為軸線的迭代計劃 工作流程和角色為軸線的迭代計劃 適合的項目規(guī)模 都可以 全部或大型項目 適合項目團隊的大小 小團隊 大團隊 適合的項目階段 全部或者項目早期 項目的中期 依賴 內(nèi)部依賴，串行執(zhí)行 造成團隊之間或者計劃之間的依賴，并行執(zhí)行 管理難度 中低 高 綜上所述，在一個項目中，項目經(jīng)理和項目管理人員往往根據(jù)項目的具體情況和項目所在階段來采用不同的迭代計劃的開發(fā)方法。甚至將兩者結(jié)合，制定適合項目的迭代計劃，從而降低項目風(fēng)險、提供項目團隊的協(xié)作能力，提高生產(chǎn)效率，實現(xiàn)快速交付的目標(biāo)。敏捷 RUP：來自實戰(zhàn)中的經(jīng)驗由 Scott W. Ambler 所做的介紹這篇文章實際上是由三篇文章組合而成的。它們?yōu)樵?IBM174。 Rational174。 Unified Process174。 或者簡稱為 RUP174。 團隊上面應(yīng)用敏捷策略提供了被證明為行之有效的建議。本文是由 Mark Lines、Joshua Barnes、以及 Julian Holmes 分別撰寫的，它們都是 Unified Process Mentors （）的共同創(chuàng)辦人。這三位已經(jīng)通過書籍指導(dǎo)了全世界成千上萬名軟件開發(fā)方面的從業(yè)者，舉辦了幾十場研討會，撰寫了多部著作，作為咨詢顧問和用戶組的主席人等。他們工作于遍及世界各地的機構(gòu)中，將他們的處理過程理論付諸實踐，通過實例引導(dǎo)并且通過結(jié)構(gòu)的改變驅(qū)動成功。 我的經(jīng)驗是，好的 RUP 就是敏捷的 1 并且包含了許多成功地測量敏捷技術(shù)所需要的建議。第一篇文章“將規(guī)則引入到敏捷的生命周期之中”是由 Mark Lines 撰寫的，它展示了 RUP 需求管理技術(shù)和風(fēng)險驅(qū)動開發(fā)周期是如何將所需要的規(guī)則性水平引入到許多機構(gòu)中的，并且還不失敏捷方法的特點之一：靈活性。作者認(rèn)為您并不希望需求在開發(fā)周期的后期發(fā)生根本上的變更，而前期的一小部分投資能夠從根本上減少您的開銷、進度、以及整個項目所面臨的風(fēng)險。第二篇文章“在大型機構(gòu)中將敏捷性引入 RUP 的策略”是由 Joshua Barnes 撰寫的，它從一個相反的方向?qū)Υ浖幚磉^程中的挑戰(zhàn)。它提出了一些快速提高您的基于 RUP 處理過程的方法——許多項目是以頭腦中固定的目標(biāo)開始的，并且在此基礎(chǔ)上進行剛性的調(diào)整，盡管實際情況是：該團隊在項目進展到一半的時候意識到他們能夠不再受到固定目標(biāo)的束縛，因為該目標(biāo)并不是固定的，而規(guī)則也并不是嚴(yán)格的。第三篇文章“地理上分布式的敏捷團隊：使個體以及它同處理過程和工具之間的交互發(fā)揮作用是由 Julian Holmes 撰寫的，它概述了在一個分布式的敏捷團隊內(nèi)部提高協(xié)作的策略。在一個項目團隊內(nèi)部完成有效的協(xié)作對于一個共處一地的團隊是一項很艱巨的挑戰(zhàn)，所以就更不用對于一個地理上分布的團隊了。Julian 提出開發(fā)一個協(xié)作團隊文化的建議，同時保持方法、交付和管理共享工作產(chǎn)品的一致性。 將規(guī)則引入到敏捷的生命周期之中由 Mark Lines 撰寫敏捷性項目能夠被無止境地迭代下去，只有當(dāng)耗盡預(yù)算時該項目才會被結(jié)束。在早期迭代和不合理的需求混合中所執(zhí)行的特性通常是麻煩的制造者。RUP 通過在早期逐出需求的不確定性將結(jié)構(gòu)添加到一個敏捷方法中，并且隨著項目的不斷推進很自然地繃緊了處理過程的控制。 我在敏捷項目中所看到的一個不適宜的傾向就是項目從一個迭代到另一個迭代，幾乎看不到盡頭。某些項目經(jīng)理（PM）好像是忘記了傳統(tǒng)的 PM 對于“客戶永遠是正確的”這一敏捷法則的嚴(yán)格性。這導(dǎo)致從迭代到迭代的持續(xù)的需求變更。通常，隨著需求條目從本次迭代中的執(zhí)行棧中移除，相等數(shù)量的或者更大數(shù)量的工作條目就會被添加回這個棧中。時間和預(yù)算被快速地消耗殆盡，而大量待處理的需求依然被留在那里。RUP 項目的兩個階段RUP 確實能夠在這些情況下幫助團隊認(rèn)識到所有的迭代并不是完全相同的。Walker Royce 將一個項目的開發(fā)周期描述為兩個階段。 2 第一個階段大約占到整個開發(fā)周期的 20% 到 40%，它將其稱之為 Engineering （工程）階段。這個階段是由統(tǒng)一處理過程（UP）的 啟始和精化 階段所組成的。工程階段表現(xiàn)為項目所有方面的混合，例如：計劃、需求、體系結(jié)構(gòu)和代碼。這是自然的，也是意料之中的，業(yè)務(wù)和技術(shù)出資方都努力去理解系統(tǒng)的解決方案是什么，以及如何將它實現(xiàn)。Royce 將開發(fā)周期的第二個階段描述為產(chǎn)品化階段，它是由 UP 開發(fā)周期的構(gòu)建和產(chǎn)品化 階段所組成的。它負(fù)責(zé)使用在前面的工程階段中被證明為有效的技術(shù)來執(zhí)行剩余的需求（大約 60% 到 80%）。適應(yīng)項目期間變更控制的嚴(yán)格性在工程階段期間，我們試圖避免通過改變控制程序加重用戶的負(fù)擔(dān)。反過來，他們也應(yīng)當(dāng)嚴(yán)格遵守委托事項，直到團隊實現(xiàn)了某些需求為止，因此得到了一個推斷嚴(yán)格的委托事項的基本線。將這一行為始終銘記在心中，根據(jù)用戶的需要（無條件的）在早期迭代中向棧中添加、改變、和區(qū)分需求的優(yōu)先次序。通過在精化 中增加同軟件的風(fēng)險方面相關(guān)的功能性，我們能夠移除大量的和項目相關(guān)的不確定性，例如：理解和建立這些需求。同需求的不確定性相關(guān)的風(fēng)險能夠通過原型、圖板、可視化建模、以及規(guī)則示范等技術(shù)被降低。關(guān)于范圍和進度的委托事項統(tǒng)稱在這個階段的末尾被期待。這種方法的好處就是相對于傳統(tǒng)的瀑布式方法來說，用戶會在更晚的時候才被要求提交需求。他們有時間在我們進入嚴(yán)格的變更控制程序之前看到軟件的進展情況，Scott Ambler 喜歡將它們稱之為“變更防御”程序。不好的消息就是有時我們?nèi)匀恍枰嚲o變更控制的嚴(yán)格性。不要不切實際的期望 IT 項目交付團隊在需求范圍不斷變更的情況下還能夠遵守進度和預(yù)算。我指導(dǎo)團隊將一個項目中的精化階段看作“sandbox”時間。IT 團隊利用這段時間指出什么是可行的，以及如何去做。同樣地，用戶也可以利用這段時間精確地指出他們所希望的是什么。一旦精化“sandbox” 階段結(jié)束之后，我們就將進入項目的產(chǎn)品化階段。此時，項目經(jīng)理需要繃緊變更控制或者無法按要求交付的風(fēng)險。圖 1 描繪了這一增長處理過程控制的概念。請注意：“變更控制的嚴(yán)格性”曲線并不一定如這張圖表中所描繪的那樣在構(gòu)建階段中如此快速地增長。這取決于您的機構(gòu)核項目的獨特方面。對于同用戶的契約關(guān)系來說，在構(gòu)建中較早地制定嚴(yán)格的變更控制程序也許是必須的。對于同用戶的協(xié)作和信任關(guān)系來說，您可能將繃緊處理過程控制推遲到構(gòu)建的后期，并且“變更控制的嚴(yán)格性”曲線也將會向右移動。圖 1: 隨著項目的進展，變更控制的嚴(yán)格性也在不斷地加強。 教育我們的出資方是一個關(guān)鍵問題不幸的是，許多“敏捷的 RUP”項目經(jīng)理并不改變他們的行為，或者設(shè)置適當(dāng)?shù)钠谕麄冊谡麄€開發(fā)周期中總是從一個迭代移動到另一個迭代。用戶通常沒有接受過理解跨越 UP 階段的變更重點的訓(xùn)練，Gary Evans 喜歡將它稱之為項目的季節(jié)。他們明白在項目的早期他們擁有相當(dāng)大程度的變更自由度，并且自然地假設(shè)這種自由度能夠貫穿于項目的始終。我曾經(jīng)向出資方展示過迭代后的演示模型，意在展示處理過程在向前移動到執(zhí)行新的需求之前，首先會召開需求引出會議！項目經(jīng)理有時會將比當(dāng)前迭代中執(zhí)行的需求更多的需求添加到未完成的工作單中！這確實是一種十分挫敗的體驗。看起來許多接受過不是基于 UP 的敏捷性訓(xùn)練的項目經(jīng)理并不能夠充分地認(rèn)識到對于增長的變更控制嚴(yán)格性的需要。他們以同樣的方式管理每一次迭代，并且不能夠設(shè)定完全符合用戶的期望。相反，接受過適當(dāng)培訓(xùn)的用戶和