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