我們已將反覆定義成相當完整的迷你專案,它貫穿所有主要規範,在大部分情況中,都會產生可執行但不完整的系統:版本。雖然 [編輯、編譯、測試、除錯]
這個循環聽起來像一次反覆,但這裡不是這個意思。每日或每週的建置漸進地整合和測試越來越多的系統元素,也似乎是一項反覆,但在這裡所用的詞義中,這只是反覆的一部分。
反覆開始於規劃和需求,結束於內部或外部的版次。
反覆的速度主要取決於開發組織的大小。
例如:
-
如果只有五個人,他們可以在星期一早上做些規劃,每天中午一起吃飯來監視進度,重新配置作業,星期二開始建置,到了星期五晚上,反覆便告完成。
-
但如果是 20 個人,就很難這麼做了。這時需要花更多時間來分配工作、使各個小組同步作業、進行整合等等。反覆可能會需要三或四個星期。
-
如果是 40 個人,光是「從大腦到四肢的神經匯集」就要花一星期。這時有許多中間的管理層次,對目標的共識需要更正式的文件,以及更多正式的形式。三個月是合理的反覆長度。
其他因素也會介入,例如:組織對於反覆方式的熟悉度(包括擁有穩定而成熟的組織)、小組用來管理程式碼的自動化程度(如分散式 CM)、分送資訊(如內部網路)、自動測試等等。
另外,您也要知道,在反覆中,規劃、同步化、分析結果等等,都有固定的額外負荷。
因此,您一方面折服於反覆方式將帶來的巨大好處,熱切地想要進入反覆的世界,但限於組織人力,您的熱情也慢慢變淡了。
部分經驗資料:
SLOC
|
開發人員數目
|
反覆持續時間
|
10,000
|
5
|
1 星期
|
50,000
|
15
|
1 個月
|
500,000
|
45
|
6 個月
|
1,000,000
|
100
|
1 年
|
-
超過 6 個月的反覆大概需要建置中間里程碑,專案才能上軌道。請考慮縮減反覆範圍來縮短它的長度以及確保更清晰的焦點。
-
超過 12 個月的反覆,本身會有風險,因為反覆跨越了年度經費循環。在過去 12 個月內未產生任何可見項目的專案,會面對失去資金的風險。
-
小於 1 個月的反覆必須很小心設定範圍。短反覆通常比較適合建構階段,新功能將併入的程度及新奇程度都很低。 短的反覆不容易或無法進行正式的分析或設計,可能只會漸進地改進已清楚理解的功能。
-
反覆不需要長度全部相同:它們的長度會隨著目標而不同。一般而言,詳述反覆會比建構反覆長。在一個階段內,反覆通常會有相同的長度(這會使規劃更容易)。
在粗略計劃中,有了反覆數目的觀念之後,您便需要定義各次反覆的內容。找一個名稱或標題來識別每次反覆結束時的產品是好的想法,可以讓人們更能掌握焦點。
範例私密電話交換機的反覆
-
反覆 1:區域電話。
-
反覆 2:新增外部呼叫和訂閱者管理。
-
反覆 3:新增語音信箱和電話會議。
非常簡單的專案可能每個階段只有一次反覆:
-
初始階段一次反覆,用來產生也許是證明概念的原型,也許是使用者介面實體模型,也可能完全不反覆,例如發展循環。
-
詳述階段一次反覆,用來產生架構原型。
-
建構階段一次反覆,用來建置產品(最多到測試版)。
-
轉換階段一次反覆,用來完成產品(完整產品版本)。
如果是比較大的專案,在它的起始開發循環中,規範如下:
-
初始階段中一次反覆(可能是產生原型)。
-
詳述階段兩次反覆;架構原型一次,架構基準線一次。
-
建構階段兩次反覆,以顯現局部系統,使它成熟。
-
轉換階段一次反覆,以從起始作業功能移至完整的產品版本。
如果是具有大量未知事項和新技術等等的大型專案,可能情況如下:
-
在初始階段新增一次反覆,以便進一步建立原型。
-
在詳述階段新增一次反覆,以便探索不同的技術。
-
在建構階段新增一次反覆,以便處理完整的產品規模。
-
在轉換階段新增一次反覆,以便取得作業回饋。
因此,在經過一次開發循環之後,我們會有:
-
低:3 次反覆 [0,1,1,1]
-
典型:6 [1, 2, 2, 1]
-
高:9 [1, 3, 3, 2]
-
非常高:10 [2, 3, 3, 2]
因此,一般而言,請規劃 3 至 10 次反覆。不過,由於觀察到上下界表示罕見情況,因此,大部分開發都會使用 6 至 8 次反覆。
可能的變式有許多種,這會隨著風險、大小和複雜度而不同:
-
如果產品是針對某些全新的領域,您可能需要增加初始階段的反覆次數來合併概念,將各種實體模型呈現給跨部門的客戶或使用者,或建置要求提案的充份回應。
-
如果必須開發新的架構,或有大量的使用案例模型,或有挑戰性很高的風險,您應該規劃在詳述階段中進行兩或三次反覆。
-
如果產品大而複雜,且開發了很長一段時間,您應該計劃在建構階段中,進行三次或更多次反覆。
-
如果您因為必須縮短上巿時間,必須交付縮減功能的產品,或在使用一段時間之後,您覺得可能需要進行許多小型調整來配合一般使用者的基礎,您應該規劃在轉換階段進行幾次反覆。
採用瀑布式生命週期的專案,預設的檢視序列是在重要工作成果完成時,進行單一的主要檢視,例如:
-
在系統規格完成時,進行系統需求檢視 (SRR);
-
在軟體需求規格完成時,進行軟體規格檢視 (SSR);
-
在軟體設計說明的架構設計區段完成時,進行初步設計檢視 (PDR);
-
在軟體設計說明的詳細設計區段完成時,進行重要設計檢視 (CDR)。
在 Rational Unified Process (RUP) 中,在每次反覆完成了對等工作成果的組件時,便會檢視這些組件,但主要里程碑(因而也包括檢視)則是與初始、詳述、建構和轉換等階段的完成對齊。基於合約所賦予的責任,想採用 RUP
的專案管理人員可能需要找出一種方式來協調這個明顯的衝突。理想上,專案管理人員應該使客戶相信,以階段和反覆為基礎的方式,事實上更能真實呈現專案的進度,風險也比較低,因此,SRR、SSR
等都不需要。不過,這不一定做得到,專案管理人員仍必須排定在適當的點上進行這些檢視。在 RUP 中,是可以找到這些重要工作成果(實際上是它們在 RUP 中的對等項目)基本完成的點,只是不一定與階段或反覆幾乎完全對齊。
在這裡,我們的方式是假設 RUP 和(理想上)瀑布式生命週期在需求、設計等上所花的相對工作大致相同,但工作的分配方式不同。結果如下:
-
SRR(主要是關於願景)可以排在初始階段結束之時;
-
SSR(主要是關於軟體需求規格)在詳述階段進行 1/3 之時;
-
PDR(主要是關於軟體架構文件)在詳述階段結束之時;
-
CDR(主要是關於設計模型)在建構階段進行 1/3 之時;
為了有效,專案管理人員與客戶商議之時,應該嘗試將這些檢視和規定的 RUP 檢視結合起來。在 SRR 和 PDR 上,這完全做得到,它們分別可以和生命週期目標里程碑檢視和生命週期架構檢視結合起來。
正如同軟體流程會受到專案特性的影響,專案組織也會受到影響。您必須採用這裡所提供的預設結構(請參閱下圖)來反映各個因素的影響,例如下列中的各個因素:
-
商業環境定義
-
軟體開發工作的規模
-
新奇程度
-
應用程式的類型
-
現行開發流程
-
組織因素
-
技術和管理上的複雜度
在分析組織整體應如何採用新的開發流程時,這些是主要的辨識因素,在這裡,我們要檢查它們對於專案結構的選擇會造成什麼影響。下圖是預設專案組織,顯示如何將責任指派給小組結構。
這個圖顯示預設專案組織。請注意,在安排角色時,年資或職權並不重要。
這個圖是考慮專案層次角色和責任應如何對應到小組結構的起點。另外,這個圖也強調角色(黃框所顯示)並不是個人,而是個人(或小組)在專案中所能穿戴的一頂「帽子」。正是為了這個原因,有些角色(如專案管理人員)會重複出現。這表示依照 RUP
所定義,專案管理人員的行為有時會出現在多個小組中。例如,在大型專案中,以工作分解結構為基礎來準備狀態報告的作業可以委派給管理小組中的個人。不過,這是 RUP 指派給稱為專案管理人員之角色的責任。
在小型專案中,指定為專案管理人員的個人可能會執行稱為專案管理人員的角色的所有作業,這時管理小組便與軟體管理小組聯合為一。小組結構的選擇會受到專案的特性和大小的影響,但它應該接受一些主要是常識性規則的調整:
-
小型小組生產力通常比較好;不過,在大型專案中,必須對照跨小組互動的量來取得平衡
-
避免太深的階層
-
任何管理者或小組負責人的控制範圍都應該只限於七人加減兩人
-
軟體開發小組結構應該由軟體架構來驅動;好的架構在子系統之間的內聚力好、耦合性低,可讓小組能夠更有效地平行運作
-
理想上,單元測試以外的測試應該由不是開發小組的小組來執行。不過,請注意,如果專案很小,這可能不具有經濟上的意義
-
結構必須讓所有小組和個人取得定義清楚的權限和責任。如果階層超出三個層次,這就特別重要。這類結構中間的管理者和小組負責人必須瞭解,在技術和管理作業的平衡上,他們必須做到什麼。
-
這個結構必須支援人員的能力、經驗和動機:例如,如果要由單一小組執行分析、設計和實作,完全不換手,它會需要所有必要的能力。技巧好的分析師,不一定是好的實作者;
-
小組結構不應太嚴格:在專案的生命期限內,個人會在小組之間移轉,小組的責任也會隨著專案重點的階段移轉而改變。
[ROY98] 中有預設組織之原理的詳細討論。尤其是,將部署責任指派給軟體評量小組,這裡認定在開發專案的所有小組中,軟體評量小組會最直接面對使用者將會見到的軟體。
在專案的生命期間,組織會成長,以支援專案計劃中所擷取的工作分解結構。下圖顯示這一點,它取自 [ROY98]。
這個進展強調每個階段的不同組作業:
-
初始階段小組:這是焦點在於規劃的組織,有其他小組的充分支援,以確保計劃能夠代表所有觀點的共識;
-
詳述小組:這是焦點在於架構的組織,專案的驅動力量在於軟體架構小組,依實現穩定架構基準線所需要,得到軟體開發和軟體評量小組的支援;
-
建構小組:這是一個平衡的組織,大部分作業都在軟體開發和軟體評量小組;
-
轉換小組:這是焦點在於客戶的組織,由使用的意見來驅動部署作業。
在這個進展中,小組之間的移轉將確保知識和能力會保留在專案之內。例如,當詳述完成時,有些架構小組成員會安置到開發小組中,也許是作為小組負責人,也許是將架構性的「願景」帶到開發中。不久之後,在建構階段即將結束時,焦點又會移到評量小組,人員又會從開發小組移到評量小組。在這個階段,避免失去熱烈建構時的架構完整性也很重要,架構小組的影響力不能隨著專案「重心」的移轉而消退。將部分架構小組成員移到評量小組是其中一個方式。
|