本文來自于 Rational Edge：作者提出了一項將 Rational 統一過程進行剪裁的技術，以適應軟件項目具體需求，即使外聘的 RUP 專家不熟悉本公司及其文化。
設想您是一個 IT 部門的經理，該部門的軟件開發職員在滿足市場需求的過程中需要更多靈活性。過程的級別應該通過開發的范圍和分布、項目的技術復雜度，及文檔的需求進行平衡。您采用的方法應該著重于在早期減少 風險，包括技術風險。通過引入迭代開發，您將爭取增加最終用戶的滿意度。要滿足這些需求，您和您的開發 團隊已經決定在您未來的項目中使用 Rational Unified Process?，或稱 RUP?。您已經做出了一個重要的決定，但現在您有更多的決定要做，尤其對不熟悉 RUP 的 項目經理來說是個挑戰。
進退兩難
RUP 包含一個工件擴展庫，其中有許多您不需要的東西。沒有一個組織需要全部的內容。事實上，RUP 最新版本（7.0）的第一個關鍵原則是“使過程適應組織和項目”，所以您需要將 RUP 按您的組織及其項目的大小和需求進行剪裁。這樣剪裁的結果是 RUP 的一部分，被稱為開發案例（development case）。在開發案例中，您將描述在項目中使用的所有活動、角色、工件和模板。
每個所選擇的支持工件（可交付的）都將需要 資源來生產它。向開發案例中添加的每一項元素都應該根據期望的效益進行平衡，您需要考慮的方面包括：時間節省、質量獲得，或為項目評估、計劃和范圍管理提供的基礎。換句話說，開發案例太大將會不必要地浪費項目的錢。問題是：您如何繼續讓您的開發案例正常？您打算自己找出如何剪裁 RUP 的方法嗎，或者您打算從外面雇傭一個 RUP 顧問或過程工程師嗎？自己處理 RUP 的裁剪，讓您的團隊等著您的指導，在缺乏剪裁 RUP 的內行經驗的情況下，這樣做是很困難的。您將不得不花費一些時間來找出哪個工件要被略去、哪個要被添加，并且確定應該如何用它們來適合您的項目，或組織。事實上，您需要了解 RUP 的全部才能夠以合理的方式對它進行剪裁，因此您將在將來的六個月中非常繁忙。
另一種方法，您可以雇傭一個 RUP 顧問，一個可以在什么工件是強制的，以及在特定的情況下只需要哪個工件的方面指導您的人。顧問可以幫助按照您的需求修改 RUP 模板，并最恰當地將它們用于創建有用的工件工具。但是外部的 RUP 顧問對您的業務的了解是有限的，更不要提您的組織或公司的文化。這意味著顧問將使用相當多（昂貴）的時間了解您的業務 —— 否則，結果將是剪裁出來的開發案例并不符合您公司的需求和特性。
我們已經扮演過外部的 RUP 顧問的角色，并且為各種各樣的公司成功地定義了開發案例。作為顧問，我們相信剪裁 RUP 的外部專家經驗的價值，并且我們已經開發了幫助加速剪裁過程，并且與此同時描述組織具體需求的技術。我們將介紹兩個概念：職責矩陣和工件流。
職責矩陣
我們基于建立“什么”和“誰”利用面向目標的方法來剪裁 RUP。我們開始研究項目應該交付 什么 （哪些工件）。由工件開始的一個很大的優勢是工件是有形的東西。通過觀察哪些工件獲得的基線狀態（已經被正式地批準）可以很容易地檢查項目進展。
工件必須總是有用的。這可能聽起來微不足道，但是在許多情況下，我們發現了由那些不知道工件用途的人撰寫的工件。我們經常提出的問題是，“如果沒有工件被生成，將會出現什么問題？”這個問題的答案澄清了工件的目的。如果您不能找到此問題的具體答案，那么有很大可能性此工件是多余的。
在決定生成哪個工件之后，我們研究 誰 （哪個角色）負責創建每個工件。我們將工件、角色和職責一起放入我們的職責矩陣中。我們在最左邊的列放工件，在最頂端的行放角色。在交叉部分我們放上表示各種職責的符號。這就形成了如圖 1 所示的矩陣。
圖 1：職責矩陣實例
工件的作者不僅涉及創建此工件的那個人。要完成矩陣，我們還要研究哪些角色支持創建過程，以及哪角色些負責正式地接收一個工件。通過訪談、討論會和評論的方式能夠支持角色給出輸入。當然，我們能夠識別出細粒度的職責，但這很少有用。注意，負責工件（將其寫在紙上或匯集工件）的角色是實際的作者。由于這涉及特殊的技能，因此該職責不容易委托。例如，我們要注意的是不要將太多的工件分配給項目經理。他或她應該只撰寫并負責管理工件。
職責矩陣將使簡化我們得到適當的開發案例的過程。它提供了許多優點：
◆我們可以在所有涉眾出席的一個（或多個） 會議上填寫職責矩陣。這使其成為每個人都同意的聯合工作。
◆我們不需要對業務有很多的了解來支持職責矩陣的創建。
◆職責矩陣可以被用來作為開發案例的一部分，以非常簡潔且易讀的方式提供對所剪裁的 RUP 的主要構建模塊的概述。
填寫職責矩陣
職責矩陣可以通過不同的方法填寫。我們將看一看其中的三種。
策略 1：從 100% RUP 開始
通常的起始點是一組 標準的 RUP 工件和角色。RUP 顧問對組織中需要什么 RUP 工件和角色進行有根據的推測，并填寫職責矩陣中的所有職責。該職責矩陣隨后用作與涉眾進行討論的基礎。
然而，該方法有兩個不利方面：
與公司經驗不相關。職責矩陣沒有使用涉眾熟悉的角色和工件。
從涉眾的觀點出發，RUP 引入了所有的新詞匯。因此職責矩陣很難讓人理解。這各問題可以通過給人們具體的 RUP 培訓，按照開發案例來剪裁來解決。
[1] [2]
