學習案例:使用RUP作為方法框架

Maureen Field, Group Leader, IT Project Office, Ford Credit
Venkat Alladi, Process Methodologist, Ciber, Inc.

2004 年 4 月

本文來源于 2003 年 Rational 用戶大會的一個演講稿，這個學習案例的研究討論了一個公司成功的開發和部署以 IBM RUP 作為過程框架的迭代開發方法的真實經驗。實現一個標準的過程和這個過程為開發組織提供的未來機會也將在本文中被關注。

介紹

本文被劃分為五個部分。首先是一個簡要的介紹，然后我們將討論我們的開發工作，隨后我們將討論我們的部署工作、經驗教訓和對本文的總結。

這個案例研究是一個現實世界的真實的經歷，它是關于我們的團隊如何成功的開發和部署一個使用 RUP® 作為過程框架的迭代開發的方法的。這是福特公司和福特金融信貸公司共同工作的結果。福特金融信貸公司是福特公司的一個全資控股子公司，并且是汽車金融的最大供應商。我們在四十個國家為超過 11,000 個經銷商提供車輛金融服務，并且自從 1959 年以來我們已經為超過五千萬量汽車提供了貸款服務。我們以福特金融而聞名，通常媒體稱我們為福特信貸。我們擁有超過 700 個職員的龐大的 IT 隊伍。

我們的動機是什么呢？

我們很難跨越項目實現項目交付產物的共享。每一個團隊都擁有自己的一套模板和他們自己的方法。當職員被從一個團隊調到另一個團隊時，他們必須學習新的方法。同時我們也很難利用公共團隊。這些團隊是外部的應用團隊，他們提供良好的產品和項目服務。服務團隊的例子包括象 DA 、DBA 、框架團隊和構建團隊。每個服務某一方面的應用團隊都有不同的交付產物集合，因此他們沒有一個公共的過程框架。

我們也有些晚的在項目中包含這些服務團隊，因此導致了一些問題。人們在需要進入產品化階段時才想起構建團隊，而不是在適當的時候聯系他們。

此外，我們的框架架構師一直被過程問題壓的喘不過來氣�？蚣芗軜嫀煹墓ぷ魇窃O計并維護我們的設計模式；相反他們一直被詢問如何組織一個項目、什么過程應該被使用和項目應該有多少迭代。那不是他們的工作。

項目也正感覺到了另一個痛處：過晚的項目風險的識別。我們有一個必須連接數據倉庫和為報告目的返回信息的項目。他們將這個需求留到了最后的時刻，并發現應用的性能不是足夠快的。這對項目造成了很大的影響。

最重要的是，這種對擁有一個公共過程的努力是一個拉動的工作，而不是一個推動的工作。我們并沒有在我們的組織中推進這種方法。而是我們被要求實施一個公共的軟件開發過程。

我們為什么選擇 RUP ？

在我們的組織中我們擁有一些在 RUP 方面的技術專長。我們也知道 RUP 是可以定制的。一些框架團隊的人員說他們非常了解 RUP ，并起草了一份一頁紙的 RUP 的概要，這顯然是被過份的裁剪了。

我們也知道無論在公司內還是公司外我們都已經擁有豐富知識的資源。我們知道 RUP 提供了一個豐富的被在工業中清晰定義和良好理解的術語集合，我們也知道這是 RUP 真正的優勢。RUP 的工業領先的位置給了我們和我們的管理層很大的信心。 RUP 是可以高度定制的，并且我們知道我們必須要做什么。

我們將如何按照我們的路線開始呢？

首先我們在六個項目中嘗試使用 RUP ，這些項目覆蓋了四個不同的業務領域。然后我們在公司論壇中推動大家對 RUP 的了解。RUP 已經在一些項目人員群體中有了一定的立足空間了，這給了我們很大的鼓勵。我們確定了公司中的領域問題專家（SME）。然后我們開始了兩個項目：一個負責開發 RUP 的自定義版本，另一個負責部署開發出來的自定義的 RUP 版本。我們的產出結果是我們稱作為統一方案交付方法或者 USDM 的過程實例。它是基于 RUP 的，但是對于福特公司特定的組織和項目是需要定制的。例如，我們必須包括內部的控制考慮和我們的數據和記錄的保留政策。此外，我們必須包括按照福特公司熟知的工作家族來定義角色。

USDM 也是非常注重實效的以保證實現真正的價值，甚至是對于快進度的項目，并且它也是足夠靈活的以便我們能夠使用它來滿足我們眾多項目的需要。

開發

我們將開發工作作為一個項目來實施。（見圖 1）

圖 1:開發項目

我們有一個目標，這個目標是針對福特的需要創建一個健壯的并且注重實效的面向對象的開發過程。我們同時還確立了這樣的目標：定制 RUP 、開發培訓和定義一個支持的組織。我們的時間限定在六個月，我們擁有三個資源：三個方法專家將工作在這個項目中。

我們所要執行的步驟被列在圖 2 中。

圖 2:在開發項目中的步驟

通過我們對 RUP 的實施 ，那六個我們嘗試的項目，我們確定了 USDM 的進入標準。在福特信貸公司中所有的項目都必須使用對象技術。對于我們來說，就是 J2EE 。我們通過瀏覽 RUP 的產物準備我們過程中的產物，然后決定哪一個是我們需要的，哪一個是我們不需要的。之后我們為過程方法添加了福特特有的一些過程。在福特公司我們有很多我們自己的工作產物和被需要的過程。

我們文檔化了服務團隊的角色和職責以及這些不同的團隊應該在一個項目中包括過程的哪些方面。我們也通過識別進入和退出初始、細化、構建和轉換階段意味著什么定義了階段的出口標準。此外，我們創建了簡化的工作流。我們接受了 RUP 中已有的工作流程，一些工作流程按照 RUP 中的定義那樣使用，另一些被我們進行了有意義的簡化。

我們細化了詞匯表并合并添加了一個推薦的讀物列表。我們創建了一些培訓材料。此外，我們搜集了一些工作產物的樣例并定義了我們的支持組織。最重要的是，我們創建了一個 Web 網站。所有的結果產物構成了 USDM 。

我們通過創造擁有權的感覺和將服務團隊作為 SME 包含在項目當中合并了服務團隊（組織外部的提供服務和向應用團隊提供產品的應用團隊）。然后我們確定服務團隊過程的入口點 — 他們應該什么時候進入項目。這是非常重要的并且添加了很大的價值。接下來我們將服務團隊的職責映射到了適當的活動或者工作流程中。我們建立了與服務團隊管理層的良好關系，這一點對我們是非常重要的。

每一個項目都面臨著挑戰。我們遇到了組織的復雜性和雞與蛋的問題。當我們盡力的改進我們過程時我們必須要進行培訓，同時我們有好懷疑的指導團隊的參與者。在我們嘗試 RUP 實現過程中與我們一起工作的指導團隊的一些經理是頑固的。經理們想要看到接下來六個月項目計劃的每一個最終的細節，否則他們是不滿意的。他們想預先知道每一件事情。我們必須說服他們這與他們管理的項目類型的做法是不同的。

在我們的 SME 中也存在著不一致的看法。無論什么時候進入專家們討論的房間，你都會聽到很多的看法，這些看法都是明確的針對我們的案例的。我們也很難協調在福特公司和福特信貸公司之間的工作（比如，什么時間在哪里我們應該進行會議）。

我們也很難擁有在福特公司和福特信貸公司的項目管理方法論。因為那些福特公司的管理人員，甚至雖然他們是我們項目的發起者，并不理解我們項目的管理方法論，因此對我們來說產生了一些問題。他們不理解什么應該被包括在項目中、一個項目的發起者意味著什么和他們的職責是什么。

總而言之，在 USDM 中我們有大約 20 個工作產物。我們也擁有定義良好的與服務團隊的連接點。我們擁有簡化了的工作流程。我們擁有定義良好的支持組織，包括指導服務，我們發現指導服務是極其重要的。我們的整個過程都在一個全面的網站上被描述出來。

當我們定制 RUP 的一個關鍵產物時我們引入了一個項目的章程，這個項目章程代替了 RUP 中的遠景文檔。我們創建了一個系統架構文檔。我們采用了 RUP 中的系統架構文檔，并對這個文檔進行了一些重要的改變以滿足福特公司和福特信貸公司的需要，同時也改變了文檔的名字。我們也創建了一個有用的被稱為風險用例映射的產物，它被用于根據用例劃分風險的等級或者優先級。

圖 3 顯示了一些關鍵的產物。

圖 3:核心的產物

圖 4 顯示了我們定制的過程流程中的一個。

圖 4:需求工程流程

我們采用了 RUP 的工程流程，并和我們的領域問題專家一起檢查了這些流程，然后我們在流程中添加了一些我們決定被需要的額外活動。

然后我們必須讓組織了解 USDM ，這可以通過瀏覽我們建立的全面的網站來完成。我們也為高層和中層的管理人員進行了關于 USDM 的介紹。我們引導大家來了解 USDM 并在公司的面向對象的興趣論壇中對 USDM 進行了介紹。這可以幫助我們使整個組織了解我們將要部署的新的方法論。

部署

在我們開發了 USDM 這后，我們需要將它部署到我們的組織中。這個工作也被作為一個項目來實施，見圖 5 。

圖 5:部署項目

我們的目標是實現能夠提供所有必要的支持和指導服務的 USDM 支持中心，以便 USDM 能夠被容易的理解并在組織中使用。

我們的目標是建立一個支持中心的過程，產生和交付適當的培訓材料，并且伴隨過程的度量方法。

部署的步驟被顯示在圖 6 中。

圖 6:部署項目

部署交付物

我們建立了一個變更控制過程。我們定義了一個指導認證的過程和指導的程序。當我們想讓服務團隊了解我們的過程是怎樣的并且他們應該在什么時候和如何使用我們的過程時，我們也為我們的服務團隊開發了培訓材料。然后我們定義并簽署了服務團隊協議。（這些協議的一個是關于框架團隊的，我們知道他們希望在項目的早期就被包含進來）。最重要的是，我們向合格的項目交付和部署了指導服務。

我們的支持組織有兩種武器，如圖 7 所示。

圖 7:支持組織

一種武器是研究行業并開發和維護過程的產品。他們是支持團隊持續改進的部分。另一種武器能夠幫助應用團隊。我們擁有指導人員來提供培訓，我們覺得培訓真的是非常的重要，并且已經使我們成功的應用過程。

我們也創建了一個描述變更控制過程如何工作的流程圖。我們想包括適當的人員，利用已有的工具進行跟蹤和記錄我們的建議，并且建立一個變更控制委員會。變更控制委員會包括方法專家、項目指導人員、來自服務團隊的領域問題專家和管理人員。這個小組決定建議是被采納還是被拒絕。

指導

就像我們所提及的那樣，我們的過程的一個重要的特點就是指導。好的指導能夠幫助平滑的示范遷移。福特公司的大部分人員從事需求方面的所有工作、根據需求簽署和約、分析和設計的工作、編碼的工作和并交付能夠在項目末尾階段被集成在一個的軟件產物。在我們的組織中有一些從事 Cobol 編程的人員，他們不懂任何關于面向對象編程的知識。存在大量的學習曲線要克服，我們的指導服務能夠幫助消除這些學習曲線。

我們想要為這個過程確�？缃M織的一致性。我們想要確保團隊以項目的方式應用我們方法論，而不是在人們自己的思想趨向上使用他們。通過指導，我們獲得了在過程上的立即反饋。我們希望積極的而不是被動的工作。我們想要在項目的一開始就參與其中，而不是當項目遇到麻煩時。我們的指導向各個團隊展示了如何執行過程，甚至如果團隊需要技術上的幫助，我們會幫助他們創建 UML 圖。

過去我們僅僅是將一堆過程交給團隊，然后說按照他們去做吧。結果卻是非常的不好。我們也雇傭了一些顧問。他們向我們出售了一個大的過程，這過程成生了一個復雜的工作計劃。過程中包括了很多任務，并且任務的名字與我們一直使用的名字是不同的。這一次我們決定我們需要手把手的指導來幫助我們的團隊應用這個方法論，并且到此為止我們是成功的。

對于項目指導人員的要求是我們希望他們能夠向對待病人一樣始終如一的對待項目團隊。他們需要具有堅實的方法論的經驗。他們需要在 RUP 方面是訓練有素的。他們也必須是迭代開發方面的專家。他們需要傳授給項目團隊可信性的技術上的經驗。他們必須精通使用 UML 進行面向對象的分析與設計，并且知道如何進行項目管理。

通過我們與服務團隊的協調，我們的指導人員被包括進了項目中。服務團隊告訴我們項目開始時需要一名指導人員。作為一個可選的方法，我們在我們的網站上設置了一個請求按鈕，以便項目能夠請求一個指導人員。項目的管理溝通也應該包括指導人員。然而，我們認為指導人員的引入應該在項目管理和優先過程之前進行，而不是在項目隨意的過程中引入指導人員。從開始和成為優先過程和項目管理的一部分，我們處于引入指導人員的早期階段。福特信貸公司也有項目管理的指導人員。當項目管理的指導人員被引入到項目中時，我們希望我們的 USDM 指導人員也被引入到項目中。

我們如何度量我們指導服務的成功呢？

項目團隊的感覺是一個衡量成功的方法。我們在細化和構建階段結束時對我們指導的團隊進行了調查。我們知道我們是成功的另一種方法是當我們認為我們的服務團隊能夠更早的在過程中工作時，我們就已經成功了。

還有一種確認我們成功的方法是在細化階段后對指導的要求減少了。團隊能夠按部就班的工作，并且他們知道他們應該做什么，他們正確的去做了。在細化階段結束時我們的指導人員已經不被需要了。我們已經擁有按時被完成并且被良好的開始使用項目。

今天我們在哪里與 USDM 一致？

自從 2002 年 5 月我們已經在 18 個項目中采用了 USDM 。由于指導的要求我們已經增強了從事支持的人員，我們雇傭了其他的指導人員，并且繼續保持對管理的強有力的支持。我們也發現對于需求開發的培訓要求。我們正在開始培訓一些業務人員，以便當他們進入項目時知道如何開發用例。我們想預先的培訓他們，使他們了解在定義需求方面領導工作是他們的職責。我們已經實現了很多的變更請求，雖然我們已經有了將變得更大的記錄。

什么是我們計劃增強的事情？

我們計劃制定一個供所有福特信貸公司的項目使用的標準配置管理計劃。我們覺得這將為項目添加大量的價值。每一個人都將按照相同的方式做事情。他們將擁有相同的構建結構和相同的目錄結構并且這將為我們帶來真正的好處。我們也擁有一個標準的參考實現模型以便我們所有的項目都能夠從相同的系統架構框架開始。我們正著眼于為我們的外包工作制定過程。我們已經有了一個將六個 Sigma 的概念納入我們過程的計劃。我們有一個新的基于用例的項目計劃。我們也有一個項目人員安排輔助和缺陷管理過程，他們將很快的被并入到 USDM 中。

經驗教訓

我們覺得我們沒有正確的完成的事情之一是在開發和固定軟件開發過程之前直到項目管理過程被完全制度化我們一直在等待。我們的項目經理們知道管理項目是什么樣子。我們實際上使用了這個項目管理過程來管理我們的開發和部署項目。我們在所有的層次上獲得了管理層的支持。中層管理人員是非常重要的，因為他們是與項目最接近的管理人員。我們將開發和部署工作獨立出來。我們在早期就引入了服務組織的領域問題專家。我們雇傭了經驗豐富的指導人員，他們擁有真正的資產。我們保持事情的簡單化并適時的提供培訓。

所范的錯誤

象很多項目一樣，我們在得到適當的資源之前就承諾了日期。我們直到我們進入項目環境之前我們一直在等待培養業務團體。我們應該提早一點通知他們。我們花費了太多的時間來定制工作產物。我們過份的強調了我們已有產物和模板的重用，我們幾乎總是回到 RUP 中，并對 RUP 的產物進行一些改動。我們花費了太多時間來討論我們的入口標準。我們有大量的不同意見，尤其是與福特公司的人員。在我們開發這個方法論期間，我們也接受了一些具有錯誤技能的項目資源，并且我們低估了一些我們的項目交付產物，尤其是網站的開發。

結論

RUP 是一個良好的開始方法。它是一個非常好的框架，可以為福特這樣的公司提供所有工具和必要的信息。這個框架是非常容易定制以滿足我們的需要的。我們發現的一個重要的事情是集成是關鍵。 RUP 是一個打包的解決方案。如果你將它帶入你的組織，你仍然必須做一些工作。你不能直接為一個項目使用它。在福特信貸公司我們擁有自己的項目管理過程和其他必須集成的過程。定制是重要的。最重要的是，對于我們來說指導是制度化象 RUP 這樣的過程的基本要素。

我們得到的下一個結論是保持過程的簡單性。我們有項目管理、六個 Sigma 、擁有自己過程的服務團隊和 RUP 。我們應該盡量簡潔、清晰的顯示這些過程的連接點，這樣可以產生更少的產物和有限的文書工作。

在最后的分析中我們覺得與你正在通過得到有價值的反饋支持的團隊享受你們的成功樂趣是重要的。

網站演示 — 關鍵的特點

USDM 的一個關鍵特點是開發案例，一個我們用來為項目配置過程的重要產物。我們識別出了三個不同的項目類型：構建新應用的項目；對一個應用系統范圍進行增強的項目；修改 bug 的維護項目。

使用用例模型，我們識別出對于哪些個迭代哪些用例要被開發。然后我們進行了初始的計劃，計劃中安排了迭代的時間。這就是我們如何開始每一個項目的。我們了解項目的范圍，然后通過對時間線和迭代如何被定義的理解來創建定制的開發案例。然后開發我們的工作計劃（進度表）。

基于項目的類型，我們建議哪些產物應該被使用。這是一個協作的團隊工作。作為指導人員，我們與團隊站在同一立場上，并討論項目的需要。此外，在每次迭代和階段的結束我們來確定被使用的產物是否是有價值的。如果產物沒有提供價值，我們將停止使用它。

USDM 的另一個特點是為不同類型的項目工作流程的定制。對于增強或者維護項目的工作來說，你可能僅僅需要一定的活動；因此你可以重用已有的產物。例如，在增強路徑的活動中，“設計用戶界面”，我們也許只是檢查已有的 GUI 以確定用戶的交互，從而了解增強如何能夠被集成到這個流程中。對于所有的工作流程或者活動，我們為增強類型的項目識別關鍵的事情。

過程的下一個關鍵特點是一個服務團隊連接點的 Web 頁面。我們為福特公司和福特信貸公司各建立了一個頁面，因為我們每個公司有不同的服務要求。再一次說明，服務團隊是提供公共資源的項目外的組織。服務團隊的例子比如 DA/DBA 、可重用的團隊、框架架構師、構建團隊和生產管理。當應用團隊使用服務團隊連接點網頁時他們了解在過程中服務團隊應該在什么時候被聯系。

USDM 的另一個關鍵特點是針對過程改進指導人員的使用。指導人員能夠帶來很大的幫助，因為他們能夠始終如一的和不斷的提供關于什么產物正在被使用、什么過程正在被使用和什么沒有被有效的使用方面的反饋。我們就像記錄變更請求一樣記錄了被建議的改進。然后變更控制委員會對于變更請求說可以或者不可以。如果答案是可以，我們就實施變更。

此外，我們保存了一個指導請求日值。當一個指導人員被分配到一個項目中時，我們記錄一些信息，比如指導人員被估計參與項目指導的時間和針對項目的指導人員的資源分配。我們計劃使用這些信息進行度量。我們正盡力的構建允許我們執行趨勢分析的統計數據。我們希望使用這些信息來改經我們的過程。我們也從我們的用戶得到過程改進的建議。他們使用一個簡單的網站反饋表單來提交建議的改進。然后這些建議被提交到變更控制委員會。

對于培訓，當團隊開始一個項目時，我們為他們提供幾個過程的展示。我們沒有打印的過程指南。以前，福特公司的開發過程包括巨大的活頁封面，有時是幾卷的紙張。這一次我們決定將過程的每一件事情發布到網站上，并提供可下載的頁面。這是節約成本的方法，但它的更大的好處是我們每兩個月就要更新一些東西。人們可以訪問這個網站，并可以得到他們需要的更新材料。我們認為這是一個有效的溝通過程和在過程中交流知識的方法。

USDM 過程的另一個特點是指導人員的網站。這個網站為我們的指導人員收藏了信息，包括一個文檔化的指導過程。過程列出了當指導人員參加項目時他們要做的事情。他們要做的事情從初始階段就開始了，也包括其他三個階段。這是一個我們的指導人員要遵守的以在指導工作中促進一致性的指導方針。我們也有一個指導認證程序，新加入的指導人員必須通過這個認證過程以確保他們理解了福特公司和福特信貸公司特定的組織過程，從而使他們能夠一致的指導我們的應用團隊。

我們的 USDM 網站非常類似于 RUP 的過程工具，但用起來更加簡單。在 RUP 中有更多的特性，我們主要是為我們的指導人員使用這些特性作為輔助的工具。我們的所有的工作產物和模板都存儲在 USDM 網站上。

問題 & 解答

你什么時候開發 Web 網站，你使用了 WorkBench 或者 任何其他的 Rational 工具了嗎？

我們唯一使用的工具是 RUP 的過程工具。我們沒有使用 WorkBench 或者其他的工具。我們開發了我們自己的 Web 網站； RUP 不在下面。我們作為方法專家在我們的桌面是有 RUP ，但是團隊并不能訪問它。

在未來你將包括遺留的、非面向對象的開發嗎？

目前來看，我們還沒有這方面的計劃。組織，福特公司，也有另一個 SDM ，被叫作 Classic SDM ，我們使用它來進行我們的主機系統和瀑布型的開發。那就是我們現在的計劃，雖然我們有對 USDM 進行一些變化以使我們能夠為兩種開發使用我們的基于 RUP 的過程的想法，但是從策略上看還不能立即實施。目前來看，我們只是對我們的使用了對象技術的開發項目使用 USDM 。

在應用 RUP 后，你看到了在時間和質量上的改進了嗎？

我的確看到了在質量上的改進。項目按時完成了，客戶對項目更加的滿意了。商業客戶自始自終的被包括在項目中。他們能夠更早的在細化階段對系統進行測試，這導致在項目的后期有更少的痛苦。

什么樣類型的信息被用來定義方法論的成功？

我們有一個正在進行的工作來定義一個能夠證明價值和捕獲一些其他關系的信息的度量模型。我們目前的基本反饋來自于我們的客戶、我們的服務團隊和我們指導管理的會議。此外，在項目結束的時候，我們有一個總結經驗教訓的會議，在會議中我們可以直接得到回復。我們有一個提交給項目經理和項目團隊成員的評估表格，他們能夠在過程和指導工作中提供反饋。

在時間上你的最大挑戰是什么？

這個過程是非常簡單的，并且很多人都想用它，但是我們沒有足夠多的支持人員。因為在福特信貸公司，一個非常大的組織，這個過程正慢慢的變成主流，我們沒有足夠的支持服務來為所有需要幫助的團隊提供支持。第二點是我們只關注在 基于 OO 的項目、使用 J2EE 平臺的項目和使用組件架構的項目上。如果你正工作在一個大的組織中，所有數據都被存儲在主機系統中，那對我們來說將這個過程擴展到遺留類型的項目上挑戰是巨大的。

你為什么將開發和部署分離開來？這樣做對我們有什么意義？

我們做的第一件事是開發方法論。我們用了六個月開發這個方法論，然后用了另外五個月將它部署到我們的組織中。我們的 Web 網站在開發項目結束時是可得到的，然后在部署項目期間我們建立了指導服務。我們確定了指導的過程是怎樣的，培訓了我們的服務團隊，并且與我們的服務團隊達成了協定。

你指導的項目使用什么類型的迭代時間周期？

這依賴于項目，但是我們盡量的保持那些迭代在兩周到六周，迭代的周期也依賴于什么被包括在項目中。指導人員與團隊一起來幫助確定迭代的周期。

文章來源于領測軟件測試網 http://www.kjueaiud.com/