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