準則: 反覆計劃
反覆式作業是現代軟體開發工作的脈博。本準則提議規劃反覆式作業的策略。
關係
相關元素
主要說明

反覆型樣

初始階段反覆

在「初始階段」時,最主要的風險通常是商業方面的或技術方面的風險。初期的主要商業風險經常是在於確定專案資金。因此,概念實證原型通常是初始階段的產物。概念實證原型會示範主要的功能,或是一些必要的技術。

新產品的第一個反覆作業通常都是最困難的。在第一個反覆作業中,除了要產生軟體外,還必須要達到許多新的層面:例如,準備流程、組成團隊、瞭解新的領域、熟悉新的工具等等。在有關可以呈現多少架構,或可以達到的可用功能程度預期方面,要持一點保留。如果您把期望訂得太高,將可能會導致延後完成第一個反覆作業、縮減所能做的反覆作業總數,並因而抵銷反覆式方法的好處。第一個反覆作業應該要專注於使架構維持正確。因此,您必須讓軟體架構師參與早期反覆作業的規劃流程。

詳述反覆

在「詳述」時,反覆作業會專注於定義穩定的架構、設計和實作系統的必要行為,以及透過一系列的架構原型,探索技術方面的架構問題。「重大架構性」情境是一些子流程,這些子流程會透過定義方式,來實作系統的架構。

建構及轉換反覆

在接近「詳述」的尾聲,以及在「建構」與「轉換」期間,變更要求(亦稱為「軟體變更訂單」或 SCO)會開始驅動反覆流程。從下列情況所產生的 SCO 結果:

  • 加強功能要求。
  • 要求範圍超過個別套件或類別的變更要求。
  • 變更反覆範圍及目標。
  • 需求變更提議更改需求基準線,或是將接受的變更納入需求基準線。

這些 SCO 都和現有的專案計劃、反覆計劃以及現有的風險清單維持平衡。SCO 可能會導致需要重新評估需求的優先順序,或是驅使重新設定風險的優先順序。不過,SCO 必須要審慎管理,專案才不會失去控制。

在「建構」與「轉換」期間,其焦點是要呈現架構及實作所有剩餘的需求。

反覆策略

反覆式和只考量整個系統一次的「直瀉式模型」不同的地方,是在每次反覆時,只考量系統的一部分功能。在每次反覆期間,都會分析、設計及實作整個系統的一小部分。所選擇包含的部分,以及要多深入,對於降低後續反覆作業的風險具有舉足輕重的影響。這裡有兩個基本的策略:寬廣/淺顯和窄小/深入。

寬廣且淺顯

在「寬廣/淺顯」策略中,將會分析整個問題領域,但是卻只會考慮表層的詳細資料。這裡會定義所有「使用案例」,並且大部分都會提供詳細明細,以深入瞭解現有的問題。這裡也會廣泛地定義架構,以及定義架構元件提供的關鍵機制與服務;會定義子系統之間的介面,但只有在必須管理關鍵的風險或不確定性時,才會詳述其內部明細。在「建構」階段之前,只會進行少量的實作,大部分的反覆作業都是在「建構」階段時發生。

「寬廣/淺顯」策略適用於下列狀況:

  • 團隊缺少問題領域或技術方面的經驗(包括方法學或流程)。
  • 穩健的架構是未來功能的關鍵需求,並且架構是前所未有的。

不過這個策略也有一些潛在的陷阱:

  • 團隊可能會陷入分析停頓(非邏輯地認為除非設計得很完美,否則就無法實作任何功能)。
  • 這裡需要取得一些早期的結果,來建立信心和可靠性;若專案小組無法產生可執行程式的時間愈長,他們就會對自己的能力愈缺乏信心。
  • 未顯示出足夠的技術明細和架構挑戰,來瞭解真實的技術風險

窄小且深入

在「窄小/深入」策略中,將會徹底地分析問題領域的一個截塊。這裡會定義與此窄小截塊相關的「使用案例」,並且提供詳細明細,以深入瞭解現有的問題。也會定義屬意的行為所需要的支援架構,並且會設計和實作系統。後續的反覆作業會專注於分析、設計及實作其他的垂直截塊。

「窄小/深入」策略適用於下列狀況:

  • 需要呈現早期的結果,以克服主要的風險、累積支援或證明可行性。
  • 需求不斷演變,因此在開始詳細的設計和實作工作之前,極難完整定義所有需求。
  • 強制的截止時間,因此提早開始進行開發是成功交付的關鍵。
  • 可重複使用的可能極高,因此提高漸進交付的程度。

不過這個策略並非完全沒有缺點:

  • 在這種策略中,每個反覆作業開發的軟體,都是呈垂直整合,但卻無法水平整合。這種情況有時稱為烤箱管症狀,導致系統極難整合。
  • 這種策略不適合用來在全新的問題領域中開發系統,或是依據全新架構的系統,因為這種系統功能的大部分都必須進行採樣,才能達到架構上的平衡。

從經驗獲取的知識

一般而言,早期的反覆作業會偏向「寬廣/淺顯」策略,而晚期的反覆作業(已經開發穩定的架構)則傾向於「窄小/深入」策略。

第一個反覆作業通常都是最困難的,因為這需要備齊整個開發環境以及大部分的專案小組。工具整合以及建立團隊問題也會增加第一個反覆作業的複雜程度。這時專注於架構方面可以協助維持重點,並避免團隊因過早專注於細節而陷入泥沼。

混合式策略

  • 初始階段的「窄小/深入」策略

    運用新的技術對於專案的基本可行性很重要。許多電子商業專案都需要屏除傳統方式,更深入探究新的技術。概念實證原型仍被視為「拋棄」式,並且只會探究專案概念的可行性。

  • 初始階段的「寬廣/淺顯」策略

    採用這項策略是為了瞭解系統的範圍,並取得系統的功能寬度樣本,以確定架構確實有能力交付屬意的功能。

  • 詳述階段的「寬廣/淺顯」策略

    這種方式可以協助開發穩健的架構,以選擇性地專注於「窄小/深入」,來處理特定的技術風險。在「建構」階段時已經建立好穩健的架構,這時的重點可以回到「窄小/深入」,因為這時已經開發了功能,並且已在一系列的整合累積中交付那些功能。

  • 建構階段的「窄小/深入」策略

    建構反覆一定都是「窄小/深入」,這時團隊會並列開發及交付必要的功能。 

新團隊的特殊注意事項

新團隊通常都會對於本身能達成的目標抱持過於樂觀的想法。為了反轉這一點,並避免在實際的結果不如樂觀的預期時,所可能造成的士氣低落問題,最好在第一個反覆作業 可以達到的功能數量方面,持較適度的保留。盡量嘗試在建立成就感和專案動力時,同時累積經驗。

如果開發環境及/或方法對團隊而言都是全新的,則將第一次反覆作業的功能減少到最小。專注於整合及調整環境,以便熟練工具的用法,然後在後續的反覆作業中,逐漸增加功能內容。

預期的重做

重做在某種程度上是好事。反覆式開發的一個主要好處,就是可以犯一些錯誤和做實驗,但是這些都要在很早時發生,以便能採取更正動作。不過特別是技術人員,他們都傾向於在連續的反覆作業之間,過度「鍍金」和重做工作。

在反覆作業尾聲進行反覆作業評估時,團隊應該決定現行版次的哪一個部分要重做。預期重做要依下列和系統總計相對的比率,分散在各個階段中:

  • 初始階段,40%-100% - 這是會開發拋棄式探索用原型的期間
  • 詳述或演化週期,早期的反覆 25%-60%;晚期的反覆小於 25%。
  • 建構,在架構基準線之後,每個反覆 10% 或更少,總計的 25%,
  • 轉換,小於 5%。

重做是無可避免的。如果沒有人認為有需要重做時,您就應該覺得可疑。這可能是因為:

  • 過度的排程壓力。
  • 缺少實際的測試或評估。
  • 缺少原動力或焦點。
  • 將重做視為負面的不好、浪費資源或承認是能力不好或失敗。

太多的重做則是一種警示。這可能是因為過度的「鍍金」或要達到不能接受的需求變更層次。這時必須要進行商業案例,來評估是否需要進行某些重做。

請注意,我們在「重做」種類中,並沒有包括縮減前一個反覆作業的工作範圍 (因為對於反覆管理採取的固定時間方法)。「專案管理人員」應該在用來定義下一個反覆作業內容的功能池中,包括這項縮減範圍工作。很明顯的,這種工作通常都具有高優先順序。「專案管理人員」也應該探詢和審慎思考前一個反覆作業無法達到其既定目標的原因。例如,雖然我們並不建議緊急增添人員,以符合排程需求,但專案若長期 人員不足,同時不斷地針對每一個反覆作業制定過多的計劃,也不是很理想的情況。這通常會導致團隊士氣低落,並且造成客戶憤怒不已。這時應該找出適當的平衡,並且可以由諸如 COCOMO II 之類的估算模型(請參閱 [BOE00])協助此作業。專案會在每一個反覆作業中,建立其在生產力和品質方面的成就歷程。「專案管理人員」在規劃下一個反覆作業時可以參考的一個強力指示器,就是上一個反覆作業達到什麼目標。

規劃層次

當第一份反覆計劃完成時,小組負責人(可能是與專案管理人員合併)就可以將其修正為作業層次的工作計劃。隨附的「Microsoft® 專案範本」(作業層次)會顯示其形式。不過請注意這些工作計劃是從反覆計劃衍生來的,它們並不是個別產生的獨立工作成果。很重要的一點是如果專案管理人員要維持控制的話,可以將工作計劃彙整為專案管理人員的反覆計劃。