【正文】 他們以同樣的方式管理每一次迭代，并且不能夠設(shè)定完全符合用戶的期望。我曾經(jīng)向出資方展示過迭代后的演示模型，意在展示處理過程在向前移動(dòng)到執(zhí)行新的需求之前，首先會(huì)召開需求引出會(huì)議！項(xiàng)目經(jīng)理有時(shí)會(huì)將比當(dāng)前迭代中執(zhí)行的需求更多的需求添加到未完成的工作單中！這確實(shí)是一種十分挫敗的體驗(yàn)。用戶通常沒有接受過理解跨越 UP 階段的變更重點(diǎn)的訓(xùn)練，Gary Evans 喜歡將它稱之為項(xiàng)目的季節(jié)。圖 1: 隨著項(xiàng)目的進(jìn)展，變更控制的嚴(yán)格性也在不斷地加強(qiáng)。對(duì)于同用戶的契約關(guān)系來說，在構(gòu)建中較早地制定嚴(yán)格的變更控制程序也許是必須的。請(qǐng)注意：“變更控制的嚴(yán)格性”曲線并不一定如這張圖表中所描繪的那樣在構(gòu)建階段中如此快速地增長。此時(shí)，項(xiàng)目經(jīng)理需要繃緊變更控制或者無法按要求交付的風(fēng)險(xiǎn)。同樣地，用戶也可以利用這段時(shí)間精確地指出他們所希望的是什么。我指導(dǎo)團(tuán)隊(duì)將一個(gè)項(xiàng)目中的精化階段看作“sandbox”時(shí)間。不好的消息就是有時(shí)我們?nèi)匀恍枰嚲o變更控制的嚴(yán)格性。這種方法的好處就是相對(duì)于傳統(tǒng)的瀑布式方法來說，用戶會(huì)在更晚的時(shí)候才被要求提交需求。同需求的不確定性相關(guān)的風(fēng)險(xiǎn)能夠通過原型、圖板、可視化建模、以及規(guī)則示范等技術(shù)被降低。將這一行為始終銘記在心中，根據(jù)用戶的需要（無條件的）在早期迭代中向棧中添加、改變、和區(qū)分需求的優(yōu)先次序。適應(yīng)項(xiàng)目期間變更控制的嚴(yán)格性在工程階段期間，我們?cè)噲D避免通過改變控制程序加重用戶的負(fù)擔(dān)。Royce 將開發(fā)周期的第二個(gè)階段描述為產(chǎn)品化階段，它是由 UP 開發(fā)周期的構(gòu)建和產(chǎn)品化 階段所組成的。工程階段表現(xiàn)為項(xiàng)目所有方面的混合，例如：計(jì)劃、需求、體系結(jié)構(gòu)和代碼。 2 第一個(gè)階段大約占到整個(gè)開發(fā)周期的 20% 到 40%，它將其稱之為 Engineering （工程）階段。RUP 項(xiàng)目的兩個(gè)階段RUP 確實(shí)能夠在這些情況下幫助團(tuán)隊(duì)認(rèn)識(shí)到所有的迭代并不是完全相同的。通常，隨著需求條目從本次迭代中的執(zhí)行棧中移除，相等數(shù)量的或者更大數(shù)量的工作條目就會(huì)被添加回這個(gè)棧中。某些項(xiàng)目經(jīng)理（PM）好像是忘記了傳統(tǒng)的 PM 對(duì)于“客戶永遠(yuǎn)是正確的”這一敏捷法則的嚴(yán)格性。RUP 通過在早期逐出需求的不確定性將結(jié)構(gòu)添加到一個(gè)敏捷方法中，并且隨著項(xiàng)目的不斷推進(jìn)很自然地繃緊了處理過程的控制。 將規(guī)則引入到敏捷的生命周期之中由 Mark Lines 撰寫敏捷性項(xiàng)目能夠被無止境地迭代下去，只有當(dāng)耗盡預(yù)算時(shí)該項(xiàng)目才會(huì)被結(jié)束。在一個(gè)項(xiàng)目團(tuán)隊(duì)內(nèi)部完成有效的協(xié)作對(duì)于一個(gè)共處一地的團(tuán)隊(duì)是一項(xiàng)很艱巨的挑戰(zhàn)，所以就更不用對(duì)于一個(gè)地理上分布的團(tuán)隊(duì)了。它提出了一些快速提高您的基于 RUP 處理過程的方法——許多項(xiàng)目是以頭腦中固定的目標(biāo)開始的，并且在此基礎(chǔ)上進(jìn)行剛性的調(diào)整，盡管實(shí)際情況是：該團(tuán)隊(duì)在項(xiàng)目進(jìn)展到一半的時(shí)候意識(shí)到他們能夠不再受到固定目標(biāo)的束縛，因?yàn)樵撃繕?biāo)并不是固定的，而規(guī)則也并不是嚴(yán)格的。作者認(rèn)為您并不希望需求在開發(fā)周期的后期發(fā)生根本上的變更，而前期的一小部分投資能夠從根本上減少您的開銷、進(jìn)度、以及整個(gè)項(xiàng)目所面臨的風(fēng)險(xiǎn)。 我的經(jīng)驗(yàn)是，好的 RUP 就是敏捷的 1 并且包含了許多成功地測(cè)量敏捷技術(shù)所需要的建議。這三位已經(jīng)通過書籍指導(dǎo)了全世界成千上萬名軟件開發(fā)方面的從業(yè)者，舉辦了幾十場(chǎng)研討會(huì)，撰寫了多部著作，作為咨詢顧問和用戶組的主席人等。 團(tuán)隊(duì)上面應(yīng)用敏捷策略提供了被證明為行之有效的建議。 Unified Process174。它們?yōu)樵?IBM174。甚至將兩者結(jié)合，制定適合項(xiàng)目的迭代計(jì)劃，從而降低項(xiàng)目風(fēng)險(xiǎn)、提供項(xiàng)目團(tuán)隊(duì)的協(xié)作能力，提高生產(chǎn)效率，實(shí)現(xiàn)快速交付的目標(biāo)。在這種情況下各個(gè)迭代計(jì)劃之間是有重合（Overlap）的，項(xiàng)目計(jì)劃活動(dòng)的執(zhí)行是并行進(jìn)行的。 測(cè)試計(jì)劃 軟件設(shè)計(jì)計(jì)劃 對(duì)于如上九種軟件工程流程，并不是一定要對(duì)應(yīng)九個(gè)單獨(dú)的子計(jì)劃，在一般的應(yīng)用軟件的開發(fā)項(xiàng)目中，一般根據(jù)角色的團(tuán)隊(duì)的情況分為如下幾個(gè)單獨(dú)的計(jì)劃：當(dāng)然這個(gè)單獨(dú)的計(jì)劃只是相對(duì)獨(dú)立的，一方面要與總體的項(xiàng)目集成計(jì)劃保持一致，另一方面還要考慮與其他軟件工程流程的計(jì)劃的依賴關(guān)系。根據(jù) RUP 的工程流程，項(xiàng)目中會(huì)有如下活動(dòng)類型：業(yè)務(wù)建模，需求分析，分析設(shè)計(jì)，實(shí)施開發(fā)，測(cè)試，部署，配置和變更管理，項(xiàng)目管理，環(huán)境。 具體例子參照如下：圖 1. 以時(shí)間為軸線的迭代計(jì)劃圖 2. 以時(shí)間為軸線的迭代計(jì)劃示例以軟件工程流程或者角色為軸線的迭代計(jì)劃當(dāng)項(xiàng)目規(guī)模比較大，團(tuán)隊(duì)內(nèi)部角色分工比較明確的情況下，迭代開發(fā)的活動(dòng)組織在一個(gè)計(jì)劃中往往難以管理和監(jiān)控。 在這種方法下，對(duì)于一個(gè)迭代開發(fā)周期中，更像一個(gè)小的瀑布模型。這種方法一般適合項(xiàng)目早期、人員較少的情況下。綜合考慮，在完成了迭代目標(biāo)、周期后，項(xiàng)目管理人員就可以開發(fā)項(xiàng)目的迭代計(jì)劃了。迭代周期的長短在同一個(gè)項(xiàng)目中是可以不同的，但是一般經(jīng)驗(yàn)來看，相對(duì)固定的設(shè)置從項(xiàng)目管理和項(xiàng)目團(tuán)隊(duì)的工作來看更適合，可以保持比較好的項(xiàng)目的工作節(jié)奏。迭代周期（Duration）也是制定迭代目標(biāo)要考慮的因素，迭代周期也是根據(jù)項(xiàng)目整體的周期長短來確定合理的周期。一般對(duì)于需求不明確的應(yīng)用軟件的開發(fā)項(xiàng)目，往往精化階段會(huì)有更多個(gè)迭代，而在產(chǎn)品移交階段的迭代會(huì)比較少。比如在初始階段一般有 12 個(gè)迭代周期，精化階段一般會(huì)有 24 個(gè)迭代周期。一般來說，這四個(gè)階段作為項(xiàng)目開發(fā)生命周期的主要里程碑，而細(xì)化后的迭代階段作為項(xiàng)目的二級(jí)里程碑。以時(shí)間為軸線的迭代計(jì)劃以時(shí)間為軸線的迭代計(jì)劃也是使用 RUP 開發(fā)整體項(xiàng)目計(jì)劃的主要的方法。在不同的項(xiàng)目或者同一個(gè)項(xiàng)目的不同的階段，會(huì)交替使用甚至組合使用。根據(jù)筆者在眾多的項(xiàng)目中應(yīng)用和實(shí)踐 RUP 中，總結(jié)出了兩種迭代計(jì)劃的開發(fā)方法。 完成對(duì)架構(gòu)決策中 3 個(gè)關(guān)鍵技術(shù)的驗(yàn)證實(shí)現(xiàn) 迭代計(jì)劃的開發(fā)方法RUP 的開發(fā)過程模型對(duì)項(xiàng)目管理和項(xiàng)目計(jì)劃提出了更高的要求，迭代計(jì)劃的好壞直接影響到項(xiàng)目目標(biāo)的實(shí)現(xiàn)，項(xiàng)目風(fēng)險(xiǎn)和生產(chǎn)效率。 開發(fā)架構(gòu)驗(yàn)證框架 概括來說，項(xiàng)目范圍或需求、架構(gòu)及決策、項(xiàng)目總體目標(biāo)是設(shè)置迭代目標(biāo)的重要的輸入。另外影響迭代目標(biāo)的另外一個(gè)重要因素是項(xiàng)目的需求和架構(gòu)的成熟程度，需求的明確程度，個(gè)性化需求和共性需求的比例，是影響項(xiàng)目風(fēng)險(xiǎn)和迭代開發(fā)目標(biāo)的重要因素。通常在項(xiàng)目前期的迭代中以發(fā)布原型系統(tǒng)和原型架構(gòu)為主，在項(xiàng)目的中期以發(fā)布的增量的功能Feature、業(yè)務(wù)模塊為主，而在項(xiàng)目的后期以增量業(yè)務(wù)功能、測(cè)試系統(tǒng)、非功能需求、缺陷修改為主。應(yīng)用 RUP 開發(fā)項(xiàng)目的迭代目標(biāo)主要是以項(xiàng)目開發(fā)周期中該迭代結(jié)束后所發(fā)布的交付物為主。 團(tuán)隊(duì)成熟度和規(guī)模 項(xiàng)目規(guī)模大小、周期 提高客戶參與度和項(xiàng)目的可視化 迭代計(jì)劃的開發(fā)考慮的因素： 體現(xiàn)了 RUP 架構(gòu)驅(qū)動(dòng)、關(guān)注風(fēng)險(xiǎn)的特點(diǎn) 多個(gè)比較明確的角色的參與 一個(gè)迭代是總體項(xiàng)目計(jì)劃的一個(gè)階段 因此使用 RUP 來完成項(xiàng)目，開發(fā)迭代計(jì)劃是實(shí)施的主要難點(diǎn)之一。本文還將與讀者分享在實(shí)際項(xiàng)目中應(yīng)用 RUP 如何開發(fā)迭代目標(biāo)、如何開發(fā)迭代計(jì)劃以及介紹了兩種不同的迭代計(jì)劃的模板參考示例。只是從項(xiàng)目管理和項(xiàng)目計(jì)劃的角度探討如何應(yīng)用 RUP 的迭代方法開發(fā)項(xiàng)目計(jì)劃。在這種情況下，RUP 的迭代開發(fā)的方法已經(jīng)成為應(yīng)用軟件開發(fā)項(xiàng)目的主流的開發(fā)模式，并能夠有效解決這些問題。筆者結(jié)合在以往項(xiàng)目中應(yīng)用 RUP 迭代開發(fā)的實(shí)踐，總結(jié)了兩種開發(fā)迭代計(jì)劃的方法，并對(duì)比兩者的適用情況，以期對(duì)應(yīng)用 RUP 的項(xiàng)目管理人員提供借鑒。從項(xiàng)目管理的角度來看，RUP 的開發(fā)中對(duì)于迭代計(jì)劃的開發(fā)和管理是保證成功交付項(xiàng)目的關(guān)鍵。 Scrum (2004). See ://。 Agile Alliance (2004) 您可以參閱本文在 developerWorks 全球站點(diǎn)上的 英文原文。至于軟件工程的社會(huì)效應(yīng)方面，Scrum已被證實(shí)的過程模式可以即時(shí)地方便需求管理，變化控制以及項(xiàng)目管理提供。 概括來說，RUP通過引入結(jié)構(gòu)化并已經(jīng)證實(shí)的進(jìn)程框架滿足了組織上的需求，而且Scrum模式可以為項(xiàng)目加入更多動(dòng)態(tài)特性。輸出的組件可以作為組織內(nèi)其它項(xiàng)目的輸入文檔。RUP過程框架可以迎合你的項(xiàng)目需要；RUP開發(fā)工程和軟件開發(fā)規(guī)劃反映了你對(duì)使用Scrum技術(shù)的決定。 結(jié)束語該工具將過程，組件和描述文檔集成起來，并創(chuàng)建一個(gè)網(wǎng)絡(luò)導(dǎo)航。這樣做有助于項(xiàng)目團(tuán)隊(duì)成員更好的理解Scrum過程。使用RUP模型設(shè)計(jì)工具可以很容易的管理Scrum的角色和組件之間的依賴性。 RUP模型設(shè)計(jì)是修改和管理核心模型的可視化工具。Rational Process Workbench 產(chǎn)品包含了RUP模型設(shè)計(jì)，RUP組織和RUP構(gòu)建。 使RUP適用于Scrum的工具項(xiàng)目規(guī)劃反映了這些決定，而且闡述了在某些階段不使用Scrum技術(shù)的原因。為了更好地保證項(xiàng)目的成功部署，產(chǎn)品化階段可以單獨(dú)作為一個(gè)項(xiàng)目擁有Scrum 部署團(tuán)隊(duì)人員。與初始階段相比，在細(xì)化和構(gòu)建階段團(tuán)隊(duì)的工作更加獨(dú)立和指向切實(shí)目標(biāo)。 RUP項(xiàng)目的四個(gè)階段體現(xiàn)了軟件工程過程中的不同項(xiàng)目樣式。新手和經(jīng)驗(yàn)不豐富的軟件工程師可以把RUP作為交流的指導(dǎo)和一個(gè)結(jié)構(gòu)化的環(huán)境。RUP過程框架可以作為指導(dǎo)，提供可供考慮的有用步驟和組件。 收集素材經(jīng)過一段時(shí)間，隨著Scrum團(tuán)隊(duì)在“疾跑”過程中規(guī)律性地獲得有用的文檔，真實(shí)的開發(fā)工程也就成形了。另一方面，你也可以從開發(fā)工程去掉所有和Scrum團(tuán)隊(duì)相關(guān)的組件。開發(fā)工程把強(qiáng)制性的和可選擇性的組件羅列出來作為成功的指路標(biāo)。這些職責(zé)和義務(wù)的不同需要在項(xiàng)目規(guī)劃中定義。 在Scrum中，Scrum管理者充當(dāng)了管理和Scrum團(tuán)隊(duì)之間的協(xié)調(diào)人。 *描述評(píng)估和評(píng)估使用的技術(shù)。 *描述正在進(jìn)行中的“疾跑”目標(biāo)； *概括項(xiàng)目中應(yīng)用的Scrum規(guī)則； 內(nèi)部的組織上，管理上，語言的，非語言的交流都應(yīng)被Scrum團(tuán)隊(duì)消除，而應(yīng)該交給Scrum管理者（在RUP中稱為項(xiàng)目經(jīng)理）處理。 RUP的“項(xiàng)目管理”原則，特別是項(xiàng)目規(guī)劃，為軟件開發(fā)團(tuán)隊(duì)提供了體驗(yàn)Scrum精髓的絕好機(jī)會(huì)。除了扮演項(xiàng)目經(jīng)理角色的Scrum管理者，團(tuán)隊(duì)成員應(yīng)該專注于對(duì)實(shí)現(xiàn)Scrum目標(biāo)必要的活動(dòng)，而不應(yīng)陷于管理工作之中。 雨傘活動(dòng)第二類是材料活動(dòng)，包括“商業(yè)模型”，“需求”，“分析和設(shè)計(jì)”，“實(shí)現(xiàn)”，“測(cè)試”，和“部署”。 為了在Scrum的上下文環(huán)境中討論RUP的九個(gè)原則，我把它們分成了兩類。團(tuán)隊(duì)與外界隔離開工作，不予許變化影響當(dāng)前的“疾跑”。他們抓住需要的變化，在本次“疾跑”結(jié)束時(shí)提出它們作為下一系列目標(biāo)的一部分。 管理變更Scrum可以從RUP的質(zhì)量保證計(jì)劃中獲益，該計(jì)劃由項(xiàng)目管理者控制，是成功的迭代開發(fā)的重要組成部分。在這種方式下，功能是用一種重復(fù)的方式測(cè)試，度量和展示的。 迭代，遞增的開發(fā)已經(jīng)為每個(gè)軟件項(xiàng)目的質(zhì)量和進(jìn)展提供了很好的度量手段。關(guān)于使用哪種組件，使用到何種程度和質(zhì)量，取決于既定的“疾跑”目標(biāo)。甚至RUP框架本身就是可視的，有很多UML的外殼。 可視化模型 很多靈活的軟件項(xiàng)目使用現(xiàn)代軟件工具和編程語言，比如，模塊構(gòu)建占主導(dǎo)的技術(shù)。RUP倡導(dǎo)的以體系架構(gòu)為核心的方法導(dǎo)致了對(duì)各種應(yīng)用結(jié)構(gòu)的仔細(xì)考慮和選擇。 使用模塊構(gòu)建在RUP中，需求管理需要通過協(xié)作完成。 整個(gè)團(tuán)隊(duì)都可以管理需求，但是需求的控制權(quán)是由產(chǎn)品所有者掌握的。盡管在對(duì)“迭代”的定義上RUP更為靈活，30天的限定仍然經(jīng)常被RUP使用，并且已被認(rèn)為是一個(gè)有效的長度。 迭代開發(fā) 讓我們從RUP過程框架的六個(gè)最佳實(shí)踐開始吧。 RUP各階段和原則之間的關(guān)系如圖一所示。 現(xiàn)在使用RUP的軟件項(xiàng)目可以很容易地從Scrum原則中獲益，即使已經(jīng)開始的項(xiàng)目也是如此。這些模式在過去的大小項(xiàng)目和不同商業(yè)領(lǐng)域中都獲得了成功。在會(huì)上，團(tuán)隊(duì)向項(xiàng)目的風(fēng)險(xiǎn)承擔(dān)者展示完成的功能模塊。團(tuán)隊(duì)是自組織的，著眼于“疾跑”的目標(biāo)，這樣就最大限度發(fā)揮了每一個(gè)團(tuán)隊(duì)成員的作用。這就使得組織上的問題和挑戰(zhàn)清晰明顯。在團(tuán)隊(duì)對(duì)“疾跑”的作用有更多了解以后，團(tuán)隊(duì)成員就可以調(diào)整原始的產(chǎn)品評(píng)估，并將“疾跑”過程中獲得的信息加入到產(chǎn)品訂單中。“疾跑”過程一旦開始，團(tuán)隊(duì)全部與外界的交流都必須經(jīng)由Scrum管理者進(jìn)行。產(chǎn)品風(fēng)險(xiǎn)的所有承擔(dān)者，包括Scrum團(tuán)隊(duì)和產(chǎn)品所有者，共同檢視訂單，然后根據(jù)優(yōu)先級(jí)次序決定先開發(fā)哪一功能。 Scrum的迭代過程被稱為“疾跑”，時(shí)間為30天。 Scrum團(tuán)隊(duì)不止是一個(gè)程序員隊(duì)伍，它由各種背景下的不同角色組合而成，包括商業(yè)分析者，設(shè)計(jì)師，程序員和測(cè)試者等等。Scrum甚至可以兼顧在其他地方工作的團(tuán)隊(duì)成員。分組可依據(jù)功能，結(jié)構(gòu)主體，或者應(yīng)用，包括子應(yīng)用等進(jìn)行。 只有團(tuán)隊(duì)成員可以在Scrum會(huì)議上發(fā)言，但是允許有旁聽者。如果問題得不到解決，團(tuán)隊(duì)成員應(yīng)向Scrum管理者或大項(xiàng)目成員提出質(zhì)疑。Scrum管理者在會(huì)上對(duì)障礙提出即時(shí)的解決方案或指導(dǎo)，使團(tuán)隊(duì)不斷向著目標(biāo)前進(jìn)。Scrum管理者*主持會(huì)議，并且對(duì)整個(gè)項(xiàng)目的成敗負(fù)責(zé)。 Scrum團(tuán)隊(duì)的組成 *從現(xiàn)在到下次Scrum會(huì)議的時(shí)間里你準(zhǔn)備做什么？ 這個(gè)會(huì)議也叫Scrum，在會(huì)議中每個(gè)團(tuán)隊(duì)成員僅就以下三點(diǎn)發(fā)言： Scrum如何工作RUP和其他敏捷軟件工程過程能夠很好地迎接這些挑戰(zhàn)。這種重復(fù)使得輸入和輸出參數(shù)更加容易預(yù)測(cè)和描述，但這并不是當(dāng)今軟件工程的有益目標(biāo)。 這一過程是迅速，有適應(yīng)性，自組織的，它代表了從順序開發(fā)過程以來的重大變化。2 ” 它發(fā)現(xiàn)了軟件工程的社會(huì)意義。 Scrum于1995年由Advanced Development Methodologies,Inc提出，并在2001年“敏捷聯(lián)盟（Agile Alliance）”形成后受到了更多歡迎。 什么是Scrum？我在工具條內(nèi)提供了關(guān)于Scrum和“靈活”的術(shù)語的詞匯表，并且在下文中這些術(shù)語首次出現(xiàn)的地方用星號(hào)作了標(biāo)記。Scrum是一系列有趣的，用來包裝靈活軟件項(xiàng)目的項(xiàng)目管理模式。 正如你所知道的，RUP（Rational Unified Process，Rational 統(tǒng)一過程），是一種被廣泛使用的軟件過程框架。 來自于 Ra