使用 RUP 管理小型项目和团队
級別： 初級
David Kohrell, President, Technology As Promised, LLC
Bill Wonch, Instructor, Technology As Promised, LLC
2005 年 10 月 19 日
來自 Rational Edge：軟件項目管理者常常認為 Rational Unified Process（即大家所熟知的RUP），不適用于有限規模的軟件項目。本文提供了在整個迭代開發階段均遵循RUP，從而獲益匪淺的兩個小項目的典型示例。David Kohrell 在2005年2月的 Rational Edge 期刊上指出，Rational Unified Process，? 或者稱 RUP，?為項目的推進提供了一個靈活的過程 -- 從先啟階段，經過細化階段、構建階段，以及產品化階段 -- 給予指導和說明。本文特別關注RUP如何同樣能為小項目和團隊提供指導。另外，在用于敏捷開發環境的能力方面，我們也觀察了RUP和其它指導（比如，項目管理協會的項目管理知識體系，或PMBOK?）。
小型項目和團隊的背景
通常看來，如果被安排來管理一個小項目，也就意味你是新人或者你已經落伍了。大家都認為“一流的資源”應該被分配給大型的、企業級的、全特性的發布項目。這種認識是錯誤的，讓我們來看一下市場，特別是2001年 .com 破碎之后，小型項目和敏捷團隊的時機成熟了。公司在一個月、一個季度、或者一年之內完成的項目越小，那么，產生收益、減少成本、或者拓展品牌和價值的機會就越多。
明確以下一些定義之后，我們繼續這個話題的討論：
- 大型項目：預算超過$500,000，團隊規模為十三人或者更大，項目進行時間超過一年。
- 中等項目：預算$100,000-$500,000，團隊規模為六到十二人，項目進行時間為六個月到一年。
- 小型項目：預算低于$100,000，團隊規模少于六人（包括在該項目和其他項目之間共用的團隊成員，以及每日必須的人員）。項目進行時間少于六個月。
- 變更請求：預算低于$50,000的所有任務都是被一個人在幾周之內來完成。
|
RUP同樣適用于小型項目
在 Michael Jordan、Greg LeMond、Tiger Woods之前，Bo Jackson統治著整個體育世界。19世紀80年代后期流行著這樣一句話：“Bo 懂得籃球、足球、投資”。
過去的三個多月里，在研討會或課堂上，我引用Bo Jackson的例子來反駁RUP“不適”小型項目的錯誤觀點。我認為RUP“適合”于所有類型的項目，這讓很多人都感到驚詫。就我在過去幾年使用RUP的經歷而言，它能夠用在所有大型、企業級項目，并且組織變更請求。它不僅僅是一個可有可無的方法論。
下面是人們經常提起的用來說明“RUP不適用于小型項目”的兩個方面，我將逐一解答這些問題，來證明他們的看法是錯誤的：
我的回答：敏捷方法以及類似的方法（SCRUM，Paired Programming）在軟件構建中是革新的、有用的。然而，在RUP中也可以使用敏捷方法。那些輕量級的方法可以很好地在新系統的構建階段、解決方案，或者程序中得到運用；但是仍然需要管理其它三個階段的上游和下游活動，比如決定需要做什么（需求）以及操作環境將受到什么影響（發布管理）。RUP并不關注先啟階段、細化階段、構建階段和產品化階段所有業務原則的使用，事實上，它是為這些活動提供了一個最佳框架。
我的回答：方法、知識體系，或者成熟模型不會強加過程。他們只為估算需要做什么，以及如何做得更好而提供一定的基礎。“如何做”這部分是由實施組織來決定的。
PMBOK并沒有規定2000版本中的39個過程或者2004版本中的44個過程在項目中都必須得到使用。它是一個知識體系，為項目管理者可能遇到的各種情況提供了一個起點。例如，它有助于定義組織的變更控制過程應該包括哪些內容。現在，項目管理專業人員（PMP?）在項目管理協會（PMI）監督之下，當然必須遵循PMBOK。PMI提供PMP資格認證，這樣，聘用專業人員的組織機構就能夠放心該專業人員懂得PMBOK。但是這并不意味著專業人員必須在每個項目中都使用到PMBOK的每一項知識。
SEI的能力成熟度模型（CMM）和CMMI從五個級別來評估并驗證某組織的成熟度。按照SEI的規定，很清楚地評估和驗證一個組織做什么，以及在某種程度上，他們如何完成。然而，這并不是規定一個“可重復過程”（二級）必須利用過程、工具和組織角色來完成。
相似地，“RUP的精髓”-- 以及已開發的許多實施RUP的工具 -- 培養逐漸細化的理念，即增量開發的本質。RUP的觀點是組織應當設計并構建部分而不是全部解決方案，需求是已知的。現實中，驗證某特色或者系統是“受人歡迎的應用程序”（比如，想法），還是“失敗”（比如，Coca-Cola's New Coke，自1984）的一個最有效辦法就是將產品交付給用戶。
應用RUP，探尋SEI CMM/CMMI評估，或者使用PMI PMBOK時，最佳實踐是成體系地使用這些向導。例如，你應該首先懂得業務需要（a.k.a 需求），從本質的用例開始，基于那些用例和UML的強大功能進行建模。在2004年《The Rational Unified Process Made Easy》一書中，Per Kroll和Philippe Krutchen很好地描述了這個方法：
|
RUP應用在小型項目環境中
現在，讓我們舉兩個例子，來驗證RUP在小型項目環境中的使用。首先是公共部分項目 – 更新一個使用了十五年的打印工作過程。第二個項目涉及將RUP用于創建一個學習管理系統入口，稱為“TAP University”。兩個項目預算均低于$100,000，由小型團隊在90到120天以內完成。
打印服務更新項目
Bill Wonch，本文作者之一，是 Nebraska 州勞工部的兼職講師和軟件架構師。他最近負責更新一套已使用20年的程序，合計并打印出成千上萬份報表和帳單，以下是他的故事。
這只是一個小項目。但是，它卻是系統的核心，稱為 Mix，而且，必須支持部門內其它系統的更新。這個大框架說明了RUP中可交付的軟件體系架構文檔 -- 理解每個項目、變更命令，或者任務都影響著工作的進展，如同高爾夫球的每個線都與其它相關聯一樣。
當即有系統需要更新，以便與公司現代化的失業保險利益支付系統一起運作的時候，“Mix更新項目”開始了。原先的系統Mix是用COBOL構建的，運行于一個主機系統上。“Mix”并不是一個簡稱；1987年起名為“Mix”是因為它混合了進行大量打印工作的主框架數據和窗體。
新系統將在Java中使用成熟的商業化（commercial-off-the-shelf，COTS）應用和組件來構建，生成必要的XML文件。
項目的先啟階段，我們為系統定義三個參與者：
- 抽象應用類，表示使用即有Mix應用程序的所有系統。
- 操作類，表示員工管理打印的操作。
- 業務使用者，即使用該文檔存儲庫的人員。
如圖1所示，每個參與者均與相應的用例關聯。記住這些參與者和用例，我們可以為更新系統選擇最佳的商業應用。通過這個信息，我們可以精確地計算出更新所需的成本。那些是項目合同與計劃中有限的內容。基于此，我們可以估算出項目的資金。
圖1：在項目先啟階段為系統定義的三個參與者
根據先啟階段確定的計劃和捕獲的用例，RUP指引著項目的進行。RUP精髓的一部分就是可以將需求劃分成不同的組，并根據需要將各組歸入先啟、細化、構建和產品化階段。Mix系統中包括106個打印程序，從先啟階段到產品化階段，將這些程序分成幾個組，然后再單獨迭代地處理，經過四個階段的每次進展都是低風險的（驗證方法），然后再將大大小小打印程序集成。以上做法是有意義的。
TAP University
TAP (Technology As Promised) University是一個在線學習管理系統項目。TAP University的目標是延伸這種由TAP伙伴提供給公司客戶的面對面培訓，并為公司、公共用戶及學生提供在線服務。 2
這是一個小型的項目。改進一個開源的學習管理系統。 該項目的可視化文檔草案于2005年2月22日提出，項目計劃完成于2005年5月3日，包括需要的資源、成本和范圍。表1描述了每個迭代和用例。
表1：TAP University項目的迭代和用例
|
從設想到實施，這個項目只有不到六個月的時候；從正式的項目工作開始到功能的完成，從項目計劃到支持這個產品僅花費了90天。
這里涉及到了8項資源；估計完成該項目所需的小時數為652。成本主要是“人力資本” -- 低于 $15,000。
RUP在本項目中的應用主要包括以下兩方面：
|
結論：RUP的確也適合于小型項目
文章中提到的兩個小型項目呈現了不同類型的組織的需要：大型公共部門辦事處與新近發展起來的小公司。項目的關注點也不同：更新使用15年之久的打印集合工具和在線學習管理系統。兩個項目共同之處是，他們的規模都很小，并且RUP都可以提供一套嚴格而靈活的方法。
Gary Pollice 等幾位作者在《小型團隊的軟件開發》一書中為小型項目的管理者提出了一些有價值的建議：
面對不斷的變化，項目團隊如何掌握怎樣應對變化才能獲得最大的生產率？我們認為，關鍵在于盡可能多地學習不同技術，學習如何有效地使用工具來支持不同的技術，以及決定聯合起什么作用和什么時候起作用。 3RUP以及各種支持RUP的工具，確確實實也“適用于小型項目”，另外，項目管理者應懂得如何最好地發揮RUP的優勢。
|
注釋
1 Per Kroll and Philippe Kruchten, The Rational Unified Process Made Easy: A Practitioner's Guide to the RUP, Addison-Wesley: 2004, pp. 244-245.
2http://www.tapuniversity.com/
3 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.aspromised.com)總裁和 TAP University (http://tapuniversity.aspromised.com)。他是位于 Omaha, Nebraska的Bellevue大學項目管理方向的一位教授。作為IBM Scholars 網絡的一員，他曾在幾個組織中負責產品開發、軟件交付、網絡基礎設施和過程工程項目方面的領導、培訓和咨詢。他獲得管理 M.A.，MIS，社區和地區計劃 M.A.，Nebraska 大學的 B.S.。他通過了項目管理協會的項目管理專家資格認證。此外，他還通過 MS Project 2000 認證，成為 Microsoft Solutions Framework Practitioner 和 Microsoft Certified Programmer。 | ||
| Bill Wonch，Instructor，Technology As Promised，LLC(www.aspromised.com)，Nebraska 州勞工開發部門的一名軟件架構師。他從 Oklahoma 的 Rogers State University 獲得 Associates 學位。他在軟件工具的使用方面有豐富的經驗，包括 Cold Fusion、PHP、 Rational Product Suite、UML、WebSphere、DB2、MS SQL、Crystal、ASP和XML。 | ||
轉載于:https://www.cnblogs.com/jacklaw/archive/2007/12/05/983764.html
總結
以上是生活随笔為你收集整理的使用 RUP 管理小型项目和团队的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 获取某年某月的第一天和最后一天的Sql
- 下一篇： 常用 API 函数(5): 文本和字体函