主題
Rational Unified Process (RUP) 是 Rational 軟體經過多年精心研發而成的一種流程架構,至今已廣泛運用在大大小小、各種類型的軟體專案中。
近來更有「敏捷式」流程不斷問世,且獲肯定為建置中小型系統的有效方法,例如極致程式設計 (XP)、SCRUM、功能驅動開發 (FDD) 及 Crystal Clear 方法論。(如需有關敏捷聯盟的詳細資訊,請參閱 www.agilealliance.org。)
以下各節旨在協助專案團隊評估從上述方法中發現的一些「敏捷式」作法,察看在 RUP 定義下更臻完整的軟體開發流程如何因應(如需 RUP 的相關資訊,請參閱 RUP簡介)。
敏捷社群已匯整出多種「最佳作法」,尤其適合並行配置的小型專案團隊採用。儘管 RUP 的目標對象不分規模大小,但依然能夠有效適用於小型專案。 一般而言,RUP
及敏捷社群對於開發優質軟體的重要最佳作法所見略同,例如雙方皆贊同採用反覆式開發,並把焦點放在使用者群。
以下各節將說明如何將敏捷社群所指的一些「最佳作法」應用在 RUP 式專案中,坐收事半功倍之效。在此特別針對以極致程式設計 (XP) 方法論所提出的作法進行說明。(如需 XP 的相關資訊,請參閱以下網站:http://www.extremeprogramming.org。)
XP 作法
XP 包括四項基本「活動」(編碼、測試、接聽及設計),皆與 RUP規範相當吻合。這些
XP 活動需透過一套作法來進行,這牽涉到執行額外的活動,因而又對映到 RUP 的其他規範。根據《eXtreme Programming 製程》一書所述,XP 的作法有:
-
全盤規劃:結合商業優先順序及技術面的預測,迅速決定新版軟體的範疇。當實際情況大幅偏離計劃時修正計劃。
-
小型版本:將單純系統付諸迅速生產,之後以極短的週期發行新版本。
-
隱喻:以淺顯易懂的方式描述系統全貌,聯想所有的開發工作。
-
簡式設計:無論指定期限長短,都盡可能將系統設計得越簡單越好。一旦發現不必要的複雜性便立即刪修。
-
測試:程式設計師持續撰寫單元測試,待測試完全執行通過,才能進行後續開發。客戶撰寫測試展示功能開發全數完成。
-
重構:程式設計師在不變更系統行為的情況下進行重組,刪除重複的部分,增進溝通、簡化或增加彈性。
-
雙人程式設計:由兩名程式設計師在一台機器上撰寫所有的產品程式碼。
-
集體擁有權:任何人皆可隨時變更系統中的任何程式碼。
-
連續整合:每完成一項作業,需每天多次進行系統整合與建置。
-
每週工時 40 小時:規定每週工作不得超過 40 小時。不得連續兩週加班。
-
駐點客戶:延請一名使用者親自參與團隊,全天駐守現場以回答問題。
-
程式碼撰寫標準:程式設計師撰寫所有的程式碼時,均按照規定盡量透過程式碼進行控制。
在「全盤規劃」作法中執行的活動,例如主要會對映到 RUP 的專案管理規範。但有些 RUP 主題超出 XP 範圍,例如部署已發行的軟體。需求誘導亦大幅超出 XP 的範圍,因為需求是由客戶定義、提供。此外,由於 XP
旨在應付較小規模的開發專案,故不比 RUP,較難詳盡處理配置及變更管理規範與環境規範上的問題。
與 RUP 相容的 XP 作法
下列作法說明在 XP 與 RUP 交集的規範中,XP 能夠(且在某些情況下已有先例)運用於 RUP 中:
-
全盤規劃:XP 在規劃方面的準則適用於極小型專案,用來達成專案管理規範中的多項目標。對於正式性低的專案尤其有用,因為這類專案不需要生產正式的中間專案管理構件。
-
測試優先設計與重構:這類技術適合應用在 RUP 的實作規範中。XP 中採行測試優先設計的測試作法,更是詳加釐清需求的好方法。如下節所述,重構可能無法擴大應用至較大型的系統。
-
連續整合:RUP 在子系統及系統建置階段(反覆週期內)支援此項作法。於統合系統環境中整合並測試通過單元測試的元件。
-
駐點客戶:如有客戶實地參與團隊,將可減少中間交付項目(尤其是文件)的數量,而有利於 RUP 的活動進展。XP
注重交談,將交談視為客戶與開發人員之間溝通的首要途徑,但前提需要雙方持續進行且通曉系統才能成功,若系統必須經過轉換,即使規模不大,光靠交談仍是不夠的。因此 XP 提供事後補充的機會,例如在專案最後提出設計文件。不過 XP
雖然不禁止製作文件或其他構件,但仍希望您只做真正需要做的事。RUP 所見略同,但更進一步說明當持續及通曉不足以解決事情時的補救辦法。
-
程式碼撰寫標準:RUP 含有一套幾乎奉為強制遵循的程式設計準則。(大多數的專案風險測寫、驅使調整的主要因素,都會強制遵循)
-
每週工時 40 小時:如同 XP,RUP 建議應避免長期加班。XP 並未硬性限制在 40
小時,允許有不同的工時寬限。軟體工程師向來有超時工作的壞習慣,不為賺取額外的報酬,只求完成任務時的成就感,而管理人員也樂觀其成,從不加以阻止。但管理人員切忌如此剝削部屬或要求部屬加班。無論有無加班費,都應記錄員工實際的工作時數。如果有人工作時數長期居高不下,便有必要調查,不過,這方面的問題應由管理人員與當事人之間就實際情況進行解決,並查明團隊其他同仁可能有的問題。40
小時只是參考指標,非硬性規定。
-
雙人程式設計:XP 主張雙人程式設計利於掌控程式碼品質,且一旦習得此項技能,工作將變得更有樂趣。RUP 雖不會鉅細靡遺的說明程式碼生產機制,但在 RUP 式流程中採用雙人程式設計確有可能。RUP
現已透過白皮書,提供一些有關雙人程式設計及測試優先設計與重構的資訊。當然,RUP
中並不一定要套用以上任何一種作法,但是對於具有開放溝通風氣的團隊而言,我們敢斷言,雙人程式設計的效益(站在總生命週期成本效益的角度)恐怕不彰。在合作愉快的團隊中,成員會自然的主動聚在一起討論並解決問題,而非出自被動。
所謂好的流程應從個人層次做起的這項建議,往往令人反感,也不適用於某些企業文化。因此 RUP 不主張嚴格強制執行。不過,在某些情況下,XP 提倡的分組作業及某些其他類型的團隊作法確實有益,因為每個團隊成員可以互助合作,例如:
-
成員彼此認識後,可加速組成團隊
-
團隊完全沒接觸過某些新技術
-
團隊成員有資深員工,也有新人
無法擴大應用的 XP 作法
下列 XP 作法無法擴大應用至較大型系統(XP 本意也不在於此),因此我們在 RUP 中一併納入此項但書。
-
隱喻:對於較大型及複雜的系統而言,隱喻式的架構顯然有其不足之處。RUP 針對系統架構提出較周詳的基礎架構說明,遠勝過《eXtreme Programming
製程》所形容的「幾個大箱子用線接起來。」即使是 XP 社群,最近也開始反對隱喻法了。隱喻已不再列為 XP 的作法(除非人們能想出較好的說明方式,這時隱喻也許派得上用場)。
-
集體擁有權:當團隊成員皆熟悉其負責開發的小型系統或子系統的所有程式碼時,很適合採用集體所有制。但是否要讓團隊全員都能更改任何一部分程式,需視程式碼的複雜程度而定。較快速且安全的作法是讓當事人(或小組)去修改其目前負責的相關程式碼區段。程式碼就算寫得再好,也必須靠通曉其道的人來解,才能有效節省時間,尤其程式使用複雜演算法時更是如此。
-
重構:在大型系統中,頻繁進行重構無法彌補架構欠缺。在《eXtreme Programming 製程》中有述:「XP
的設計策略好比攀登搜尋演算法。首先你會有一個簡單的設計,然後你會把它弄得稍微複雜些,然後簡單些,然後又複雜些。攀登搜尋演算法的問題是,你只能一次解決一小部分的問題,細部改變不可能改善整個局勢,非得大修不可。」在 RUP
中,架構提供「山峰」的樣貌及登頂的途徑,讓大型而複雜的系統有跡可循。
-
小型版本:客戶接受新版本並著手部署的機率高低,取決於眾多因素,通常包括系統大小,因其往往直接關係到營運衝擊。兩個月的週期對於某些類型的系統來說或許太短,會受到後勤單位的反彈。
XP 作法的注意事項
XP 作法乍聽之下似乎大可運用在 RUP 的簡單設計中,但是在普遍應用時,仍需留意一些詳述及注意事項。
-
簡式設計
XP 是相當典型的功能驅動流程:使用者選擇所要的情景、拆解成一項項作業,然後進行實作。依據《eXtreme Programming
製程》所述,任何期限下的最佳軟體設計,應執行每一項測試、沒有重複的邏輯、言明所有程式設計師必知的旨意,且含有最少的可用類別及方法。XP 認為只要對客戶不具有商業價值,就無必要加入設計。
但問題是,跟局部最佳化的問題一樣,這項觀點的問題出在它忽略了 RUP 所謂的「非功能性」需求。這些需求同樣能夠為客戶創造商業價值,只是比較不容易用一般敘述表達。XP 所謂的限制中,有部分便屬於這類需求。RUP
亦不主張對非必要的推測性架構進行設計,除非確知架構模型會是達成非功能性需求的重要關鍵。
因此,RUP 贊同 XP
所主張的「簡式設計」應包括執行所有測試的觀點,並進一步擴大解釋為應涵蓋非功能性需求的軟體測試。再次強調,此觀點只會隨著系統大小及複雜性增長而浮現為重要議題,或是當架構無前例可循或非功能性需求過於繁雜時浮出檯面。例如,轉置資料的需求
(在異質分散式環境中運作)可能會讓程式碼極為複雜,但仍為程式中不可或缺的設計。
小型專案的構件對照
當我們針對小型專案訂作專屬的 RUP,因應實情需要刪減 工作成果需求時,相較於 XP 專案中的等值構件有何異同?表 1 列出小型 RUP 專案的代表性 RUP 構件。
表 1:小型專案之 XP 與 RUP 構件對照
雖然兩者的構件就細部而言不盡相同,但大體來說 RUP 在小型專案(XP 所能輕鬆應付的類型)上的構件,與 XP 專案構件相當吻合。
請注意,表中有少數構件雖然非屬 XP 範圍內,但在許多專案中是必要的。包括資料模型及部署相關的構件,例如 使用者輔助資料。
活動
RUP 將作業定義為由角色所執行的工作─無論作業是輸入構件再行轉換,或是新建構件後再變更輸出構件。RUP 根據 RUP規範不斷列舉這些活動並逐一分類。這些其規範包括:需求、分析與設計、部署及專案管理(較具代表性者)。
活動所產生及消耗的構件有時間上的關聯,當活動的輸入準備妥當(且處於適當的成熟狀態)時,理論上即可開始執行。亦即在構件狀態許可的情況下,生產者與消費者的成對活動有可能在時間上重疊,沒有一定的先後次序。活動的目的在於訂立生產構件的明確準則,也可供專案管理人員作為規劃的準據。
從生命週期、構件及活動各方面照章編織成 RUP,即是「最佳作法」,也就是從實證通過的軟體工程原則、到建置高良率優質軟體、一直到可預測的時程及預算的整個流程。藉由活動(及其相關構件)的支持,並實踐 RUP 設計主軸的這些最佳作法,RUP
才能堅守其據以為根基的重要原則。需注意的是,XP 雖然也使用「作法」的概念,但與 RUP 的最佳作法並非完全合致。
XP 提出一套簡約而動人的軟體開發觀點,僅主張撰寫程式碼、測試、接聽及設計這四項基本活動,且只要根據部分輔助作法即可執行並建立結構(詳見《eXtreme Programming 製程》第九章)。確實,如先前所言,XP
的活動在涵蓋範圍上較接近 RUP 的原則而非 RUP 的活動,而 XP 專案中包括其四大基本活動的所有實際行為,大多出自於其作法詳述與應用。
因此,RUP 的活動中雖有部分與 XP 相呼應,但 XP 的「活動」並未正面做此認定或說明。例如我們來看 《eXtreme Programming
安裝篇》的第四章「使用者情景」,從標題「根據故事定義需求,記在卡片上」乃至於整章內容,都不離依使用者的情景訂定流程說明及準則,以及產生構件的方式及人力分配。而在XP
叢書的不同章節(標題下的內容時而構件導向、時而活動導向)中,持續加以闡述,同時說明「製成的構件」和「已做的工作」,以區分規定與細節的等級。
RUP 顯然高標的規定來自其對於活動及輸出入的考量嚴謹且較為正式。XP 雖然不乏規定,但或許因為其定位在輕量,因此也就省略了正式性及細節。 不夠具體既不是優點也不算缺點,但 XP
中欠缺詳細資訊這點,卻不能與單純性混為一談。細節不足對於經驗較豐富的開發人員也許無所謂,但在多數情況中,對於新團員以及還未趕上團隊的軟體開發腳步者來說,資訊越詳細越有幫助。
活動跟構件的重點一樣,都是要把焦點放在所要達成的目標。在盲目摸索中進行活動決非可取的作法。活動及其相關準則應在你需要時給予指引,以幫助你達成目標,但不應當作自己不知如何達成目標時的藉口。此意念同樣明示於 XP 中,而我們認為 RUP
的每一位使用者都應謹記在心。
角色
在 RUP 中,將活動的執行者稱之為角色(更具體言之,角色包括個人及群組)。角色對於特定的構件也有責任,責任角色通常需創建構件,並確保其他授權的角色在做任何變更時,不會把構件搞砸。個人或群體可扮演單一或多重角色。角色不需要對照到組織內部的某種職務或職銜。
《eXtreme Programming 製程》針對 XP
界定了數種角色,如程式設計師、客戶、測試人員、追蹤人員、講師、顧問及老闆,並說明其職責以及擔任各種角色所應具備的能力資格。在其他 XP 叢書中也有這些角色的說明參考。XP
與 RUP 的角色數量差異十分明顯:
-
XP 未採用所有的 RUP 規範。
-
XP 角色與組織內部的職位(可能擔負多重職責)較相近,RUP 角色則否。例如,XP 的程式設計師實際上身兼多個 RUP 角色的職務,如實作人員、程式碼審查人員及整合人員,而這些角色僅有些微的資格差異。
小型專案中的 XP 及 RUP 角色
若將 RUP 角色對照到小型專案,會比其對應的 XP 角色少 5 個之多,都屬於職務或職銜的角色。此 XP 對應角色的對照結果如表 3(摘自 RUP)所示。
表 3:小型專案中的 XP 角色與 RUP 角色對照
XP 作法與 RUP 搭配使用
RUP 是一種流程基礎架構,據以配置特定流程並建例實例。RUP 必須經過配置,這是 RUP 本身定義的必要步驟。嚴格而言,我們應將量身訂作後的 RUP 版本與 XP 進行比較,亦即將 RUP 量身訂作成 XP
明訂(或暗喻)的專案特性。如此量身訂作而成的 RUP 流程將可融合許多 XP 的作法(例如雙人程式設計、測試優先設計與重構等),但又不至於完全仿照 XP,因為 RUP
強調的是架構、摘要(建模方面)及風險的重要性,並隨著時間(階段、反覆週期)而有不同的結構。
XP 的目的則在於實作小型專案的輕量化製程。為此,其中也包含一些概略性的說明(至少書中有寫)。在 XP 實作過程中,隨時隨地都有事情等著你去發掘、創造或定義。RUP 能兼融合乎及超乎 XP 規模與類型範疇的專案。在此藍圖鋪陳下,RUP
實際上能夠與 XP 文獻中所述的絕大多數作法相容。
值得留意的是,XP 的本質著重在組織、人員及文化。此原則放諸業界皆準,當然也適用於採用 RUP 開發的專案。搭配使用這些作法,將大有利於小型專案。
敏捷式流程參考資料
-
eXtreme Programming (XP)(如需相關資訊,請參閱 http://www.extremeprogramming.org/more.html):
-
eXtreme Programming 製程:擁抱改革:作者 Kent Beck 說明 eXtreme Programming 所蘊含的概念及哲學。本書旨在宣揚理論而非情境作法。
-
重構─改善既有的程式碼設計:為 Martin Fowler 所寫的第一本探討重構的權威鉅作。以型樣進行闡述。 內容蒐羅豐富的 Java 範例。本書旨在說明重構的方法及理由。
-
eXtreme Programming 安裝篇:由 Ron Jeffries、Chet Hendrickson 與 Ann Anderson 合著。本書補充《eXtreme
Programming 製程》,較深入探討特定的 XP 作法。內容旨在教述 XP 式的程式設計方法。
-
規劃 eXtreme Programming:由 Kent Beck 與 Martin Fowler 合著。本書對於如何在快速交付環境中規劃軟體,提出最新的想法。旨在教述如何執行 XP
專案。
-
eXtreme Programming 驗證篇:由 Giancarlo Succi 與 Michele Marchesi 合著。XP2000
的相關論述。彙集多篇精譬的論文,探討豐富多元的主題。
-
eXtrem Programming 情境篇:由 Robert C. Martin 與 James W. Newkirk 合著。以 XP 的實際專案為例進行深入剖析。
-
eXtreme Programming 探索篇:作者 William C.Wake。內容選自熱門的 XPlorations 網站。詳細研探特定主題。
-
eXtreme Programming 應用篇:勝券在握:由 Ken Auer 與 Roy Miller 合著。XP 先趨者的經驗傳承。將於 9 月出版。
如需敏捷聯盟其他成員的相關資訊,請參閱 http://www.agilealliance.org。
|