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