| Gary Pollice
IBM
2005 年 1 月 IBM Rational Unified Process?（或簡稱 RUP?）是一個(gè)完善的軟件開發(fā)過程框架，它具有若干種即裝即用的實(shí)例。源自 RUP 的過程范圍很廣，從滿足短周期的小型項(xiàng)目需要的輕量級(jí) RUP，到滿足大型的、可能是分布式的項(xiàng)目團(tuán)隊(duì)需要的更加完備的過程。各種類型和規(guī)模的項(xiàng)目都已成功地使用了 RUP。本白皮書說明了如何在小型項(xiàng)目中以輕量級(jí)的方式應(yīng)用 RUP。我們將要講解如何在一個(gè)完整項(xiàng)目的上下文范圍內(nèi)應(yīng)用極限編程（XP）技術(shù)。 摘要
IBM Rational Unified Process?（或簡稱 RUP?）是一個(gè)完善的軟件開發(fā)過程框架，它具有若干種即裝即用的實(shí)例。源自 RUP 的過程范圍很廣，從滿足短周期的小型項(xiàng)目需要的輕量級(jí) RUP，到滿足大型的、可能是分布式的項(xiàng)目團(tuán)隊(duì)需要的更加完備的過程。各種類型和規(guī)模的項(xiàng)目都已成功地使用了 RUP。本白皮書說明了如何在小型項(xiàng)目中以輕量級(jí)的方式應(yīng)用 RUP。我們將要講解如何在一個(gè)完整項(xiàng)目的上下文范圍內(nèi)應(yīng)用極限編程（XP）技術(shù)。 引言
一個(gè)小故事
一天早上，一名經(jīng)理找到我詢問我是否可以花幾個(gè)星期為一家公司剛剛啟動(dòng)的投資建立一個(gè)簡單的信息系統(tǒng)。我正厭煩手頭的項(xiàng)目而渴望新項(xiàng)目啟動(dòng)帶來刺激，于是我為這個(gè)機(jī)會(huì)歡欣雀躍--我快速開始行動(dòng)，為新的偉大解決方案進(jìn)行開發(fā)，而擺脫我工作的大型機(jī)構(gòu)的官僚和手續(xù)的束縛。 事情在開始階段進(jìn)行得很順利。在頭六個(gè)月中，我都工作很長時(shí)間并且自得其樂。我的工作效率不可思議，并且一些工作堪稱是我職業(yè)生涯中的杰作。開發(fā)周期是快速的，而且我每隔幾周就可以完成系統(tǒng)中一些新的主要部分。與用戶的交互過程簡單而直接，我們都屬于一個(gè)緊密聯(lián)系的團(tuán)隊(duì)，而且可以免除一些手續(xù)和文檔。也沒有什么正式的設(shè)計(jì)；代碼就是設(shè)計(jì)，設(shè)計(jì)也就是代碼。一切都是這樣的完美！ 這種完美只持續(xù)了一段時(shí)間。隨著系統(tǒng)開發(fā)的進(jìn)行，我們需要開展更多的工作?，F(xiàn)有代碼隨著問題的變更而必須進(jìn)行完善，而且我們也相應(yīng)精化了所需工作的概念。我雇了一些開發(fā)人員幫助進(jìn)行開發(fā)。我們就像一個(gè)單元一樣工作，經(jīng)常對(duì)一些問題互相討論。這加強(qiáng)了溝通同時(shí)也免除了形式。 一年過去了。 我們還在增加開發(fā)人員。整個(gè)團(tuán)隊(duì)從 3 個(gè)人到 5 個(gè)人，然后是 7 個(gè)人。每次增加人員時(shí)，都要花很長的時(shí)間來學(xué)習(xí)，如果沒有經(jīng)驗(yàn)，那么就很難理解和解釋整套系統(tǒng)，即使是一個(gè)概覽。我們開始使用白板圖來更加正式地展示系統(tǒng)的整體結(jié)構(gòu)、主要概念和接口。 我們?nèi)匀辉谑褂脺y試作為驗(yàn)證系統(tǒng)是否滿足需要的主要手段。很多新來的開發(fā)人員都站在用戶的立場上，我們發(fā)現(xiàn)項(xiàng)目早期非正式的需求和個(gè)人聯(lián)系已經(jīng)不能滿足需要了。我們花費(fèi)了更長的時(shí)間來計(jì)劃我們要建立的目標(biāo)內(nèi)容。結(jié)果由于我們保留了討論的文字記錄，而不用頻繁地回想已經(jīng)做過的決定。我們還發(fā)現(xiàn)描述需求和使用場景有助于向系統(tǒng)的新用戶介紹情況。 系統(tǒng)的規(guī)模和復(fù)雜度不斷增加，意外的情況發(fā)生了--需要清楚地描述系統(tǒng)的構(gòu)架。在項(xiàng)目初期，構(gòu)架大部分存于我的頭腦中，后來潦草地記在筆記或活動(dòng)掛圖中。不過，隨著項(xiàng)目的人員越來越多，構(gòu)架有些失控。由于不是每個(gè)人都和我一樣富有經(jīng)驗(yàn)，他們無法發(fā)現(xiàn)某些變更對(duì)整個(gè)構(gòu)架帶來的影響。我們不得不使用更精確的術(shù)語定義對(duì)系統(tǒng)構(gòu)架的約束。任何可能影響構(gòu)架的變更都需要團(tuán)隊(duì)進(jìn)行商討，并且最終獲得我的同意。我們繞了一圈后才發(fā)現(xiàn)了這個(gè)問題，接受了一些重大教訓(xùn)之后，這在真正認(rèn)識(shí)到構(gòu)架的重要性。 這是一段真實(shí)經(jīng)歷。它只講述了這個(gè)項(xiàng)目中的一部分困難經(jīng)歷。這些經(jīng)歷只在一個(gè)方面是不同尋常的：我們中的一部分人從開始的最后一直在一起，時(shí)間一年有余。開發(fā)人員經(jīng)常在一個(gè)項(xiàng)目中半途而來，沒等結(jié)束就已經(jīng)離開，絲毫看不到他們的所作所為帶來的后續(xù)影響。 這個(gè)項(xiàng)目本該使用一些過程進(jìn)行管理。過程太多會(huì)誤事，但是不使用過程會(huì)帶來新的風(fēng)險(xiǎn)。就像投資高風(fēng)險(xiǎn)股票的人僅僅看到高回報(bào)一樣，幾乎不使用過程 的項(xiàng)目組忽略了項(xiàng)目環(huán)境中的關(guān)鍵風(fēng)險(xiǎn)，其實(shí)是在"期望得到最好的結(jié)果，但是沒有為最壞的情況做打算"。 概述
本文討論了如何將過程應(yīng)用到例如上文所述的項(xiàng)目中。我們的目的是為了得到使用過程的"恰當(dāng)級(jí)別"。了解開發(fā)團(tuán)隊(duì)所面對(duì)的挑戰(zhàn)以及其所處的來務(wù)環(huán)境，可以得出過程使用的恰當(dāng)級(jí)別。如果我們理解了這些挑戰(zhàn)，就可以使用剛好足夠的過程來降低風(fēng)險(xiǎn)。不論是輕量級(jí)的還是其他，"一刀切"過程是不存在的。在以下內(nèi)容中，我們來研究這一思想，即過程的恰當(dāng)級(jí)別可以作為一個(gè)風(fēng)險(xiǎn)的函數(shù)。 我們集中討論如何通過使用兩個(gè)流行的方法得到過程的恰當(dāng)級(jí)別：Rational Unified Process 或簡稱 RUP 以及極限編程（XP）。我們展示如何在小型項(xiàng)目中使用 RUP 以及 RUP 如何處理 XP 沒有涉及到的領(lǐng)域。二者融合為項(xiàng)目團(tuán)隊(duì)提供了所需的指南--減少風(fēng)險(xiǎn)同時(shí)完成交付軟件產(chǎn)品的目標(biāo)。 RUP 是由 IBM Rational 開發(fā)的過程框架。它是一種迭代的開發(fā)方法，基于六個(gè)經(jīng)過行業(yè)驗(yàn)證的最佳實(shí)踐（參見 RUP 附錄）。隨著時(shí)間的推進(jìn)，一個(gè)基于 RUP 的項(xiàng)目將經(jīng)歷四個(gè)階段：起始階段（Inception）、細(xì)化階段（Elaboration）、構(gòu)造階段（Construction）、交付階段（Transition）。每個(gè)階段都包括一次或者多次的迭代。在每次迭代中，您根據(jù)不同的要求或工作流（如需求、分析和設(shè)計(jì)等）投入不同的工作量。RUP 的關(guān)鍵驅(qū)動(dòng)因素就是降低風(fēng)險(xiǎn)。RUP 通過數(shù)千個(gè)項(xiàng)目中數(shù)千名 IBM Rational 客戶和合作伙伴使用而得到精化。下圖展示了一個(gè)典型迭代過程的工作流： 典型迭代流
 作為風(fēng)險(xiǎn)如何影響過程的一個(gè)例子，我們應(yīng)該考慮是否需要為業(yè)務(wù)建模。如果由于對(duì)業(yè)務(wù)的理解中沒有考慮到一些重大風(fēng)險(xiǎn)，將導(dǎo)致我們所構(gòu)建的系統(tǒng)是錯(cuò)誤的，那么我們就應(yīng)該執(zhí)行一些業(yè)務(wù)建模工作。我們需要正式進(jìn)行建模工作嗎？這取決于我們的涉眾--如果一個(gè)小團(tuán)隊(duì)將非正式地使用結(jié)果，那么我們也許只進(jìn)行非正式的記錄就可以。如果組織中的其他人也將使用結(jié)果或者查看結(jié)果，那么我們可能就要投入更大的努力，并且確保該結(jié)果的正確性和可理解性。 您可以定制 RUP 使其滿足幾乎任何項(xiàng)目的需要。如果沒有滿足您特定需要的即裝即用的過程或路線圖，您可以輕松地創(chuàng)建您自己的路線圖。路線圖描述了該項(xiàng)目如何計(jì)劃使用過程，因此代表了該項(xiàng)目的特定過程實(shí)例。這就意味著，RUP 可以按需要變得簡單或復(fù)雜，我們將在本文中詳細(xì)解釋。 XP 是一個(gè)用于小型項(xiàng)目中的以代碼為中心的輕量級(jí)過程（參見 XP 附錄）。它來自 Kent Beck 的創(chuàng)意，在大概 1997 年 Chrysler 公司的 C 3 工資單項(xiàng)目中得到軟件界的關(guān)注。如同 RUP 一樣，XP 也是基于迭代的，并且體現(xiàn)了諸如小規(guī)模發(fā)布、簡單設(shè)計(jì)、測試以及持續(xù)迭代幾項(xiàng)實(shí)踐，。XP 為恰當(dāng)?shù)捻?xiàng)目和環(huán)境引入了一些有效的技術(shù)；不過，其中也存在隱藏的假設(shè)、活動(dòng)和角色。 RUP 和 XP 具有不同的基本原理。RUP 是過程組件、方法以及技術(shù)的框架，您可以將其應(yīng)用于任何特定的軟件項(xiàng)目，我們希望用戶限定 RUP 的使用范圍。XP，從另一方面來說，是一個(gè)具有更多限制的過程，需要附加內(nèi)容以使其適合完整的開發(fā)項(xiàng)目。這些不同點(diǎn)解釋了軟件開發(fā)界的一個(gè)觀點(diǎn)：開發(fā)大型系統(tǒng)的人員使用 RUP 解決問題，而開發(fā)小型系統(tǒng)的人員使用 XP 作為解決方案。我們的經(jīng)驗(yàn)表明大部分的軟件項(xiàng)目都處于兩者之間--盡力找尋適用于各自情況的過程的恰當(dāng)級(jí)別。單純地使用兩者之一是不充分的。 當(dāng)您在 RUP 中融合了 XP 技術(shù)時(shí)，您會(huì)得到過程的正確量，既滿足了項(xiàng)目所有成員的需要，又解決了所有主要的項(xiàng)目風(fēng)險(xiǎn)問題。對(duì)于一個(gè)工作于高信任環(huán)境中的小型項(xiàng)目團(tuán)隊(duì)，其中用戶是團(tuán)隊(duì)的一部分，那么 XP 完全可以勝任。對(duì)于團(tuán)隊(duì)越來越分散，代碼量越來越大，或者構(gòu)架沒有很好定義的情況，您需要做一些其他工作。在用戶交互具有"契約"風(fēng)格的項(xiàng)目中，僅有 XP 是不夠的。RUP 是一個(gè)框架，您可以從 RUP 出發(fā)，在必要時(shí)以一組更健壯的技術(shù)來擴(kuò)展 XP。 本文的以下部分描述了一個(gè)基于 RUP 四個(gè)階段的小型項(xiàng)目。在每個(gè)階段中，我們都確定了所產(chǎn)生的活動(dòng)和工件 。雖然 RUP 和 XP 具有不同的角色和職責(zé)，但是我們在這里不會(huì)處理這些差異。對(duì)于任何組織或項(xiàng)目，實(shí)際項(xiàng)目成員必須在過程中與正確的角色關(guān)聯(lián)起來。 項(xiàng)目啟動(dòng)－起始階段
對(duì)于新的開發(fā)項(xiàng)目來說，起始階段是很重要的，在項(xiàng)目繼續(xù)進(jìn)行前，您必須處理重要的業(yè)務(wù)與需求風(fēng)險(xiǎn)。對(duì)于那些增強(qiáng)現(xiàn)有系統(tǒng)的項(xiàng)目，起始階段是比較短暫的，但是其目的仍是確定該項(xiàng)目的實(shí)施價(jià)值及可行性。 在起始階段中，為了構(gòu)建軟件您可以創(chuàng)建業(yè)務(wù)案例。視圖是起始過程中的關(guān)鍵工件。它是系統(tǒng)的高級(jí)描述。它為每個(gè)人解釋該系統(tǒng)是什么、可能使用系統(tǒng)的用戶、使用系統(tǒng)的原因、必須具備的功能，以及存在的約束。視圖可能很短，也許只有一兩段。視圖往往包括軟件必須為客戶提供的關(guān)鍵功能。 下面的例子展示了一個(gè)項(xiàng)目的很短視圖，該項(xiàng)目對(duì) Rational 的外部網(wǎng)站進(jìn)行了改造。 為使 Rational 的地位達(dá)到電子開發(fā)（包括工具、服務(wù)和最佳實(shí)踐）的世界領(lǐng)先程度，可以通過動(dòng)態(tài)的、個(gè)性化的網(wǎng)站加強(qiáng)客戶關(guān)系，為訪問者提供自助服務(wù)、支持和目標(biāo)內(nèi)容。新的過程和技術(shù)啟用可以使內(nèi)容供應(yīng)商通過一種簡化的、自動(dòng)的解決方案加速發(fā)布并提高內(nèi)容的質(zhì)量。 RUP 起始階段中 4 個(gè)重要活動(dòng)為： 制定項(xiàng)目的范圍。如果我們打算構(gòu)建一個(gè)系統(tǒng)，我們需要知道其內(nèi)容以及它如何滿足涉眾的需要。在這個(gè)活動(dòng)中，我們捕獲內(nèi)容和最重要的需求的足夠詳細(xì)的信息，從而得出產(chǎn)品可接受的標(biāo)準(zhǔn)。 計(jì)劃并準(zhǔn)備業(yè)務(wù)案例。我們使用視圖作為指導(dǎo)，定義風(fēng)險(xiǎn)緩和策略，開發(fā)起始的項(xiàng)目計(jì)劃，并確定已知成本、日程計(jì)劃，以及盈利率平衡。 綜合得出備選構(gòu)架。如果正在計(jì)劃中的系統(tǒng)沒什么新穎性，而且使用的框架廣為人之，那么您可以跳過這一步。我們一旦知道客戶的需求，就要開始分配時(shí)間研究可行的備選構(gòu)架。新技術(shù)能夠帶來解決軟件問題的新的并且經(jīng)過改進(jìn)的解決方案。在過程的早期花些時(shí)間評(píng)估購買還是創(chuàng)建系統(tǒng)，并選擇技術(shù)，也可以開發(fā)出一個(gè)起始原型，這些都可以減少項(xiàng)目的一些主要風(fēng)險(xiǎn)。 準(zhǔn)備項(xiàng)目環(huán)境。任何項(xiàng)目都需要項(xiàng)目環(huán)境。不論您使用 XP 技術(shù)（例如結(jié)對(duì)編程），還是較傳統(tǒng)的技術(shù)，您都需要確定團(tuán)隊(duì)將要使用的物理資源、軟件工具以及步驟。 進(jìn)行小型項(xiàng)目開發(fā)時(shí)，并不需要太多的"過程時(shí)間"來執(zhí)行起始過程。您往往可以在幾天中或者更少的時(shí)間里完成，下面的內(nèi)容說明了本階段除了視圖之外的預(yù)期工件。 一個(gè)經(jīng)批準(zhǔn)的業(yè)務(wù)案例
涉眾有機(jī)會(huì)從業(yè)務(wù)的角度認(rèn)定項(xiàng)目是值得進(jìn)行的。RUP 和 XP 都承認(rèn)最好在早期就得出項(xiàng)目是否值得進(jìn)行的結(jié)論，以免在一個(gè)注定將要失敗的項(xiàng)目中花費(fèi)寶貴的資源。如同在"Planning Extreme Programming" 一書描述的那樣，XP 對(duì)于項(xiàng)目是如何形成的以及涉及哪些角色這兩個(gè)問題的回答是比較模糊的（似乎在現(xiàn)有項(xiàng)目或系統(tǒng)的環(huán)境中是最清晰的），但是在研究階段，XP 處理的工件與 RUP 起始過程中的是相同的。 不論您在 XP 中非正式地考慮業(yè)務(wù)問題，還是在 RUP 中將業(yè)務(wù)案例做成一流的項(xiàng)目工件，您都需要考慮這些問題。風(fēng)險(xiǎn)清單您應(yīng)該在整個(gè)項(xiàng)目開發(fā)過程中都保持記錄 Risk List（風(fēng)險(xiǎn)清單）。使用有風(fēng)險(xiǎn)清單可以是一個(gè)具有經(jīng)過計(jì)劃的風(fēng)險(xiǎn)緩和策略的簡單清單。為各個(gè)風(fēng)險(xiǎn)設(shè)定優(yōu)先級(jí)。任何與項(xiàng)目有關(guān)的人員都可以隨時(shí)看到風(fēng)險(xiǎn)的內(nèi)容以及如何處理風(fēng)險(xiǎn)，但是沒有提供解決風(fēng)險(xiǎn)的一般方式 。 初步項(xiàng)目計(jì)劃
本計(jì)劃包括資源估算、規(guī)模以及階段計(jì)劃。對(duì)于任何項(xiàng)目，這些估算都是不斷變化的，您必須監(jiān)控它們。 項(xiàng)目驗(yàn)收計(jì)劃
您的計(jì)劃正式與否依賴于項(xiàng)目的類型。您必須判斷客戶會(huì)如何才能認(rèn)為您的項(xiàng)目取得了成功。對(duì)于一個(gè) XP 項(xiàng)目，客戶會(huì)采取驗(yàn)收測試的形式。在更普遍的過程中，客戶可能不會(huì)真正地進(jìn)行測試，但是接受的標(biāo)準(zhǔn)必須直接由客戶作出，或者由另一個(gè)角色作出，例如與客戶直接接觸的系統(tǒng)分析員。也可能存在其他的驗(yàn)收標(biāo)準(zhǔn)，例如創(chuàng)建最終用戶文檔和幫助，但是XP并不涉及此內(nèi)容。 起始細(xì)化迭代計(jì)劃
在基于 RUP 的項(xiàng)目中，在上次迭代的最后，您將詳細(xì)計(jì)劃下次迭代。在迭代的最后，您可以評(píng)估迭代開始時(shí)設(shè)立的標(biāo)準(zhǔn)。XP 提供了探監(jiān)控與衡量迭代成功的一些優(yōu)秀技巧。衡量標(biāo)準(zhǔn)是簡單的，您可以輕松地將它們合并到迭代計(jì)劃和評(píng)估標(biāo)準(zhǔn)中。 起始用例模型
雖然這聽起來比較正式而讓人望之卻步，但是它卻相當(dāng)簡單。用例與客戶在XP中編寫的"故事"相對(duì)應(yīng)。其間的差異就是一個(gè)用例就是一套完整的動(dòng)作，由參與者或系統(tǒng)外部的人員或事物發(fā)起，這正是用例的價(jià)值所在。用例可能包括若干個(gè)XP"故事"。RUP 為了定義項(xiàng)目的邊界，推薦在起始過程中確定用戶與角色。從用戶的觀點(diǎn)關(guān)注整套操作有助于將系統(tǒng)分為有價(jià)值的部分。這有助于判定恰當(dāng)?shù)膶?shí)施特性，因此我們能夠在每次迭代的最后向客戶交付一些成果（可能在起始迭代與細(xì)化迭代早期除外）。 RUP 與 XP 都可以幫助我們確保避免一種情況，即整個(gè)項(xiàng)目已完成 80％，但都不是可交付的形式。我們一直希望發(fā)布的系統(tǒng)對(duì)用戶都是有價(jià)值的。 在這一點(diǎn)上，用例模型在識(shí)別用例和參與者方面幾乎沒有或只有很少提供支持的細(xì)節(jié)。它可以是手工或使用工具繪制的簡單的文本或者 UML（統(tǒng)一建模語言）圖。該模型幫助我們確保已經(jīng)包含了涉眾所關(guān)心的正確的功能，并且沒用忘記任何功能，并允許我們輕松地查看整個(gè)系統(tǒng)。用例根據(jù)若干因素設(shè)定優(yōu)先級(jí)，這些因素包括風(fēng)險(xiǎn)、對(duì)客戶的重要程度以及技術(shù)難點(diǎn)。起始階段中不需要過于正式的或過大的工件。按照您的需求讓它們保持簡單或者正式就可以。XP 包括對(duì)計(jì)劃與系統(tǒng)驗(yàn)收的指南，但是 RUP 需要在項(xiàng)目的早期添加更多的一些內(nèi)容。這些少量添加可能通過處理一套更完整的風(fēng)險(xiǎn)而為項(xiàng)目提供很大的價(jià)值。 細(xì)化階段
細(xì)化階段的目標(biāo)是為系統(tǒng)構(gòu)架設(shè)立基線，為在構(gòu)建階段大量的設(shè)計(jì)與實(shí)施工作打下堅(jiān)實(shí)的基礎(chǔ)。構(gòu)架通過考慮最重要的需求（那些對(duì)系統(tǒng)構(gòu)架影響最大的需求）與評(píng)估風(fēng)險(xiǎn)演進(jìn)而來。構(gòu)架的穩(wěn)定性是通過一個(gè)或多個(gè)構(gòu)架原型進(jìn)行評(píng)估的。 在 RUP 中，設(shè)計(jì)活動(dòng)主要關(guān)注系統(tǒng)構(gòu)架的概念，對(duì)于軟件密集型的系統(tǒng)來說，就是軟件構(gòu)架的概念。使用組件構(gòu)架是在 RUP 中體現(xiàn)的軟件開發(fā) 6 項(xiàng)最佳實(shí)踐其中之一，該實(shí)踐推薦在開發(fā)與所作所為構(gòu)架上要投入一些時(shí)間。在這項(xiàng)工作花費(fèi)的時(shí)間可以減緩與脆弱的、僵化日系統(tǒng)有關(guān)的風(fēng)險(xiǎn)。 XP 使用"隱喻"替換了構(gòu)架的概念。隱喻只捕獲構(gòu)架的一部分，而其余構(gòu)架部分則隨著代碼開發(fā)的自然結(jié)果而演進(jìn)。XP假定構(gòu)架的形成是從生成簡單的代碼開始，然后進(jìn)行持續(xù)的代碼重構(gòu)。 在 RUP 中，構(gòu)架不只是"隱喻"。在細(xì)化階段中，您構(gòu)建可執(zhí)行的構(gòu)架，從中可能降低與是否滿足非功能性需求相關(guān)的許多風(fēng)險(xiǎn)，例如性能、可靠性以及健壯性。通過閱讀XP文獻(xiàn)，很可能推斷出一些 RUP 為細(xì)化階段所描述的內(nèi)容，尤其是過于 XP 所稱的基礎(chǔ)設(shè)施的過分關(guān)注，都是徒勞無功的。XP 認(rèn)為在沒有必要的情況下創(chuàng)建基礎(chǔ)設(shè)施所做的工作導(dǎo)致了解決方案過于復(fù)雜，并且所創(chuàng)建的結(jié)果對(duì)客戶沒有價(jià)值。在 RUP 中，構(gòu)架與基礎(chǔ)設(shè)施不是等同的。 在 RUP 與 XP 中創(chuàng)建構(gòu)架的方法是截然不同。RUP 建議您關(guān)注構(gòu)架，避免隨時(shí)間變化而產(chǎn)生的范圍蔓延、增加項(xiàng)目規(guī)模以及采用新技術(shù)帶來的風(fēng)險(xiǎn)。XP 采用足夠簡單或是很好理解的現(xiàn)有構(gòu)架，該構(gòu)架能夠隨著代碼而演進(jìn)。XP 建議您不要為明天而設(shè)計(jì)，而要為今天而實(shí)施。XP 相信如果您盡可能地保持設(shè)計(jì)簡單，那么將來管理起來也輕而易舉。RUP 希望您考慮該主張帶來的風(fēng)險(xiǎn)。如果系統(tǒng)或者部分系統(tǒng)在未來不得不重寫，那么 XP 認(rèn)為這種舉措比現(xiàn)在就計(jì)劃這種可能性更明智而且花費(fèi)更少。對(duì)于一些系統(tǒng)，這是千真萬確的，而且使用 RUP 時(shí)，在您細(xì)化階段考慮風(fēng)險(xiǎn)也會(huì)得出同一結(jié)論。RUP 并不認(rèn)為對(duì)于所有系統(tǒng)這都是正確的，而且經(jīng)驗(yàn)表明對(duì)于那些較大型、較復(fù)雜和沒有先例的系統(tǒng)來說，這可能是災(zāi)難性的。 雖然為未來的可能性（可能永遠(yuǎn)不會(huì)生生）花費(fèi)太多的精力可能是一種浪費(fèi)但是對(duì)未來進(jìn)行足夠的關(guān)注不失為一件精明之舉。多少公司能花得起代價(jià)不斷重寫或者甚至是重構(gòu)代碼呢？ 對(duì)于任何項(xiàng)目，在細(xì)化階段您應(yīng)該至少完成這三項(xiàng)活動(dòng)： 定義、驗(yàn)證并且設(shè)定構(gòu)架的基線。使用風(fēng)險(xiǎn)清單從起始階段開發(fā)備選構(gòu)架。我們關(guān)注是否能夠保證構(gòu)想中的軟件具有可行性。如果選定技術(shù)對(duì)于系統(tǒng)沒什么新穎性或者復(fù)雜性，這項(xiàng)任務(wù)不會(huì)花費(fèi)太長時(shí)間。如果您正在向現(xiàn)有系統(tǒng)中添加內(nèi)容，那么如果現(xiàn)有構(gòu)架不需要進(jìn)行變更，這項(xiàng)任務(wù)就不是必要的。但是當(dāng)真正出現(xiàn)構(gòu)架風(fēng)險(xiǎn)時(shí)，您并不想讓您的架構(gòu)來"碰運(yùn)氣"。 作為這項(xiàng)活動(dòng)的一部分，您可能執(zhí)行一些組件選擇，并且做出決定進(jìn)行購買/創(chuàng)建/重用組件。如果這需要大量工作，您可以將其分為單獨(dú)的活動(dòng)。 精化視圖。在起始階段，您開發(fā)了一個(gè)視圖。因?yàn)槟阋_定項(xiàng)目的可行性，并且涉眾有時(shí)間檢查和評(píng)價(jià)系統(tǒng)，因此可能要對(duì)視圖文檔及需求作出一些變更。對(duì)視圖與需求的修改一般在細(xì)化階段進(jìn)行。在細(xì)化階段的最后，您已經(jīng)深刻理解了用來構(gòu)建和計(jì)劃的最關(guān)鍵的用例。涉眾需要得到認(rèn)可，在當(dāng)前構(gòu)架的環(huán)境中，只要按照當(dāng)前的計(jì)劃開發(fā)整個(gè)系統(tǒng)，就能實(shí)現(xiàn)當(dāng)前的設(shè)想。在隨后的迭代過程中，變更的數(shù)量應(yīng)該有所減少，但是您可能會(huì)在每次迭代中花一些時(shí)間進(jìn)行需求管理。 為構(gòu)建階段創(chuàng)建迭代計(jì)劃并且設(shè)定基線?，F(xiàn)在，可以為您的計(jì)劃填充細(xì)節(jié)了。在每次構(gòu)建迭代的最后，您可以按需要重新考慮計(jì)劃并且進(jìn)行調(diào)整。調(diào)整過程經(jīng)常是必需的，因?yàn)樾枰M(jìn)行的工作往往被錯(cuò)誤地估算，業(yè)務(wù)環(huán)境也會(huì)常常變化，有時(shí)需求也會(huì)發(fā)生變更。為用例、場景以及技術(shù)工作設(shè)定優(yōu)先級(jí)，然后將它們分配到迭代過程中。在每次迭代過程的最后，您計(jì)劃產(chǎn)生一個(gè)能夠?yàn)樯姹娞峁﹥r(jià)值的工作產(chǎn)品。 您可以在細(xì)化階段執(zhí)行其他活動(dòng)。我們推薦您建立測試環(huán)境并且開始開發(fā)測試。雖然詳細(xì)的代碼還沒有完成，但是您仍然可以設(shè)計(jì)測試，也許可以實(shí)施集成測試。程序員應(yīng)該隨時(shí)準(zhǔn)備進(jìn)行單元測試，并且了解如何使用項(xiàng)目選定的測試工具。XP 推薦您在編寫代碼前先設(shè)計(jì)測試內(nèi)容。這是個(gè)獨(dú)到的見解，尤其是當(dāng)您向現(xiàn)有代碼主體中添加內(nèi)容時(shí)。不過，無論您選擇如何進(jìn)行測試，都應(yīng)該在細(xì)化階段建立常規(guī)測試體制。 RUP 描述的細(xì)化階段包括 XP 中的研究階段和投入階段。XP 處理技術(shù)風(fēng)險(xiǎn)（例如新穎性和復(fù)雜性）的方式為使用"spike"解決方案，例如花費(fèi)一些時(shí)間進(jìn)行試驗(yàn)以對(duì)工作量進(jìn)行估算。這種技術(shù)在許多案例中都是有效的，當(dāng)較大風(fēng)險(xiǎn)沒有體現(xiàn)在單個(gè)用例或"故事"中時(shí)，您就需要花些工夫確保系統(tǒng)的成功而且對(duì)工作量進(jìn)行精確的估算。 在細(xì)化階段，您會(huì)經(jīng)常更新工件，例如起始階段的需求與風(fēng)險(xiǎn)清單。在細(xì)化階段可能出現(xiàn)的工件包括： 軟件構(gòu)架文檔（SAD）。SAD 是一個(gè)復(fù)合型的工件，它提供了整個(gè)項(xiàng)目的技術(shù)信息的單一來源。在細(xì)化階段的最后，該文檔可能會(huì)包含詳細(xì)的介紹，描述在結(jié)構(gòu)上很重要的用例，并且確定關(guān)鍵的機(jī)制和設(shè)計(jì)元素。對(duì)于增強(qiáng)現(xiàn)有系統(tǒng)的項(xiàng)目，您可以使用以前的 SAD，或者如果你覺得不會(huì)帶來什么風(fēng)險(xiǎn)，那么就決定不使用該文檔。在所有的情況下，您都應(yīng)該深思熟慮并且記錄于文檔中。 構(gòu)建過程的迭代計(jì)劃。您可以在細(xì)化階段計(jì)劃構(gòu)建迭代的次數(shù)。每次迭代都有特定的用例、場景以及其他分配的工作項(xiàng)目。這些信息都在迭代計(jì)劃中有所體現(xiàn)并且設(shè)定基線。評(píng)審與核準(zhǔn)計(jì)劃可以作為細(xì)化階段的出口標(biāo)準(zhǔn)的一部分。對(duì)于非常小的短期項(xiàng)目來說，您可以將細(xì)化階段的迭代與起始過程和構(gòu)建過程合并。關(guān)鍵性的活動(dòng)仍然可以進(jìn)行，但是迭代計(jì)劃和評(píng)審所需的資源都會(huì)有所減少。 構(gòu)建階段
構(gòu)建的目標(biāo)是完成系統(tǒng)開發(fā)。構(gòu)建階段從某種意義上來看是一個(gè)制造過程，其中重點(diǎn)工作就是管理資源、控制操作以優(yōu)化成本、日程和質(zhì)量。從這個(gè)意義上來講，管理理念應(yīng)該進(jìn)行一個(gè)轉(zhuǎn)換，從起始階段和細(xì)化階段的知識(shí)產(chǎn)權(quán)開發(fā)轉(zhuǎn)換到構(gòu)建和交付階段的部署產(chǎn)品的開發(fā)。 XP 側(cè)重構(gòu)建階段。構(gòu)建階段是編寫產(chǎn)品代碼的階段。XP所有階段的目的都是為了進(jìn)行計(jì)劃，但是 XP 的關(guān)注焦點(diǎn)是構(gòu)建代碼。 構(gòu)建階段的每次迭代都具有三個(gè)關(guān)鍵活動(dòng)： 管理資源與控制過程。每個(gè)人都需要了解自己的工作內(nèi)容和時(shí)間。您必須保證工作負(fù)荷不會(huì)超過您的能力，而且工作可以按計(jì)劃進(jìn)行。 開發(fā)與測試組件。您構(gòu)建組件以滿足迭代中用例、場景以及其他功能的需要。您對(duì)其進(jìn)行單元測試和集成測試。 對(duì)迭代進(jìn)行評(píng)估。在迭代完成時(shí)，您需要判斷是否已經(jīng)達(dá)到了迭代的目標(biāo)。如果沒有，您必須重新劃分優(yōu)先級(jí)并管理范圍以確保能夠按時(shí)交付系統(tǒng)。 不同類型的系統(tǒng)需要使用不同的技術(shù)。RUP 為軟件工程師提供了不同的指導(dǎo)，以幫助他們創(chuàng)建恰當(dāng)?shù)慕M件。以用例和補(bǔ)充（非功能）需求的形式提出的需求是足夠詳細(xì)的，可以使工程師開展工作。RUP 中的若干活動(dòng)為設(shè)計(jì)、實(shí)施和測試不同種類的組件提供了指南。一名有經(jīng)驗(yàn)的軟件工程師不需要詳細(xì)查看這些活動(dòng)。經(jīng)驗(yàn)稍欠缺一些的工程師可以通過最佳實(shí)踐獲得很大的幫助。每個(gè)團(tuán)隊(duì)成員都可以按需要深入研究過程或者只是稍微了解一下。不過，他們都參照一個(gè)單獨(dú)的過程知識(shí)基礎(chǔ)。 在 XP 中，"故事"驅(qū)動(dòng)實(shí)施過程。在 Extreme Programming Installed 一書中，Jeffries等人認(rèn)為"故事"是程序員的"會(huì)話承諾"（promises for conversation）。 持續(xù)有效的交流大有裨益。雖然總是需要澄清一些細(xì)節(jié)，如果"故事"不夠詳細(xì)，而使程序員不能完成他們大部分工作，那么可以說"故事"還沒有就緒。用例必須足夠詳細(xì)以方便程序員實(shí)施。在許多情況下，程序員會(huì)幫助編寫用例的技術(shù)細(xì)節(jié)。Jeffries 等人認(rèn)為，會(huì)話應(yīng)該記錄在文檔中并且附加到"故事"中。RUP 也同意這個(gè)觀點(diǎn)，除了以用例規(guī)格說明的形式，可以按需要使用非正式的形式。捕獲并管理會(huì)話的結(jié)果是您必須管理的任務(wù)。 XP 的長處在于構(gòu)建階段。對(duì)于大多數(shù)團(tuán)隊(duì)來說，都存在適用于他們的"智慧與指南的結(jié)晶"。XP 中最顯著的實(shí)踐包括： 測試--程序員不斷地隨著代碼的開發(fā)編寫測試。測試反映了"故事"。XP提倡您首先編寫測試，這是一項(xiàng)優(yōu)秀的實(shí)踐，因?yàn)樗梢云仁鼓羁痰乩斫?故事"，并且在必要的地方提出更多的問題。不論在編寫代碼之前還是之后，一定要編寫測試。將它們加入到您的測試包中，并且保證每次代碼變更時(shí)都運(yùn)行測試。 重構(gòu)--不斷重構(gòu)系統(tǒng)的結(jié)構(gòu)而不改變其行為，可以使其更加簡單或靈活。您需要判斷對(duì)您的團(tuán)隊(duì)來說是否存在一個(gè)較好的實(shí)踐。簡單與復(fù)雜的判別否因人而異。有這樣一個(gè)例子，一個(gè)項(xiàng)目中的兩個(gè)很聰明的工程師每晚都要重寫對(duì)方的代碼，因?yàn)樗麄冋J(rèn)為對(duì)方的代碼過于復(fù)雜。這產(chǎn)生了一個(gè)副作用，也就是他們總是干擾第二天其他成員的工作。測試是有幫助的，但是如果他們之間不陷入代碼之爭的話，那么團(tuán)隊(duì)的處境就會(huì)更好一些。 結(jié)對(duì)編程--XP 認(rèn)為結(jié)對(duì)編程可以在更短的時(shí)間內(nèi)創(chuàng)建出更好的代碼。有證據(jù)表明這是正確的 。如果您遵照這項(xiàng)實(shí)踐，就需要考慮許多人文與環(huán)境的因素。程序員愿意對(duì)此進(jìn)行嘗試嗎？您的物理環(huán)境可以滿足這種情況嗎，即有足夠的空間使兩個(gè)程序員在一個(gè)單獨(dú)工作站中有效地工作？您如何對(duì)待遠(yuǎn)程工作或者在其他地點(diǎn)工作的程序員？ 持續(xù)集成--集成與構(gòu)建工作需要持續(xù)進(jìn)行，可能每天不止一次。這是一種確保代碼結(jié)構(gòu)完整的很好的方式，它還允許在集成測試過程中進(jìn)行持續(xù)的質(zhì)量監(jiān)控。 集體代碼所有權(quán)--任何人都可以隨時(shí)修改任何代碼。XP 依賴這樣一個(gè)事實(shí)，即一組好的單元測試將會(huì)減少這項(xiàng)實(shí)踐的風(fēng)險(xiǎn)。讓大家將每一件事都搞清楚的好處不能局限在一定的尺度上--是 1 萬行代碼、2 萬行代碼還是一定要少于 5 萬行？ 簡單設(shè)計(jì)--隨著重構(gòu)過程的進(jìn)行，需要不斷地修改系統(tǒng)設(shè)計(jì)使其變更簡單。再一次重申，您需要判斷這項(xiàng)工作進(jìn)行到何種程度才恰好合適。如果您在細(xì)化階段中花費(fèi)了必要霎時(shí)間來設(shè)計(jì)構(gòu)架，我們相信簡單的設(shè)計(jì)將會(huì)很快完成并且很快變得穩(wěn)定。 代碼標(biāo)準(zhǔn)--這一直都是一項(xiàng)良好實(shí)踐。標(biāo)準(zhǔn)是什么都沒關(guān)系，只要您使用它們而且每個(gè)人都認(rèn)可就可以。 RUP 與 XP 都認(rèn)為您必須管理（和控制）迭代過程。衡量標(biāo)準(zhǔn)可以提供較好的計(jì)劃信息，因?yàn)樗鼈兛梢詭椭x擇對(duì)于您的團(tuán)隊(duì)來說什么是最適合的。需要衡量三件事：時(shí)間、規(guī)模和缺陷。這樣您就可以獲得所有類型您所感興趣的統(tǒng)計(jì)數(shù)字。XP 為您提供簡單的衡量標(biāo)準(zhǔn)來判斷進(jìn)展并且預(yù)測成果。這些衡量標(biāo)準(zhǔn)圍繞著完成的"故事"數(shù)量、通過測試的數(shù)量以及統(tǒng)計(jì)中的趨勢這些問題。XP 為使用最少量的衡量標(biāo)準(zhǔn)做出了一個(gè)優(yōu)秀的表率，因?yàn)椴榭刺嗖⒉灰欢〞?huì)增加項(xiàng)目成功的機(jī)會(huì)。RUP 為您提供了對(duì)于您可以衡量的內(nèi)容以及如何衡量的指導(dǎo)，并且舉了有關(guān)衡量標(biāo)準(zhǔn)的例子。在所有的情況中，衡量標(biāo)準(zhǔn)必須簡單、客觀、易于搜集、易于表達(dá)，并且不易產(chǎn)生誤解。 在構(gòu)建階段的迭代過程中將會(huì)產(chǎn)生哪些工件呢？這取決于迭代是處于構(gòu)建階段的早期還是后期，您可以創(chuàng)建以下工件： 組件--組件代表了軟件代碼中的一部分（源代碼、二進(jìn)制代碼或者可執(zhí)行程序），或者包含信息的文件，例如，一個(gè)啟動(dòng)文件或者一個(gè) ReadMe 文件。組件還可以是其他組件的聚合，例如由幾個(gè)可執(zhí)行程序組成的應(yīng)用程序。 培訓(xùn)資料--如果系統(tǒng)的用戶界面比較復(fù)雜，那么請?jiān)谟美幕A(chǔ)上盡早編寫用戶手冊和其他培訓(xùn)資料的初稿。 部署計(jì)劃--客戶需要一個(gè)系統(tǒng)。部署計(jì)劃描述了一組安裝、測試并且有效地向用戶交付產(chǎn)品所需的任務(wù)。對(duì)于 以Web 為中心的系統(tǒng)來說，我們已經(jīng)發(fā)現(xiàn)，部署計(jì)劃的重要性又提高了。 交付階段迭代計(jì)劃--臨近交付時(shí)，您需要完成并且評(píng)審交付階段迭代計(jì)劃。 代碼完整嗎？
認(rèn)為代碼就是設(shè)計(jì)并且設(shè)計(jì)也就是代碼。代碼與自身總是一致的，這一點(diǎn)是千真萬確的。我們認(rèn)為花費(fèi)精力進(jìn)行設(shè)計(jì)并且溝通設(shè)計(jì)是很值得的，而不僅僅是創(chuàng)建代碼。下面的小故事會(huì)說明這一點(diǎn)。 RUP 與 XP 間的差異除了建立構(gòu)架的方法以外，還包括其他方面的不同。其中一點(diǎn)就是關(guān)于設(shè)計(jì)概念的溝通方式。XP 一名工程師曾有兩次這樣的軟件項(xiàng)目經(jīng)歷，設(shè)計(jì)體現(xiàn)在代碼中，并且只能在代碼中找到設(shè)計(jì)信息。這兩個(gè)項(xiàng)目都是關(guān)于編譯器的：一個(gè)是改進(jìn)與維護(hù)用于 Ada 編譯器的優(yōu)化程序，另一個(gè)項(xiàng)目是將一個(gè)編譯器的前端移植到一個(gè)新的平臺(tái)上，并且連接一個(gè)第三方的代碼生成器。 編譯器技術(shù)是比較復(fù)雜的，但也是廣為人知的。在這兩個(gè)項(xiàng)目中，該工程師想要概覽編譯器（或者優(yōu)化程序）的設(shè)計(jì)和實(shí)施。在每個(gè)案例中，他都接到一堆源代碼清單，大概有幾英尺厚，而且被告知"查看這些信息"。他本應(yīng)被提供一些帶有支持性文字的構(gòu)建很好的圖。優(yōu)化程序的項(xiàng)目沒有完成。但是編譯器項(xiàng)目確實(shí)取得了成功，由于在代碼開發(fā)過程中進(jìn)行了廣泛的測試，所以代碼質(zhì)量很高。這位工程師花費(fèi)了數(shù)天時(shí)間研究調(diào)試器中的代碼以弄明白其作用。個(gè)人的損失尚在其次，團(tuán)隊(duì)的損失代價(jià)就更不值得。我們并沒有按 XP 所示的那樣在 40 小時(shí)后完成開發(fā)，我們反而花費(fèi)了大量個(gè)人努力來完成工作。 只開發(fā)代碼帶來的主要問題就是無論代碼文檔編寫得多么好，它都沒有告訴您它本身要解決的問題，它只提供了問題的解決方案。一些需求文檔在最初用戶和開發(fā)人員繼續(xù)工作很長時(shí)間以后，仍然可以很好地解釋項(xiàng)目的原始目標(biāo)。為了維護(hù)系統(tǒng)，您往往需要了解最初項(xiàng)目團(tuán)隊(duì)的設(shè)計(jì)目標(biāo)。一些高級(jí)設(shè)計(jì)文檔都是相似的--代碼經(jīng)常沒有經(jīng)過高度的抽象，所以無法提供任何信息以表明整體的系統(tǒng)能夠?qū)崿F(xiàn)什么功能。在面向?qū)ο蟮南到y(tǒng)中，這一點(diǎn)尤其是正確的，因?yàn)閮H僅查看里面的類文件是很難甚至無法得出執(zhí)行線程。設(shè)計(jì)文檔指導(dǎo)您在后期出現(xiàn)問題時(shí)該查看的內(nèi)容--在后期經(jīng)常會(huì)出現(xiàn)問題。 這個(gè)故事說明花費(fèi)時(shí)間創(chuàng)建與維護(hù)設(shè)計(jì)文檔確實(shí)會(huì)有所幫助。這可以降低誤解的風(fēng)險(xiǎn)，并且加速開發(fā)過程。XP 的方式就是花費(fèi)幾分鐘勾畫出設(shè)計(jì)的大概內(nèi)容或者使用 CRC 卡片。 但是團(tuán)隊(duì)不主張這樣，而只是進(jìn)行代碼開發(fā)。他們有一個(gè)隱含的假設(shè)，那就是任務(wù)很簡單，我們已經(jīng)知道該如何進(jìn)行了。即使我們成功地完成了任務(wù)，那么下一個(gè)新來的人可能就不會(huì)如此幸運(yùn)。RUP建議您多花費(fèi)一些時(shí)間創(chuàng)建并維護(hù)這些設(shè)計(jì)工件。 交付階段
交付階段的焦點(diǎn)就是確保軟件對(duì)于最終用戶是可用的。交付階段包括為發(fā)布進(jìn)行產(chǎn)品的測試，在用戶反饋的基礎(chǔ)上做微小的調(diào)整等幾方面內(nèi)容。在生命周期的這個(gè)時(shí)刻，用戶反饋主要集中在精確調(diào)整產(chǎn)品、配置、安裝，以及可用性等問題上。 較早發(fā)布、經(jīng)常性發(fā)布都是很好的辦法。但是，我們通過發(fā)布要達(dá)到的目的是什么呢？XP 沒有清楚地解釋這個(gè)問題，也沒有處理發(fā)布商業(yè)軟件所必須制造問題。在內(nèi)部項(xiàng)目中，您可以為解決這些問題找到捷徑，但是即使這樣，您仍然需要編輯文檔、員工培訓(xùn)等工作。那么技術(shù)支持與變更管理又如何呢？希望現(xiàn)場客戶控制這些內(nèi)容，這是可行的嗎？Bruce Conrad 在他的 XP 的 InfoWorld 評(píng)論 中指出用戶并不希望得到的軟件總是在持續(xù)變更。您必須對(duì)快速變更軟件的利益和變更的劣勢及可能帶來的不穩(wěn)定性進(jìn)行權(quán)衡。 當(dāng)您決定發(fā)布的時(shí)候，您必須為最終用戶提供比代碼多得多的東西。交付階段的活動(dòng)和工件會(huì)指導(dǎo)您完成本部分軟件開發(fā)過程。這些活動(dòng)主要是為了向您的客戶提供可用的產(chǎn)品。交付階段的關(guān)鍵活動(dòng)如下： 確定最終用戶支持資料。該活動(dòng)比較簡單，您只需提供一個(gè)清單即可。但是務(wù)必要確保您的組織已準(zhǔn)備好對(duì)客戶進(jìn)行技術(shù)支持。 在用戶的環(huán)境中測試可交付的產(chǎn)品。如果您能夠在公司內(nèi)部模擬用戶環(huán)境，那是最好不過的。否則，就到客戶的公司去，安裝軟件并且保證其可以運(yùn)行。您一定不想尷尬地回答客戶："但是在我們的系統(tǒng)上工作很正常。" 基于用戶反饋精確調(diào)整產(chǎn)品。如果可能的話，在您向有限數(shù)量客戶交付軟件時(shí)計(jì)劃一次或者多次 Beta 測試周期。如果進(jìn)行該測試，那么就需要對(duì) Beta 測試周期進(jìn)行管理，并且考慮您"收尾工作"中的客戶反饋。 向最終用戶交付最終產(chǎn)品。對(duì)于不同類型的軟件產(chǎn)品和發(fā)布版本，需要處理許多有關(guān)打包、制造和其他產(chǎn)品問題。您肯定不會(huì)僅僅將軟件復(fù)制到一個(gè)文件夾中，然后向客戶發(fā)一封郵件告訴他們軟件已經(jīng)到位了。 與其他階段一樣，過程的格式與復(fù)雜度都有所不同。不過，如果您沒有注意部署細(xì)節(jié)，那么可能導(dǎo)致數(shù)周或數(shù)月的良好開發(fā)工作前功盡棄，從而在進(jìn)入目標(biāo)市場時(shí)以失敗告終。 在交付階段中您可以生成若干工件。如果您的項(xiàng)目涉及到將來的發(fā)布（有多少項(xiàng)目沒有涉及到呢？），那么您就應(yīng)該開始為下次發(fā)布確定功能和缺陷。對(duì)于任何項(xiàng)目，下列工件都至關(guān)重要： 部署計(jì)劃--完成您始于構(gòu)建階段的部署計(jì)劃并且將其作為交付的路線圖。 版本注釋--它是一個(gè)比較少見的軟件產(chǎn)品，不包含對(duì)最終用戶至關(guān)重要的指令?？梢詫?duì)其做出計(jì)劃，對(duì)于注釋要有一個(gè)可用的、一致的格式。 交付階段資料與文檔--這類資料可以采取很多形式。您可以在線提供所有內(nèi)容嗎？您會(huì)進(jìn)行指導(dǎo)嗎？您的產(chǎn)品幫助完整并且可用嗎？不要認(rèn)為您所了解的，客戶也同樣了解。您的成功就在于幫助您的客戶取得成功。 結(jié)束語
構(gòu)建軟件的工作遠(yuǎn)遠(yuǎn)多于編寫代碼所工作。一個(gè)軟件開發(fā)過程必須集中處理向用戶發(fā)布高質(zhì)量軟件的所有必需活動(dòng)。一個(gè)完整的過程不必是龐大的。我們通過集中論述項(xiàng)目中的主要活動(dòng)和工件，已經(jīng)向您展示了如何進(jìn)行一個(gè)小型但是完整的過程。如果執(zhí)行某項(xiàng)活動(dòng)或者創(chuàng)建某個(gè)工件對(duì)于緩解項(xiàng)目中的風(fēng)險(xiǎn)是有幫助的，那么就請進(jìn)行。您可以按需要為您的項(xiàng)目團(tuán)隊(duì)和組織使用或多或少的過程和格式。 RUP 和 XP 并不必是互相排斥的。通過結(jié)合使用這兩種方法，您完全可以得到一個(gè)過程，幫助您比現(xiàn)在更快地交付更高質(zhì)量的軟件。Robert Martin 描述了一個(gè)叫做 dX 的過程，他將其作為 RUP 的附屬品 。它就是一個(gè)從 RUP 框架中構(gòu)建的過程的實(shí)例。 一個(gè)優(yōu)秀的軟件過程可以使用經(jīng)業(yè)界驗(yàn)證的最佳實(shí)踐。最佳實(shí)踐已經(jīng)在真實(shí)的軟件開發(fā)組織中使用，并且經(jīng)歷了時(shí)間的考驗(yàn)。XP 是目前廣為關(guān)注的方法。它以代碼為中心，并提供了一項(xiàng)承諾：花費(fèi)最少的過程開銷得到最大的生產(chǎn)力。XP 中的許多技術(shù)值得在恰當(dāng)?shù)那闆r中考慮和采用。 XP 關(guān)注"故事"、測試和代碼--它以一定的深度討論了計(jì)劃，但沒有詳細(xì)闡述如何獲取計(jì)劃。XP 意味著您可以完成其他一些工作，例如"使用一些卡片進(jìn)行 CRC 設(shè)計(jì)或者草擬某種 UML……"或者"請不要生成并不使用的文檔或者其他工件"，但只是一帶而過。RUP 希望您在定制和更新開發(fā)計(jì)劃時(shí)，僅僅考慮創(chuàng)建有用和必須的東西，并且指出了這些東西該是什么。 RUP 是一個(gè)可以處理整個(gè)軟件開發(fā)周期的過程。它關(guān)注最佳實(shí)踐，并且經(jīng)過了數(shù)千個(gè)項(xiàng)目的洗禮。我們鼓勵(lì)研究和發(fā)明新的技術(shù)以產(chǎn)生最佳實(shí)踐。隨著新的最佳實(shí)踐嶄露頭腳，我們希望將它們納入 RUP 中。 附錄：Rational Unified Process
Rational Unified Process，或者簡稱 RUP，提供了軟件開發(fā)的規(guī)律性方法。它是由IBM Rational開發(fā)并維護(hù)的過程產(chǎn)品。它為來同類型的項(xiàng)目提供了幾種即裝即用的路線圖。RUP 還提供了一些信息，幫助您在軟件開發(fā)過程中使用其他 Rational 工具，但是它不要求將 Rational 工具有效地應(yīng)用于整個(gè)組織，您也可以將 Rational 工具與其他供應(yīng)商的產(chǎn)品進(jìn)行集成。 RUP 為軟件項(xiàng)目所有方面提供了指導(dǎo)。并不需要您執(zhí)行任何特定的活動(dòng)或者創(chuàng)建任何特定的工件。它只為您提供信息和指南，您可以決定將哪些應(yīng)用于您的組織。如果沒有特定的路線圖適合您的項(xiàng)目或者組織，RUP 還提供了一些指南來幫助您量身定做你的過程。 RUP 強(qiáng)調(diào)采用現(xiàn)代軟件開發(fā)的一些最佳實(shí)踐，作為一種降低開發(fā)新軟件所帶來的內(nèi)在風(fēng)險(xiǎn)的方式。這些最佳實(shí)踐包括： 1． 迭代開發(fā)
2． 管理需求
3． 使用基于組件的構(gòu)架
4． 可視建模
5． 持續(xù)的質(zhì)量驗(yàn)證
6． 控制變更 這些最佳經(jīng)驗(yàn)融合到 Rational Unified Process 的以下定義中： 角色--執(zhí)行的系列活動(dòng)和擁有的工件。
學(xué)科--軟件工程中的關(guān)鍵領(lǐng)域，例如需求、分析與設(shè)計(jì)、實(shí)施與測試。
活動(dòng)--工件生成與評(píng)估方式的定義。
工件--在執(zhí)行活動(dòng)中所使用的、生成的或修改的工作產(chǎn)品。 RUP 是一個(gè)迭代過程，確定了任何軟件開發(fā)項(xiàng)目的四個(gè)階段。隨著時(shí)間的推進(jìn)，每個(gè)項(xiàng)目都要經(jīng)歷起始階段、細(xì)化階段、構(gòu)建階段和交付階段。每個(gè)階段包括一次或多次迭代，其中您可以生成可執(zhí)行文件，但是系統(tǒng)可能不完整（可能起始階段除外）。在每次迭代過程中，您以不同的細(xì)節(jié)級(jí)別執(zhí)行幾個(gè)學(xué)科中的活動(dòng)。下文是 RUP 的概述圖。 RUP 概覽圖
 The Rational Unified Process, An Introduction, Second Edition 一書是 RUP 的好的概述。您可以在 Rational 的 Web 站點(diǎn) www.rational.com 上找到更進(jìn)一步的信息和對(duì)于 RUP 的評(píng)價(jià)。 附錄：極限編程
極限編程（XP）是由 Kent Beck 在 1996 年開發(fā)的一種軟件開發(fā)學(xué)科。它基于四個(gè)價(jià)值：溝通、簡單、反饋和勇氣。它強(qiáng)調(diào)客戶與開發(fā)團(tuán)隊(duì)成員的持續(xù)溝通，在開發(fā)進(jìn)程中設(shè)立一名現(xiàn)場客戶。該現(xiàn)場客戶決定創(chuàng)建的內(nèi)容和順序。通過持續(xù)重構(gòu)代碼并創(chuàng)建最小的非代碼工件集合而體現(xiàn)簡單。許多短期發(fā)布和持續(xù)單元測試建立了反饋機(jī)制。勇氣意味著完成正確的事情，即使并不是最流行的事情。它還意味著誠實(shí)面對(duì)您能做的和不能做的事情。 12 個(gè) XP 實(shí)踐為這四個(gè)價(jià)值提供支持。它們是： 有計(jì)劃的開發(fā)：通過結(jié)合使用優(yōu)先級(jí)"故事"和技術(shù)估算，確定下一版本的功能。 小版本：以小的增量版本經(jīng)常向客戶發(fā)布軟件。 隱喻：隱喻是一個(gè)簡單、共享的"故事"或描述，說明系統(tǒng)如何工作。 簡單設(shè)計(jì)：通過保持代碼簡單從而保證設(shè)計(jì)簡單。不斷的在代碼中尋找復(fù)雜點(diǎn)并且立刻進(jìn)行移除。 測試：用戶編寫測試內(nèi)容以對(duì)"故事"進(jìn)行測試。程序員編寫測試內(nèi)容來發(fā)現(xiàn)代碼中的任何問題。在編寫代碼前先編寫測試內(nèi)容。 重構(gòu)：這是一項(xiàng)簡化技術(shù)，用來移除代碼中的重復(fù)內(nèi)容和復(fù)雜之處。 結(jié)對(duì)編程：團(tuán)隊(duì)中的兩個(gè)成員使用同一臺(tái)計(jì)算機(jī)開發(fā)所有的代碼。一個(gè)人編寫代碼或者驅(qū)動(dòng)，另一個(gè)人同時(shí)審查代碼的正確性和可理解性。 集體代碼所有權(quán)：任何人都擁有所有的代碼。這就意味這每個(gè)人都可以在任何時(shí)候變更任何代碼。 持續(xù)集成：每天多次創(chuàng)建和集成系統(tǒng)，只要任何實(shí)現(xiàn)任務(wù)完成就要進(jìn)行。 每周 40 個(gè)小時(shí)：程序員在疲勞時(shí)無法保證最高效率。連續(xù)兩周加班是絕對(duì)不允許的。 現(xiàn)場客戶：一名真實(shí)的客戶全時(shí)工作于開發(fā)環(huán)境中，幫助定義系統(tǒng)、編寫測試內(nèi)容并回答問題。 編碼標(biāo)準(zhǔn)：程序員采用一致的編碼標(biāo)準(zhǔn)。 目前有三本描述 XP 的書： 1.解析極限編程（eXtreme Programming Explained）
2.極限編程實(shí)施（Extreme Programming Installed）
3.規(guī)劃極限編程（Planning Extreme Programming） 一些 Web 站點(diǎn)上也有關(guān)于XP的進(jìn)一步信息。 參考資料 - 您可以參閱本文在 developerWorks 全球站點(diǎn)上的 英文原文。
|