2005 年 10 月 19 日

來自 Rational Edge：軟件項目管理者常常認(rèn)為 Rational Unified Process（即大家所熟知的RUP），不適用于有限規(guī)模的軟件項目。本文提供了在整個迭代開發(fā)階段均遵循RUP，從而獲益匪淺的兩個小項目的典型示例。

David Kohrell 在2005年2月的 Rational Edge 期刊上指出，Rational Unified Process，? 或者稱 RUP，?為項目的推進(jìn)提供了一個靈活的過程 -- 從先啟階段，經(jīng)過細(xì)化階段、構(gòu)建階段，以及產(chǎn)品化階段 -- 給予指導(dǎo)和說明。本文特別關(guān)注RUP如何同樣能為小項目和團(tuán)隊提供指導(dǎo)。另外，在用于敏捷開發(fā)環(huán)境的能力方面，我們也觀察了RUP和其它指導(dǎo)（比如，項目管理協(xié)會的項目管理知識體系，或PMBOK?）。

小型項目和團(tuán)隊的背景

通?？磥?，如果被安排來管理一個小項目，也就意味你是新人或者你已經(jīng)落伍了。大家都認(rèn)為“一流的資源”應(yīng)該被分配給大型的、企業(yè)級的、全特性的發(fā)布項目。這種認(rèn)識是錯誤的，讓我們來看一下市場，特別是2001年 .com 破碎之后，小型項目和敏捷團(tuán)隊的時機成熟了。公司在一個月、一個季度、或者一年之內(nèi)完成的項目越小，那么，產(chǎn)生收益、減少成本、或者拓展品牌和價值的機會就越多。

明確以下一些定義之后，我們繼續(xù)這個話題的討論：

• 大型項目：預(yù)算超過$500,000，團(tuán)隊規(guī)模為十三人或者更大，項目進(jìn)行時間超過一年。
  
  
• 中等項目：預(yù)算$100,000-$500,000，團(tuán)隊規(guī)模為六到十二人，項目進(jìn)行時間為六個月到一年。
  
  
• 小型項目：預(yù)算低于$100,000，團(tuán)隊規(guī)模少于六人（包括在該項目和其他項目之間共用的團(tuán)隊成員，以及每日必須的人員）。項目進(jìn)行時間少于六個月。
  
  
• 變更請求：預(yù)算低于$50,000的所有任務(wù)都是被一個人在幾周之內(nèi)來完成。

回頁首

RUP同樣適用于小型項目

在 Michael Jordan、Greg LeMond、Tiger Woods之前，Bo Jackson統(tǒng)治著整個體育世界。19世紀(jì)80年代后期流行著這樣一句話：“Bo 懂得籃球、足球、投資”。

過去的三個多月里，在研討會或課堂上，我引用Bo Jackson的例子來反駁RUP“不適”小型項目的錯誤觀點。我認(rèn)為RUP“適合”于所有類型的項目，這讓很多人都感到驚詫。就我在過去幾年使用RUP的經(jīng)歷而言，它能夠用在所有大型、企業(yè)級項目，并且組織變更請求。它不僅僅是一個可有可無的方法論。

下面是人們經(jīng)常提起的用來說明“RUP不適用于小型項目”的兩個方面，我將逐一解答這些問題，來證明他們的看法是錯誤的：

1. 敏捷方法考慮到迅速和緊密的增加或者階段；減少開銷；并且確保開發(fā)人員與客戶之間的緊密聯(lián)系。
   
   我的回答：敏捷方法以及類似的方法（SCRUM，Paired Programming）在軟件構(gòu)建中是革新的、有用的。然而，在RUP中也可以使用敏捷方法。那些輕量級的方法可以很好地在新系統(tǒng)的構(gòu)建階段、解決方案，或者程序中得到運用；但是仍然需要管理其它三個階段的上游和下游活動，比如決定需要做什么（需求）以及操作環(huán)境將受到什么影響（發(fā)布管理）。RUP并不關(guān)注先啟階段、細(xì)化階段、構(gòu)建階段和產(chǎn)品化階段所有業(yè)務(wù)原則的使用，事實上，它是為這些活動提供了一個最佳框架。
   
   
2. RUP以及類似的指導(dǎo)，比如PMBOK, 軟件工程協(xié)會(SEI)的集成的能力成熟度模型 (CMMI)，或 UK 的 IT Infrastructure Library (ITIL)標(biāo)準(zhǔn)給小型項目強加了一些不必要的過程。他們其實僅適用于一千萬以上的大型項目。
   
   我的回答：方法、知識體系，或者成熟模型不會強加過程。他們只為估算需要做什么，以及如何做得更好而提供一定的基礎(chǔ)?！叭绾巫觥边@部分是由實施組織來決定的。
   
   PMBOK并沒有規(guī)定2000版本中的39個過程或者2004版本中的44個過程在項目中都必須得到使用。它是一個知識體系，為項目管理者可能遇到的各種情況提供了一個起點。例如，它有助于定義組織的變更控制過程應(yīng)該包括哪些內(nèi)容。現(xiàn)在，項目管理專業(yè)人員（PMP?）在項目管理協(xié)會（PMI）監(jiān)督之下，當(dāng)然必須遵循PMBOK。PMI提供PMP資格認(rèn)證，這樣，聘用專業(yè)人員的組織機構(gòu)就能夠放心該專業(yè)人員懂得PMBOK。但是這并不意味著專業(yè)人員必須在每個項目中都使用到PMBOK的每一項知識。
   
   SEI的能力成熟度模型（CMM）和CMMI從五個級別來評估并驗證某組織的成熟度。按照SEI的規(guī)定，很清楚地評估和驗證一個組織做什么，以及在某種程度上，他們?nèi)绾瓮瓿?。然而，這并不是規(guī)定一個“可重復(fù)過程”（二級）必須利用過程、工具和組織角色來完成。
   
   相似地，“RUP的精髓”-- 以及已開發(fā)的許多實施RUP的工具 -- 培養(yǎng)逐漸細(xì)化的理念，即增量開發(fā)的本質(zhì)。RUP的觀點是組織應(yīng)當(dāng)設(shè)計并構(gòu)建部分而不是全部解決方案，需求是已知的。現(xiàn)實中，驗證某特色或者系統(tǒng)是“受人歡迎的應(yīng)用程序”（比如，想法），還是“失敗”（比如，Coca-Cola‘s New Coke，自1984）的一個最有效辦法就是將產(chǎn)品交付給用戶。
   
   應(yīng)用RUP，探尋SEI CMM/CMMI評估，或者使用PMI PMBOK時，最佳實踐是成體系地使用這些向?qū)?。例如，你?yīng)該首先懂得業(yè)務(wù)需要（a.k.a 需求），從本質(zhì)的用例開始，基于那些用例和UML的強大功能進(jìn)行建模。在2004年《The Rational Unified Process Made Easy》一書中，Per Kroll和Philippe Krutchen很好地描述了這個方法：

．．．也許，人們采用RUP時最常出現(xiàn)的錯誤是使用太多工件或者做太多活動。過量使用RUP將會降低你的開發(fā)效率；RUP過程框架類似于自助餐，如果你還想保持健康和快樂，那么就不能吃光所有的飯菜。 ¹

回頁首

RUP應(yīng)用在小型項目環(huán)境中

現(xiàn)在，讓我們舉兩個例子，來驗證RUP在小型項目環(huán)境中的使用。首先是公共部分項目 – 更新一個使用了十五年的打印工作過程。第二個項目涉及將RUP用于創(chuàng)建一個學(xué)習(xí)管理系統(tǒng)入口，稱為“TAP University”。兩個項目預(yù)算均低于$100,000，由小型團(tuán)隊在90到120天以內(nèi)完成。

打印服務(wù)更新項目

Bill Wonch，本文作者之一，是 Nebraska 州勞工部的兼職講師和軟件架構(gòu)師。他最近負(fù)責(zé)更新一套已使用20年的程序，合計并打印出成千上萬份報表和帳單，以下是他的故事。

這只是一個小項目。但是，它卻是系統(tǒng)的核心，稱為 Mix，而且，必須支持部門內(nèi)其它系統(tǒng)的更新。這個大框架說明了RUP中可交付的軟件體系架構(gòu)文檔 -- 理解每個項目、變更命令，或者任務(wù)都影響著工作的進(jìn)展，如同高爾夫球的每個線都與其它相關(guān)聯(lián)一樣。

當(dāng)即有系統(tǒng)需要更新，以便與公司現(xiàn)代化的失業(yè)保險利益支付系統(tǒng)一起運作的時候，“Mix更新項目”開始了。原先的系統(tǒng)Mix是用COBOL構(gòu)建的，運行于一個主機系統(tǒng)上?！癕ix”并不是一個簡稱；1987年起名為“Mix”是因為它混合了進(jìn)行大量打印工作的主框架數(shù)據(jù)和窗體。

新系統(tǒng)將在Java中使用成熟的商業(yè)化（commercial-off-the-shelf，COTS）應(yīng)用和組件來構(gòu)建，生成必要的XML文件。

項目的先啟階段，我們?yōu)橄到y(tǒng)定義三個參與者：

• 抽象應(yīng)用類，表示使用即有Mix應(yīng)用程序的所有系統(tǒng)。
  
  
• 操作類，表示員工管理打印的操作。
  
  
• 業(yè)務(wù)使用者，即使用該文檔存儲庫的人員。

如圖1所示，每個參與者均與相應(yīng)的用例關(guān)聯(lián)。記住這些參與者和用例，我們可以為更新系統(tǒng)選擇最佳的商業(yè)應(yīng)用。通過這個信息，我們可以精確地計算出更新所需的成本。那些是項目合同與計劃中有限的內(nèi)容。基于此，我們可以估算出項目的資金。

圖1：在項目先啟階段為系統(tǒng)定義的三個參與者

根據(jù)先啟階段確定的計劃和捕獲的用例，RUP指引著項目的進(jìn)行。RUP精髓的一部分就是可以將需求劃分成不同的組，并根據(jù)需要將各組歸入先啟、細(xì)化、構(gòu)建和產(chǎn)品化階段。Mix系統(tǒng)中包括106個打印程序，從先啟階段到產(chǎn)品化階段，將這些程序分成幾個組，然后再單獨迭代地處理，經(jīng)過四個階段的每次進(jìn)展都是低風(fēng)險的（驗證方法），然后再將大大小小打印程序集成。以上做法是有意義的。

TAP University

TAP (Technology As Promised) University是一個在線學(xué)習(xí)管理系統(tǒng)項目。TAP University的目標(biāo)是延伸這種由TAP伙伴提供給公司客戶的面對面培訓(xùn)，并為公司、公共用戶及學(xué)生提供在線服務(wù)。 ²

這是一個小型的項目。改進(jìn)一個開源的學(xué)習(xí)管理系統(tǒng)。 該項目的可視化文檔草案于2005年2月22日提出，項目計劃完成于2005年5月3日，包括需要的資源、成本和范圍。表1描述了每個迭代和用例。

表1：TAP University項目的迭代和用例

從設(shè)想到實施，這個項目只有不到六個月的時候；從正式的項目工作開始到功能的完成，從項目計劃到支持這個產(chǎn)品僅花費了90天。

這里涉及到了8項資源；估計完成該項目所需的小時數(shù)為652。成本主要是“人力資本” -- 低于 $15,000。

RUP在本項目中的應(yīng)用主要包括以下兩方面：

1. 在迭代和用例的組織方面，RUP已經(jīng)提供了一個框架。表1所示的用例與包含MS project 進(jìn)度表輸出的兩頁項目計劃共同構(gòu)成了文檔文件。CVS 1.12 和 LMS 充當(dāng)共享庫的作用。
   
   
2. RUP指導(dǎo)我們?nèi)绾螛?gòu)建和產(chǎn)品化，甚至在僅僅已知80%需求的情況下。例如，有三個可選的電子商務(wù)解決方案有待評估。決定使用哪個電子商務(wù)工具并不排除在迭代1眾的產(chǎn)出。這意味著公司客戶能夠立即地使用迭代1。
   
   

回頁首

結(jié)論：RUP的確也適合于小型項目

文章中提到的兩個小型項目呈現(xiàn)了不同類型的組織的需要：大型公共部門辦事處與新近發(fā)展起來的小公司。項目的關(guān)注點也不同：更新使用15年之久的打印集合工具和在線學(xué)習(xí)管理系統(tǒng)。兩個項目共同之處是，他們的規(guī)模都很小，并且RUP都可以提供一套嚴(yán)格而靈活的方法。

Gary Pollice 等幾位作者在《小型團(tuán)隊的軟件開發(fā)》一書中為小型項目的管理者提出了一些有價值的建議：

面對不斷的變化，項目團(tuán)隊如何掌握怎樣應(yīng)對變化才能獲得最大的生產(chǎn)率？我們認(rèn)為，關(guān)鍵在于盡可能多地學(xué)習(xí)不同技術(shù)，學(xué)習(xí)如何有效地使用工具來支持不同的技術(shù)，以及決定聯(lián)合起什么作用和什么時候起作用。 ³

RUP以及各種支持RUP的工具，確確實實也“適用于小型項目”，另外，項目管理者應(yīng)懂得如何最好地發(fā)揮RUP的優(yōu)勢。

回頁首

注釋

¹ Per Kroll and Philippe Kruchten, The Rational Unified Process Made Easy: A Practitioner‘s Guide to the RUP, Addison-Wesley: 2004, pp. 244-245.

² http://www./

³ Pollice, Augustine, Lowe, and Madhu, Software Development for Small Teams: A RUP-Centric Approach, Addison-Wesley, 2004. p. xix.

參考資料

• 您可以參閱本文在 developerWorks 全球站點上的 英文原文。

作者簡介

		David Kohrell，Technology As Promised，LLC，(www.)總裁和 TAP University (http://tapuniversity.)。他是位于 Omaha, Nebraska的Bellevue大學(xué)項目管理方向的一位教授。作為IBM Scholars 網(wǎng)絡(luò)的一員，他曾在幾個組織中負(fù)責(zé)產(chǎn)品開發(fā)、軟件交付、網(wǎng)絡(luò)基礎(chǔ)設(shè)施和過程工程項目方面的領(lǐng)導(dǎo)、培訓(xùn)和咨詢。他獲得管理 M.A.，MIS，社區(qū)和地區(qū)計劃 M.A.，Nebraska 大學(xué)的 B.S.。他通過了項目管理協(xié)會的項目管理專家資格認(rèn)證。此外，他還通過 MS Project 2000 認(rèn)證，成為 Microsoft Solutions Framework Practitioner 和 Microsoft Certified Programmer。

		Bill Wonch，Instructor，Technology As Promised，LLC(www.)，Nebraska 州勞工開發(fā)部門的一名軟件架構(gòu)師。他從 Oklahoma 的 Rogers State University 獲得 Associates 學(xué)位。他在軟件工具的使用方面有豐富的經(jīng)驗，包括 Cold Fusion、PHP、 Rational Product Suite、UML、WebSphere、DB2、MS SQL、Crystal、ASP和XML。