| Rose Ritchie, Certified Senior Project Manager, IBM
Bernie Michalik, 高級IT認證架構師, IBM
2006 年 7 月 14 日 本文來(lái)自于 Rational Edge：通常，堅定地相信迭代化方法的軟件開(kāi)發(fā)者必須為那些出于各種原因而堅持使用傳統的瀑布方法理念的客戶(hù)服務(wù)。本文就是討論如何幫助那些人改變觀(guān)念，轉為使用Rational Unified Process。 迭代開(kāi)發(fā)技術(shù)的支持者——尤其那些花費了若干年掌握如何使用Rational Unified Process和相關(guān)的迭代方法進(jìn)行軟件開(kāi)發(fā)的專(zhuān)業(yè)技術(shù)人員和顧問(wèn)——他們經(jīng)常批評傳統的"瀑布"方法，甚至不理解為什么瀑布法仍然在軟件開(kāi)發(fā)公司中被廣泛使用。為了拿出客戶(hù)要求的IT解決方案的項目計劃，我們會(huì )涉入到許多項目，它們最初都使用瀑布方法。這些解決方案包含開(kāi)發(fā)新軟件以及擴建新的基礎結構。 我們有許多不錯的使用瀑布方法的理由，包括： - 瀑布法在過(guò)去的使用中很成功
- 我們可以重新利用其它瀑布項目的資源
- 我們的團隊（也就是我們客戶(hù)的員工）感到使用瀑布法很方便
- 我們的團隊希望在進(jìn)行開(kāi)發(fā)之前完成全部的設計任務(wù)
- 我們的團隊也許和另外一只使用瀑布法的團隊合作（尤其是那些為我們的整體解決方案和建設基礎結構的團隊）
不論這些理由是什么，使用Rational Unified Process?或者RUP?進(jìn)行項目開(kāi)發(fā)比使用瀑布法更有意義。我們可以把項目計劃和所有的方法轉換為迭代方法。本文就是基于以上所述，帶您體驗這種方法。 初始計劃是什么以及為什么？ 初始計劃通常包括許多設計階段，在這些階段中我們要概述客戶(hù)的解決方案。因為這些項目將會(huì )有多個(gè)軟件發(fā)布版本，所以初始的設計階段包括了軟件的整體設計。然后針對每個(gè)發(fā)布版本我們都會(huì )有一個(gè)設計階段。隨后的每個(gè)設計階段將變得越來(lái)越具體，因為我們的客戶(hù)逐漸清楚什么是他們所需要的，而此時(shí)我們的團隊也可以開(kāi)始動(dòng)工了。 為什么RUP更有意義？ 對于我們的許多項目，在與客戶(hù)一起評審完我們的瀑布法計劃后，就顯示出來(lái)一個(gè)面向RUP的項目計劃比我們的瀑布法計劃更具加有意義，這里有很多理由，包括： - 客戶(hù)想要盡早獲得成果。一些客戶(hù)不愿等到我們大量的設計工作完成之后才進(jìn)行開(kāi)發(fā)。它們經(jīng)常提出一些要求并且想得到應用程序的代碼，然后就可以盡快地把它們拿給股東們看了。
- 在首次軟件發(fā)布日期之前，客戶(hù)不會(huì )提出所有高水平的要求。在進(jìn)入到計劃設計階段尾聲之前，一些客戶(hù)不會(huì )提出全部的要求，或者是因為一些沖突或者其它的一些限制（例如，一個(gè)在今后某個(gè)時(shí)刻才能做出的決定）。
- 客戶(hù)希望牢牢控制項目的周期和預算。 盡管項目會(huì )出現一些不確定的要求或者其它的不確定因素，但是客戶(hù)依然想控制項目的進(jìn)度。由于RUP項目的每一個(gè)階段是一個(gè)時(shí)間箱，因此我們可以準確地描述項目的進(jìn)度以及每個(gè)階段所需的資源，還有每個(gè)階段完成之后項目的開(kāi)銷(xiāo)。
- 客戶(hù)和開(kāi)發(fā)者都想盡快消除項目中的風(fēng)險。盡早地為客戶(hù)提供應用程序代碼，可以減少由于應用程序沒(méi)有按時(shí)交付所造成的風(fēng)險。對于開(kāi)發(fā)團隊，盡早地發(fā)布項目中應用程序的部分內容，特別是與新技術(shù)有關(guān)的應用程序內容，可以有助于他們降低開(kāi)發(fā)應用程序時(shí)遇到的風(fēng)險。
- 在資金發(fā)生變化時(shí)客戶(hù)想要終止項目。通過(guò)為項目提供高價(jià)值的功能，RUP可以使客戶(hù)最大限度地靈活地花費他們的資金，并獲得盡可能多的預算，以維持這項工程。如果我們使用瀑布法，就會(huì )出現當設計出許多出色的軟件版本后，我們才發(fā)現資金僅僅夠開(kāi)發(fā)其中的一個(gè)軟件。
我們改變了什么？ 在從瀑布法到RUP的調整過(guò)程中，有許多需要改變的地方： - 項目結構。改變項目結構是非常關(guān)鍵的一步。我們將從我們的瀑布法階段，包括高層設計，總體設計，發(fā)布設計，構建，測試，部署，發(fā)布設計，構建，測試，部署－－轉到RUP階段，包括多個(gè)精化階段，隨后是多個(gè)構建階段。我們可能重復這個(gè)過(guò)程，并且每個(gè)遷移階段都會(huì )按照這個(gè)過(guò)程進(jìn)行。
- 時(shí)間框架。在我們開(kāi)始之前，每個(gè)迭代都會(huì )被限制在一個(gè)時(shí)間框架中。如果我們認為在一個(gè)精化或構建迭代階段沒(méi)有足夠的時(shí)間完成我們的工作，我們將把這項工作推延到下一個(gè)迭代中去。這個(gè)與我們在瀑布項目中處理的方法是不同的，在瀑布法中，為了完成設計，構建，測試或者部署，我們可能會(huì )擴展這個(gè)階段。
- 資源使用。在瀑布法中，我們在設計階段擁有的資源在構建／測試／部署階段時(shí)將不復存在。利用RUP方法時(shí)，我們可以保證資源貫穿于每一個(gè)階段。在項目中，我們可讓一個(gè)人在不同的階段扮演不同的角色。
- 早期開(kāi)發(fā)。我們幾乎是立即著(zhù)手開(kāi)發(fā)應用程序，甚至是精化迭代和設計還未完成。而利用瀑布法設計，開(kāi)發(fā)在設計完成之前是不能進(jìn)行的，利用RUP的項目，我們通過(guò)迅速開(kāi)發(fā)部分項目來(lái)降低了風(fēng)險并且獲得了好處。尤其是項目開(kāi)發(fā)的最初幾周，也就是我們著(zhù)手開(kāi)發(fā)用戶(hù)界面的階段。迭代法可以使我們周期性地提供應用程序的進(jìn)展，讓我們的客戶(hù)感到滿(mǎn)意。迭代法還幫助我們在客戶(hù)的要求問(wèn)題上與他們達成一致。它還可以讓我們持續地檢驗應用程序的品質(zhì)（例如，讓我們開(kāi)發(fā)的應用程序滿(mǎn)足客戶(hù)提出的要求）。它還可以通過(guò)讓開(kāi)發(fā)團隊使用新技術(shù)來(lái)降低風(fēng)險（例如，使用從未用過(guò)的永久性構架技術(shù)）。
哪些是我們要保留的相同內容？ 從瀑布法到RUP，盡管我們改變了許多，但是我們并沒(méi)有全部摒棄傳統的設計方法。 對其它活動(dòng)的關(guān)聯(lián)。當我們將項目開(kāi)發(fā)從瀑布法轉到RUP方法時(shí)，有許多支持項目和子項目也在同時(shí)進(jìn)行。在我們初始的瀑布法項目中，我們有了一個(gè)關(guān)鍵路徑，將我們的項目中的關(guān)鍵活動(dòng)與其它項目中的關(guān)鍵活動(dòng)關(guān)聯(lián)在一起。當把我們的項目轉為RUP后，我們會(huì )記錄下其它項目中關(guān)鍵活動(dòng)的日期，然后在我們的項目中創(chuàng )建出與那些活動(dòng)緊密相關(guān)的新活動(dòng)。 角色與資源。在項目中我們扮演著(zhù)同一個(gè)角色并且保持同樣的資源，盡管項目的結構已經(jīng)發(fā)生了變化。我們仍然想用相同的人員類(lèi)型得到相同的設計、開(kāi)發(fā)和測試量。還有，一些與應用程序開(kāi)發(fā)無(wú)關(guān)的角色（例如，基礎結構的開(kāi)發(fā)）也被保留下來(lái)。 交付物以及其它文檔。我們希望在瀑布項目中計劃產(chǎn)生的文檔在RUP項目中仍舊產(chǎn)生。不管我們使用什么方法，顧客仍然想要關(guān)鍵可交付物（例如，主測試計劃），而不管我們的方法是什么。同樣地，我們創(chuàng )建了一個(gè)文檔，讓團隊為每個(gè)項目準確地創(chuàng )建基礎結構，如何配置服務(wù)器、軟件，等等，無(wú)論是瀑布法還是RUP方法，我們都要做這一步工作。 所需工作量。盡管由于從瀑布法到RUP方法的改變導致了構建解決方案的方法發(fā)生了變化，但是無(wú)論使用哪一種方法，完成相同的工作所需的工作量并沒(méi)有改變。 結果是什么？ 當從瀑布法改為RUP方法后，我們發(fā)現： - RUP幫助我們管理客戶(hù)的需求，盡管客戶(hù)也許還不清楚他們最初提出的每一個(gè)需求。我們需要牢牢地管理變更并且增加額外的階段用于滿(mǎn)足新的需求。時(shí)間箱和多個(gè)迭代幫助我們管理變更。在精化階段，多個(gè)迭代意味著(zhù)如果因為時(shí)間箱而無(wú)法在一個(gè)迭代中完成任務(wù)，但客戶(hù)仍舊想要進(jìn)行這個(gè)任務(wù)，我們就要把它轉移到另一個(gè)迭代中去。同樣地，在精化階段，如果我們發(fā)現項目中包含了比計劃還要多的任務(wù)，我們就將把一些任務(wù)轉移到其它迭代中去。我們甚至可以增加額外的迭代，如果客戶(hù)覺(jué)得這樣做是值得的。如果客戶(hù)被預算所限制，他們將不會(huì )再繼續增加迭代，因為他們已經(jīng)從完成了的迭代中獲得重要的價(jià)值?！?
- 在構建階段中的多個(gè)迭代也會(huì )幫助進(jìn)行需求管理。通過(guò)使用迭代進(jìn)行應用程序的開(kāi)發(fā)，我們可以讓客戶(hù)確認他們在每個(gè)迭代中的要求。如果應用程序沒(méi)有和當初設想的一致，我們還可以在下一個(gè)迭代中將它改變。這對我們的管理也有所幫助。
- RUP幫助我們自始至終中地保證質(zhì)量。因為我們在每一個(gè)迭代結束后都發(fā)布代碼，所以RUP讓測試變得簡(jiǎn)單，并且降低了在項目的后期發(fā)現重大問(wèn)題的概率。
- 可視化建模幫助客戶(hù)發(fā)現什么是他們想要的以及幫助我們了解什么是客戶(hù)想要的。間接地，它還幫助我們拉近了與客戶(hù)之間的關(guān)系?？蛻?hù)覺(jué)得可以更進(jìn)一步參與到應用程序的開(kāi)發(fā)中去，應用程序能夠如期完成并且包含全部他們想要的東西，這些都讓客戶(hù)感到非常得滿(mǎn)意。
- 采用組件架構使我們可以交付獨立的、功能性軟件用于較早的測試。它在幫助開(kāi)發(fā)團隊進(jìn)行任務(wù)分解和分配工作時(shí)也顯得十分有用。
你應當在何時(shí)考慮使用RUP方法替代瀑布法？ 以下是在何時(shí)用RUP方法替代瀑布法的一些建議： - 使用瀑布法無(wú)法滿(mǎn)足客戶(hù)時(shí)。例如，客戶(hù)對要花費很長(cháng)時(shí)間才能看到結果感到不滿(mǎn)時(shí)?；蛘呖蛻?hù)抱怨他們需要更加靈活的應用程序，或者他們想在開(kāi)發(fā)的早期就可以解決風(fēng)險問(wèn)題?；蛘弋斂蛻?hù)想在項目的開(kāi)發(fā)初期就看到它的組成部分，不是簡(jiǎn)單的原型或者證實(shí)可行的概念，而是即將成為全部應用程序一部分的實(shí)際項目代碼，RUP 就為以上這種開(kāi)發(fā)方式提供了框架。
- 客戶(hù)當前已經(jīng)普遍使用一個(gè)或多個(gè)Rational工具。如果真是如此，那么他們應經(jīng)看到了IBM Rational軟件的價(jià)值以及這種迭代方法所帶來(lái)的好處了。你可以告訴客戶(hù)，在不久的將來(lái)使用RUP可以使這些工具變得更加有價(jià)值。
- 軟件開(kāi)發(fā)確實(shí)是項目的核心部分，并且/或者軟件是面向對象的。如果你的項目主要是網(wǎng)絡(luò )的重新設計或者是一個(gè)只有少許軟件開(kāi)發(fā)的服務(wù)器固化的項目，用傳統的瀑布方法也許會(huì )更好。同樣地，如果軟件開(kāi)發(fā)大部分是腳本或者過(guò)程語(yǔ)言的話(huà)，使用傳統的方法就足夠了。
- 客戶(hù)不確定他們的要求。也許是由于一些還未解決的爭論，或者相關(guān)的項目還未著(zhù)手動(dòng)工，或者有一些遲滯或未確定的區域，這些因素導致全部的要求不能在同一階段同時(shí)聚集在一起。
如果這些問(wèn)題你的回答大部分是"是"的話(huà)，你就應當在項目中使用RUP了。 你首先應當作的事情是什么？ - 找一個(gè)RUP的高手來(lái)幫助你。 RUP的專(zhuān)家在從瀑布法轉換到RUP的過(guò)程中可以為你進(jìn)行指導。他們在使用RUP方面很有經(jīng)驗，并且可以幫助你找出且應對轉換過(guò)程中出現的挑戰。
- 了解RUP和迭代開(kāi)發(fā)的好處。當你進(jìn)行轉換時(shí)，你也許會(huì )問(wèn)：只是為了變化而變化么？所以，學(xué)習RUP的課程，利用現有的知識(這也是另一個(gè)RUP專(zhuān)家可以幫助的領(lǐng)域)，同時(shí)閱讀文章，尤其要對那些成功使用RUP的個(gè)案進(jìn)行研究。
- 利用集成的IBM Rational工具的優(yōu)勢。RUP構架通過(guò)工具指南來(lái)指導如何使用這些工具。盡管 Rational 工具和方法可以彼此相互獨立使用，但當它們綜合在一起使用的時(shí)候會(huì )變得極為強大，畢竟整體大于部分的總和。
- 采用 RUP 最優(yōu)方法并且使用RUP作為導向重構你的項目計劃還不夠。為了取得成功，你還需要RUP作為導向 1 并且你要使用RUP的最優(yōu)方法獲得最大的收益。
- 了解客戶(hù)以及客戶(hù)企業(yè)文化以便成功地完成RUP項目。一些客戶(hù)也許不想采用全部的或者部分RUP，盡管種種跡象表明他們可以獲得利益。要對這些事情敏感從而采取辦法。
結論 關(guān)于為什么瀑布法成為我們項目開(kāi)發(fā)的一部分，這里有許多原因。偶爾，我們會(huì )遇到這種情況，一個(gè)使用瀑布法的團隊在項目開(kāi)發(fā)中競標并且中標。有些時(shí)候，IT設計師使用相同的設計方法來(lái)開(kāi)發(fā)新項目。也有時(shí)，客戶(hù)想要用瀑布法運行他所有的項目，或者含蓄地使用他們所慣用的方法。在以上這些情況中，瀑布法多少顯出了一些問(wèn)題，如果客戶(hù)堅持采用這種方法，我們也將全力照做。 就算采用一個(gè)好的瀑布法計劃，但是如果換作使用 Rational Unified Process將會(huì )帶來(lái)更多的好處。為了實(shí)現這個(gè)改變，你需要找到一個(gè)標記，用于說(shuō)明客戶(hù)和項目對于改變都是好的候選者。如果有這種跡象，在你進(jìn)行項目之前，它將幫助你了解你應當改變什么以及你應該留下些什么。然而，作為明智的改變，你可以在項目中結合使用這兩種方法的精華，這樣就可以獲得更好的結果。
參考資料
作者簡(jiǎn)介 | | | | 作為項目管理認證專(zhuān)業(yè)人員(PMP) 和 IBM Rational Unified Process的認證專(zhuān)家，Rose Ritchie 擁有十五年以上的IT經(jīng)驗，大多數時(shí)間是復雜應用軟件開(kāi)發(fā)和系統集成項目的項目經(jīng)理或程序經(jīng)理，主要工作在金融服務(wù)行業(yè)。 |
| | | | Bernie Michalik在設計、構建和實(shí)施復雜IT解決方案方面擁有二十二年的經(jīng)驗，擔任過(guò)許多不同類(lèi)型的角色，從領(lǐng)導大型團隊創(chuàng )建大型的系統基礎結構到單獨為全球客戶(hù)開(kāi)發(fā)定制軟件。他的經(jīng)驗涵蓋了廣泛的方法論。 | | 
