這篇文章實際上是由三篇文章組合而成的。它們為在 IBM® Rational® Unified Process® 或者簡稱為 RUP® 團隊上面應用敏捷策略提供了被證明為行之有效的建議。本文是由 Mark Lines、Joshua Barnes、以及 Julian Holmes 分別撰寫的，它們都是 Unified Process Mentors （www.upmentors.com）的共同創辦人。這三位已經通過書籍指導了全世界成千上萬名軟件開發方面的從業者，舉辦了幾十場研討會，撰寫了多部著作，作為咨詢顧問和用戶組的主席人等。他們工作于遍及世界各地的機構中，將他們的處理過程理論付諸實踐，通過實例引導并且通過結構的改變驅動成功。
我的經驗是，好的 RUP 就是敏捷的 1 并且包含了許多成功地測量敏捷技術所需要的建議。第一篇文章“將規則引入到敏捷的生命周期之中”是由 Mark Lines 撰寫的，它展示了 RUP 需求管理技術和風險驅動開發周期是如何將所需要的規則性水平引入到許多機構中的，并且還不失敏捷方法的特點之一：靈活性。作者認為您并不希望需求在開發周期的后期發生根本上的變更，而前期的一小部分投資能夠從根本上減少您的開銷、進度、以及整個項目所面臨的風險。第二篇文章“在大型機構中將敏捷性引入 RUP 的策略”是由 Joshua Barnes 撰寫的，它從一個相反的方向對待軟件處理過程中的挑戰。它提出了一些快速提高您的基于 RUP 處理過程的方法——許多項目是以頭腦中固定的目標開始的，并且在此基礎上進行剛性的調整，盡管實際情況是：該團隊在項目進展到一半的時候意識到他們能夠不再受到固定目標的束縛，因為該目標并不是固定的，而規則也并不是嚴格的。第三篇文章“地理上分布式的敏捷團隊：使個體以及它同處理過程和工具之間的交互發揮作用是由 Julian Holmes 撰寫的，它概述了在一個分布式的敏捷團隊內部提高協作的策略。在一個項目團隊內部完成有效的協作對于一個共處一地的團隊是一項很艱巨的挑戰，所以就更不用對于一個地理上分布的團隊了。Julian 提出開發一個協作團隊文化的建議，同時保持方法、交付和管理共享工作產品的一致性。
將規則引入到敏捷的生命周期之中
由 Mark Lines 撰寫
敏捷性項目能夠被無止境地迭代下去，只有當耗盡預算時該項目才會被結束。在早期迭代和不合理的需求混合中所執行的特性通常是麻煩的制造者。RUP 通過在早期逐出需求的不確定性將結構添加到一個敏捷方法中，并且隨著項目的不斷推進很自然地繃緊了處理過程的控制。
我在敏捷項目中所看到的一個不適宜的傾向就是項目從一個迭代到另一個迭代，幾乎看不到盡頭。某些項目經理（PM）好像是忘記了傳統的 PM 對于“客戶永遠是正確的”這一敏捷法則的嚴格性。這導致從迭代到迭代的持續的需求變更。通常，隨著需求條目從本次迭代中的執行棧中移除，相等數量的或者更大數量的工作條目就會被添加回這個棧中。時間和預算被快速地消耗殆盡，而大量待處理的需求依然被留在那里。
RUP 項目的兩個階段
RUP 確實能夠在這些情況下幫助團隊認識到所有的迭代并不是完全相同的。Walker Royce 將一個項目的開發周期描述為兩個階段。 2 第一個階段大約占到整個開發周期的 20% 到 40%，它將其稱之為 Engineering （工程）階段。這個階段是由統一處理過程（UP）的 啟始和精化 階段所組成的。工程階段表現為項目所有方面的混合，例如：計劃、需求、體系結構和代碼。這是自然的，也是意料之中的，業務和技術出資方都努力去理解系統的解決方案是什么，以及如何將它實現。
Royce 將開發周期的第二個階段描述為產品化階段，它是由 UP 開發周期的構建和產品化 階段所組成的。它負責使用在前面的工程階段中被證明為有效的技術來執行剩余的需求（大約 60% 到 80%）。
適應項目期間變更控制的嚴格性
在工程階段期間，我們試圖避免通過改變控制程序加重用戶的負擔。反過來，他們也應當嚴格遵守委托事項，直到團隊實現了某些需求為止，因此得到了一個推斷嚴格的委托事項的基本線。將這一行為始終銘記在心中，根據用戶的需要（無條件的）在早期迭代中向棧中添加、改變、和區分需求的優先次序。
通過在精化 中增加同軟件的風險方面相關的功能性，我們能夠移除大量的和項目相關的不確定性，例如：理解和建立這些需求。同需求的不確定性相關的風險能夠通過原型、圖板、可視化建模、以及規則示范等技術被降低。關于范圍和進度的委托事項統稱在這個階段的末尾被期待。這種方法的好處就是相對于傳統的瀑布式方法來說，用戶會在更晚的時候才被要求提交需求。他們有時間在我們進入嚴格的變更控制程序之前看到軟件的進展情況，Scott Ambler 喜歡將它們稱之為“變更防御”程序。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
