概念: 修改小型專案的流程
本準則討論如何針對小型專案來量身訂作 RUP。
關係
主要說明

簡介

在交付優質軟體和迅速交付兩者之間要取得微妙的平衡(就是所謂的軟體矛盾!),關鍵在於瞭解流程的基本元素,並遵循流程修改準則,充分滿足專案的特殊需求。不僅如此,也應該恪遵業界公認的最佳作法,以協助軟體開發專案順利完成。

「小型專案」的定義

「小型」可能指專案的人數、專案期間長短或開發的軟體數量。就本藍圖的目的而言,「小型專案」代表下列規模的專案:

  • 3 到 10 人
  • 專案為期不超過 1 年。

小型專案流程的特性

低度正式性是大多數小型專案的一項重要特質。雖有例外,但專案人數愈多、專案規模和複雜度愈高,愈需要正式流程。比方說,如果專案有一個 100 人的團隊分散各處,或同時與多位客戶和轉包商來一起負責多項相關產品,則您需要比一般五人小組更正式的流程。同樣地,飛彈導引系統比庫存系統升級需要更正式的構件。

究竟為何要使用流程?流程可以反覆運用成功的作法,並排除或改進失敗的作法。RUP 特別提供:

  • 最佳作法的指引
  • 您的流程需要考慮的一組作業、角色和工作成果,並包含何時需要這些項目的準則
  • 許多詳細資訊,協助您有效運用您認為對專案有益的技術。比方說,如果您在做 UML 設計模型,您必須瞭解什麼圖解最適合,以及如何建構模型。再者,如果您使用 Rational 工具,則有其他的指引說明如何在整體流程中有效運用這些工具。
  • 指出如何修改流程以解決特定流程問題的指引。比方說,如果專案有大量變更需求,您可以從指引中學習如何有效管理需求。

不論是小型或大型的專案,都需要許多相同的 RUP 活動和構件,這兩者的主要差異在於工作成果的格式和每一項作業的正式程度、詳細程度以及投注的心力。就本藍圖的目的而言,「小型專案流程」將著重在不太拘泥形式的專案上。這種小型專案流程的一些特性如下。

  • 文件數量通常很少,較不詳細。小型專案沒有詳細的「風險管理計劃」和「產品驗收計劃」,在整個「軟體開發計劃」中可能只以幾段文字輕描淡寫地帶過這些主題。在「反覆計劃」中,每次反覆的「測試計劃」可能只有幾段文字而已。
  • 小型專案一開始通常只使用少數軟體開發工具。隨著專案拙壯和愈趨於成功(所有成功小型專案的目標!),就愈需要運用有效率的工具,來協助將您的小組之流程實作方式自動化。
  • 正式審查可能由非正式的會議和討論取而代之。
  • 許多構件可能透過非正式手段取得。風險清單可能只在白板上描繪,狀態評估可能只是電子郵件中的幾段文字。

如何著手進行

在開始定義小型專案的流程之前,請先回顧下列 RUP 要素:

然後,評估在您這些要素上可能採取的任何現有流程,並以修正任何弱點為主要工作。許多專案會選擇逐步採用新的工具和流程,且一開始只採用一小部分的 RUP。

使用 Rational Method Composer (RMC),您可以透過選取和取消選取 RUP 內容套件,來進行粗略的流程修改,然後再於流程審查時,進一步細調,這包括加入您自己的專案特定準則。請注意,RMC 會包含「小型專案」方法配置。這是一種小型的 RUP 配置,包含「非正式」的範本,但不包含適用於較大型或較正式專案的指引。小型專案應該從這個範本下手,並套用針對專案本身所做的調整。如需有關修改  RUP 的詳細資訊,請參閱概念:RUP 調整。 

範例:小型專案採用 RUP 示範小型專案如何定義流程。作業:調整專案的開發流程有提供定義及記載專案的軟體開發流程之詳細指引。

其他流程修改

小型專案可能特別喜歡採用「敏捷式流程」的相關作法和技術。 這部分在概念:RUP 的敏捷式作法白皮書:在小專案上使用 RUP:依 eXtreme Programming 擴充中討論。