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