準則: 流程調整練習
這個準則說明自訂 RUP 的最佳做法。
關係
主要說明

一般

當您整理 Rational Unified Process (RUP) 中的諸多工作成果、作業和角色時,您可以問自己一些問題:

  • 我需要這個嗎?
  • 我如何整理所有這些項目來判斷我的專案需要哪幾項?
  • RUP 不是顯然只適合大型專案嗎?

調整主題將處理所有這些問題。

軟體專案的目的是產生產品。好的流程會使專案在預算內及時產生符合關係人需求的產品。如果需要其他資訊,請參閱構件: 產品

良好流程的關鍵在於掌握關鍵原則並力求簡化。

調整流程時應該考量這裡包含的準則。概念:RUP 調整提供更詳細的指引。

先建置架構

許多專案都有這個問題:焦點高度集中在一個特定區域,以至於在尚未清楚知道產生優質產品的整個流程生命週期會包含哪些「主要」元素之前,便已陷入這個特定區域的細節泥沼中。

一般而言,將焦點高度集中在特定問題區域之前,最好先以輕量方式處理流程的所有主要元素。

等優質軟體流程架構備妥之後,專案便可以將焦點放在已確定為問題主要要素的特定區域上。這項選擇的基礎,在於識別專案的風險,排定這些風險的優先順序,再決定所識別的這些風險的先期緩和策略。

不併入無法清楚證明合理的作業和工作成果

好意的專案管理人員或流程工程師可能會有一份長長的願望清單,列出最好具備的各項測量值、控制項、報告等。不過,作業和工作成果需要資金成本和時間成本。有些成本,例如每天與環境工具集的例行互動,不一定看得到,但它們會隱藏在較差的標準作業生產力中。  

您必須區分重要的流程需求和願望清單,判斷它們的好處是否大於成本。

將開發人員和流程分開

您可能會訓練有素的人員,身懷絕佳的設計、實作和測試技術。請不要讓他們每個星期浪費時間來填寫表單、補強文件或與笨拙的工具博鬥。如果這些作業是必要的,請考慮用合格的支援人員來做這些事。

儘量減少正式的中間工作成果

中間工作成果並不是針對最終產品的工作成果,與產生它們的作業和思想相比,它們的格式並不重要。只要它們能達到目的,它們的外觀如何,用來建置它們的工具是什麼,都無所謂。如艾森豪所說,「方案不算什麼;規劃才是一切」。

太快將工作成果形式化,是一個很容易落入的陷井。工作成果的早期版本,在一段時間內,在仍探索著不同的呈現及其隱含作用之時,通常是進展既快又變動不定。正式文件可能會妨礙這個流程;您可能會浪費許多時間來潤色消耗性很大的工作成果。一般而言,在工作成果的早期階段中,索引卡的手繪圖解和簡單說明便已足夠,對某些專案而言,所需要者,也可能僅止於此。

使用方便格式

您可以調整工作成果,以便能夠以任何形式來維護它。例如,「願景」文件可能做成網頁、「專案計劃」可能做成 Microsoft Project 檔案、「風險清單」可能做成 Rational RequisitePro 需求類型。

在可能之時產生

有些專案要花許多時間來手動剪貼資訊,以便將它們移入正式文件的範本。相反地,請考慮使用 Rational SoDA 等工具,從程式檔產生必要的文件,或協議更簡單的方式來提供相同的資訊,例如使用 Rational Rose 來產生 Web 型設計模型。

在許多情況下,您可以因環境已隱含地提供資訊,完全跳過某個工作成果。例如,您可以只提供含有適當需求類型和可追蹤性的調整過的 Rational RequisitePro 專案,與相關各方一起輕鬆演練它,而不需要產生需求管理計劃中列出需求類型屬性的區段。另一個範例是提供備妥的 Microsoft Project 檔案版本給相關各方,不需要將圖形複製到個別的軟體開發計劃中。

使用 Web

有用的工作成果要能夠溝通有價值的資訊。這項資訊應該放在需要的人手邊。Web 技術正好可以派上用場。如果在 Web 上備妥需求、設計和和實作,就不需要產生大量很快就會廢棄的紙本文件。

使用整合的工具

請選取適合流程的工具,再調整流程來配合工具。恰當的結果是很容易使用的流程和工具集。一般而言,相較於非整合性工具,整合性工具能夠提供較好的一致性及較有用的測量值和報告。

定期重訪流程

請定期重訪流程來修正它,使它更簡單。如果您的人員不相信流程中的每個步驟有益於最終產品,流程很可能會毀壞。

調整,但仍保留練習

RUP 鼓勵調整。不過,調整並非完全略過流程的授權。RUP 的本質在練習之中體現。當調整作業和 工作成果來配合您的需求時,請遵守這些練習的精神。