第3章 生存期模型
為了送出一個滿意的項目，需要選擇項目實施政策，選擇生存期模型的過程就是選擇政策的過程。下面進入路線圖的“生存期模型”，如圖3-1所示。
3.1 生存期概述
3.1.1 生存期的定義
軟體項目生存期模型的基本特征如下。
1）描述開發的主要階段。
2）定義每一個階段要完成的主要過程和活動。
3）規範每一個階段的輸入和輸出。
在生存期模型中定義軟體過程非常重要，人和過程是保證項目成功的兩個關鍵因素。由合适的人按好的過程進行項目開發，才能最大限度地保證項目的成功。通過過程可以實作一種規範化、流水線化、工業化的軟體開發。軟體的生産過程不存在絕對正确的過程形式，不同的軟體開發項目應當采用不同的或者有針對性的軟體開發過程，而真正合适的軟體開發過程是在軟體項目開發完成後才能明了的。是以，項目開發之初隻能根據項目的特點和開發經驗進行選擇，并在開發過程中不斷地調整。
軟體生存期模型的選擇對項目成功的影響非常重要。恰當的生存期模型可以使軟體項目流程化，并幫助項目人員一步一步地接近目标。如果選擇了适宜的生存期模型，就可以提高開發速度，提升品質，加強項目跟蹤和控制，減少成本，降低風險，改善使用者關系。
3.1.2 生存期的類型
軟體開發模型總體上經曆了從傳統到靈活的變遷，從最初的作坊式的單打獨鬥，到諸如CMM等過程改進式的過程控制，再到靈活模型，如圖3-2所示。靈活模型也發展出更多模型，如時下流行的DevOps。
項目有多種形式，也有多種實施方式。項目團隊根據項目特征選擇最可能使項目成功的生存期模型和方法。總體上，項目生存期模型可以是預測型或适應型。适應型模型可以是疊代型、增量型、靈活型等，如圖3-3所示從兩個次元展示了這4類模型的關系。從項目變化角度看，預測型低，疊代型高；從送出的頻繁度看，預測型低，增量型高。靈活模型既有疊代型，也有增量型，便于完善工作，可以頻繁傳遞。充分了解或有确定需求的項目要素遵循預測型開發模型，而仍在發展中的要素遵循适應型開發模型。
其中：
- 預測型生存期模型是一種更為傳統的方法，需要提前進行大量的計劃工作，然後一次性執行。執行是一個連續的過程。
- 疊代型生存期模型允許對未完成的工作進行回報，進而改進和修改該工作；允許對部分完成或未完成的工作進行回報，進而對該工作進行改進和修改。
- 增量型生存期模型向客戶提供已完成的、可能立即使用的可傳遞成果。
- 靈活型生存期模型同時利用疊代屬性和增量特征，便于完善工作，頻繁傳遞。團隊使用靈活方法時，他們會對産品進行疊代，建立可傳遞成果。團隊将獲得早期的回報，并能提供客戶可見性、信心和對産品的控制。由于團隊可以提前釋出産品，可以率先傳遞價值最高的工作，是以項目可以更早産生投資回報。
不同生存期模型的特征如表3-1所示。表3-1從項目需求、開發活動、産品傳遞及目标等角度展示了四大模型的項目特征。從項目需求上看：預測型的需求最穩定；其他3個類型需求有變化。從開發活動上看：預測型是每個開發活動隻執行一次，瀑布模型就是這樣；疊代型是不斷重複一些活動，直到正确為止；增量型是每個增量活動隻執行一次；靈活型也是不斷重複一些活動，直到正确為止。從産品傳遞上看：預測型、疊代型隻送出一次；增量型、靈活型多次送出小版本。從目标上看：預測型的目标是管理成本；疊代型的目标是獲得正确的解決方案；增量型的目标是加快速度；靈活型通過不斷送出和回報獲得使用者肯定。這些特征可以作為選擇模型的參考。
需要注意的是，所有的項目都具有這些特征，沒有一個項目能夠完全不考慮需求、傳遞、變更和目标這些因素。項目的固有特征決定了其适合采用哪種生存期模型。
另一種了解不同項目生存期的方法是使用一個連續區間，從圖3-3一端的預測型模型到另一端的靈活型模型，連續區間中間還有更多的疊代型周期或增量型周期。沒有哪個生存期模型能夠完美地适用于所有的項目。相反，每個項目都能在連續區間中找到一個點，根據其背景特征實作最佳平衡。實踐中還有混合型生存期模型，這種模型是預測型和适應型的組合。
3.2 預測型生存期模型
預測型生存期模型充分利用已知和已經證明的事物，不确定性和複雜性減少，允許項目團隊将工作分解為一系列可預測的小組，是一種傳統的模型，如瀑布模型。預測型生存期模型預計會從高确定性的明确需求、穩定的團隊和低風險中獲益。是以，項目活動通常以順序方式執行，如圖3-4所示。
為了實作這種方法，團隊需要詳細的計劃，了解要傳遞什麼及怎樣傳遞。當其他潛在的變更受到限制時，這些項目就會成功。團隊上司的目标是盡可能減少預測型項目的變更。
團隊在項目初始建立詳細的需求和計劃時，可以闡明各種制約因素,然後利用這些制約因素管理風險和成本。進而，在實施詳細計劃時，團隊會監督并控制可能影響範圍、進度計劃或預算的變更。
如果遇到變更或需求分歧，或者技術解決方案變得不再簡單明了，則預測型項目将産生意想不到的成本。瀑布模型和V模型是最典型的預測型生存期模型。
3.2.1 瀑布模型
（waterfall model）是一個經典的模型，也稱為傳統模型（conventional model），它是一個理想化的生存期模型，如圖3-5所示。它要求項目所有的活動都嚴格按照順序自上而下執行，一個階段的輸出是下一階段的輸入，如同瀑布流水，逐級下落。瀑布模型沒有回報，一個階段完成後，一般不傳回——盡管實際的項目中要經常傳回上一階段。瀑布模型是一個比較“老”的模型，甚至有些過時，但在一些小的項目中還是經常用到的。
瀑布模型的優點：
1）簡單、易用、直覺。
2）開發程序比較嚴格，一個程序接着一個程序進行。
3）模型執行過程中需要嚴密控制。
4）允許基線和配置早期接受控制。
5）為項目提供了按階段劃分的檢查點，目前一個階段完成後，隻需要關注後續階段。
瀑布模型的缺點：
1）在軟體開發的初期階段就要求做出正确、全面、完整的需求分析，這對許多應用軟體來說是極其困難的。
2）由于開發模型是線性的，模型中沒有回報過程，使用者隻有等到整個過程的末期才能見到開發成果，進而增加了開發風險。
3）一個新的項目不适合瀑布模型，除非在項目的後期。
4）使用者直到項目結束才能看到産品的品質，使用者不是漸漸地熟悉系統。
5）不允許變更或者限制變更。
6）早期的錯誤可能要等到開發後期才能發現，進而帶來嚴重後果。
瀑布模型的适用範圍：
1）在項目開始前，項目的需求已經被很好地了解，也很明确，而且項目經理很熟悉為實作這一模型所需要的過程。
2）解決方案在項目開始前也很明确。
3）短期項目可以采用瀑布模型。
瀑布模型的使用說明：
1）開發前，要進行概念開發和系統配置開發。概念開發主要是确定系統級的需求，送出一份任務陳述；系統配置開發需要确定軟體和硬體的情況。
2）開發中，需進行需求過程、設計過程、實施過程。
3）開發後，需進行安裝過程、支援過程、維護過程等。
瀑布模型因為缺乏靈活性、适應性不佳而漸漸受到質疑。Royce在1970年發表的《管理大型軟體系統的開發》中提到：瀑布模型建議在關鍵的原型階段之後應用，在原型階段要充分地了解所要應用的關鍵技術及客戶的實際需求。
3.2.2 V模型
V模型是由Paul Rook在1980年提出的，是瀑布模型的一種變種，同樣需要一步一步進行，前一階段任務完成之後才可以進行下一階段的任務，如圖3-6所示。
這個模型強調測試的重要性，将開發活動與測試活動緊密地聯系在一起。每一步都将比前一階段進行更加完善的測試。一般，大家對測試存在一種誤解，認為測試是開發周期的最後一個階段。其實，早期的測試工作對提高産品的品質、縮短開發周期起着重要作用。V模型正好說明了測試的重要性，它是與開發并行的，例如，單元測試對應詳細設計，內建測試對應概要設計，系統測試對應需求分析。V模型展現了全過程的品質意識。
V模型的優點：
1）簡單易用，隻要按照規定的步驟一步一步執行即可。
2）強調測試過程與開發過程的對應性和并行性。
3）開發程序比較嚴格，執行過程需要嚴密控制。
V模型的缺點：
1）軟體開發的初期階段就要求做出正确、全面、完整的需求分析。
2）軟體項目的實作方案需要很明确。
3）不能存在變更。
V模型的适用範圍：
1）項目的需求在項目開始前很明确。
2）解決方案在項目開始前很明确。
3）項目對系統的安全性能要求很嚴格，如航天飛機控制系統、公司的财務系統等。
V模型的使用說明：使用V模型，要求開發的全過程是嚴格按照順序進行的，一個階段的輸出是下一個階段的輸入。同時，注意圖3-6中虛線對應過程的并行考慮，例如，在需求分析階段，應該有系統測試的準備；在概要設計階段，應該有內建測試的準備；在詳細設計階段，應有單元測試的準備等。
3.3 疊代型生存期模型
疊代型生存期模型（見圖3-7）通過連續的原型或概念驗證來改進産品或成果，每一個新的原型都能帶來相關方新的回報和團隊見解。然後，團隊在下一周期重複一個或多個項目活動，在其中納入新的資訊。這種疊代有利于識别和減少項目的不确定性。
當項目複雜性高、變更頻繁或當項目範圍受到相關方對所需最終産品的不同觀點的支配時，采用疊代型生存期模型會有優勢。疊代型生存期模型可能需要更長的時間，因為它是為學習而優化，而不是為傳遞速度而優化。
實踐中常常将疊代型生存期模型直接等同于原型模型。
原型模型是在需求階段快速建構一部分系統的生存期模型，實作客戶或未來使用者與系統的互動，而且使用者或客戶可以對原型進行評價，這些回報意見可以作為進一步修改系統的依據。通過逐漸調整原型使其滿足客戶的要求，開發人員可以确定客戶的真正需求是什麼；開發人員對開發産品的意見有時與客戶的不一緻，因為開發人員更關注設計和編碼實施，而客戶更關注于需求。是以，開發人員快速構造一個原型有助于很快與客戶就需求達成一緻。
原型模型通常從最核心的方面開始，向使用者展示完成的部分，然後根據使用者的回報資訊繼續開發原型，并重複這一過程，直到開發人員和使用者都認為原型已經足夠好，然後開發人員在此基礎上開發客戶滿意的軟體産品，傳遞作為最終産品的原型，如圖3-8所示。
原型模型以逐漸增加的方式進行開發,以便随時根據客戶或最終使用者的回報來修正系統。在需求變化很快的時候，或者使用者很難提出明确需求的時候，或者開發人員對最佳的架構或算法沒有把握的時候，漸進原型特别有用。但是，原型模型是以犧牲項目的可控制性來換取較多的客戶回報及較好的過程可視性的。由于原型的功能和特性會随着使用者的回報而經常發生變化，是以較難确定産品的最終形态。
原型模型的優點：
1）可以克服瀑布模型的缺點，減少由于軟體需求不明确帶來的開發風險。
2）使用者根據快速建構的原型系統的優缺點，給開發人員提出回報意見。
3）根據回報意見修改軟體需求規格，以便系統可以更正确地反映使用者的需求。
4）可以減少項目的各種假設及風險等。
原型模型的缺點：
1）需求定義之前，需要快速建構一個原型系統。
2）所選用的開發技術和工具不一定符合主流的發展。
3）快速建立起來的系統結構加上連續的修改可能會導緻産品品質低下。
4）使用這個模型的前提是要有一個展示性的産品原型，是以在一定程度上可能會限制開發人員的創新。
原型模型的适用範圍：
1）項目的需求在項目開始前不明确。
2）需要減少項目的不确定性的時候。
原型模型的使用說明：
1）使用者和開發人員根據初始需求共同開發一個項目規劃。
2）使用者和開發人員利用快速分析技術共同定義需求規格。
3）設計者建構一個原型系統。
4）設計者示範這個原型系統，使用者來評估性能并辨別問題。
5）使用者和設計者一起來解決辨別的問題，循環這個過程，直到使用者滿意為止。
6）詳細設計可以根據這個原型進行。
7）原型可以用代碼或者工具來實施。
3.4 增量型生存期模型
增量型生存期模型的政策是不同時開發項目需求，而是将需求分段，使其成為一系列增量産品，每一增量可以分别實施，每個增量都包括分析、設計、實施、測試、送出等過程。每個增量是一個傳遞成果。第一個增量往往是實作基本需求的核心産品。核心産品傳遞使用者使用後，經過評價形成下一個增量的開發計劃，不斷重複這個過程，直到産生最終的完善産品。增量型生存期模型如圖3-9所示。
增量型生存期模型在各個階段并不傳遞一個可運作的完整産品，而是傳遞滿足客戶需求的一個子集的可運作産品。整個産品被分解成若幹個構件，開發人員逐個構件地傳遞産品。是以，增量型生存期模型向客戶提供完成的可傳遞成果，讓客戶能夠立即使用。如果有些項目是為了加快傳遞速度，或者無法等待所有的事情全部完成，可以采用頻繁傳遞少量可傳遞成果的方式，即增量型生存期模型。在這種情況下，客戶先接受整個解決方案的一個部分。
與一次傳遞一個最終産品相比，增量型生存期模型常優化為項目發起人或客戶傳遞價值的工作。在開始工作之前，團隊就計劃了最初的可傳遞成果，并會盡快開始第一次傳遞的工作。某些靈活項目在項目啟動後幾天内就開始傳遞價值，有的項目可能需要更長的時間，從一周到幾周時間不等。
增量型生存期模型的優點：
1）軟體開發可以較好地适應變化，客戶可以不斷地看到所開發的軟體，進而降低開發風險。
2）可以避免一次性投資太多帶來的風險，首先實作主要的功能或者風險大的功能，然後逐漸完善，保證投入的有效性。
3）可以更快地開發出可以操作的系統。
4）可以減少開發過程中使用者需求的變更。
增量型生存期模型的缺點：
1）由于各個構件是逐漸并入已有的軟體體系結構中的，是以加入構件必須不破壞已構造好的系統部分，這需要軟體具備開放式的體系結構。
2）在開發過程中，需求的變化是不可避免的。增量型生存期模型的靈活性使其适應這種變化的能力大大優于瀑布模型和原型模型，但一些增量可能需要重新開發，進而使軟體過程的控制失去整體性（如果早期開發的需求不穩定或者不完整）。
增量型生存期模型的适用範圍：
1）進行已有産品更新或新版本開發，增量型生存期模型是非常适合的。
2）對于完成期限要求嚴格的産品，可以使用增量型生存期模型。
3）對于所開發的領域比較熟悉而且已有原型系統，增量型生存期模型是非常适合的。
4）對市場和使用者把握不是很準，需要逐漸了解的項目，可采用增量型生存期模型。
增量型生存期模型的使用說明：使用增量型生存期模型時，首先建構整個系統的核心部分，或者具有高風險的部分功能——這部分功能對項目的成功起到重要作用。通過測試這些功能來決定它們是否是項目所需要的，這樣可以排除後顧之憂，然後逐漸增加功能和性能，循序漸進。增加功能的時候應該高效而且符合使用者的需要。
漸進式階段模型是一個特殊的增量型生存期模型，每個增量就是一個比較完整的系統，如圖3-10所示，即送出的是正式的版本，包括與産品相關的其他資源。例如某作業系統，為了最終完成的1.0版本，先後釋出了0.1、0.2、0.3等版本，每個版本都可以是正式的産品，直到最後送出了1.0版本。
對于軟體項目來講，可以将大的項目劃分成若幹個小項目來做，将周期長的項目劃分成若幹個明确的階段。“化繁為簡，各個擊破”是解決複雜問題的一個方法。例如，一個5年完成的項目可以分成5個階段，每年送出一個版本，無形中感覺工作時間縮短了，工作量變小了，盡管實際的工作量并沒有減少。開發過程中反複和階段送出是比較合理的過程，漸進式階段模型恰恰展現了這些特征。
漸進式階段模型的優點：
1）階段式送出一個可運作的産品，而且每個階段送出的産品是獨立的系統。
2）關鍵的功能更早出現，可以提高開發人員和客戶的信心。
3）通過階段式産品送出，可以早期預警問題，避免後期發現問題的高成本。
4）通過階段式送出可以運作的産品來說明項目的實際進展，減少項目報告的負擔。
5）階段性完成可以減少估計失誤，因為通過階段完成的評審，可以重新估算下一階段的計劃。
6）階段性完成均衡了彈性與效率，提高開發人員的效率和士氣。
漸進式階段模型的缺點：
1）需要精心規劃各個階段的目标。
2）每個階段送出的是正式版本，是以工作量會增加。
作者曾負責過一個軟體開發項目，該項目前期投入了5人做需求，時間達3個多月，進入開發階段後，投入了15人，時間達10個月之久，陸續進行了3次封閉開發，在此過程中經曆了需求的裁剪、開發人員的變更、技術路線的調整，項目組成員的壓力極大，大家疲憊不堪，産品上線時間拖期達4個月。項目完工後總結下來的一個很緻命的教訓就是：應該将該項目拆成3個小的項目來做，進行階段性版本化釋出。這樣不僅能緩解市場上的壓力，而且可減少項目組成員的挫折感，提高大家的士氣。
3.5 靈活型生存期模型
靈活生存期模型是符合《靈活宣言》原則的模型，客戶滿意度将随着有價值産品的早期傳遞和持續傳遞不斷提升。此外，功能性的、提供價值的增量可傳遞成果是衡量進展的主要尺度。為了适應更頻繁的變更，更頻繁地傳遞項目價值，靈活生存期模型結合了疊代和增量方法。
在靈活環境中，團隊預料需求會發生變更。疊代和增量方法能夠提供回報，以便改善項目下一部分的計劃。不過，在靈活項目中，增量傳遞會發現隐藏或誤解的需求。圖3-11顯示了實作增量傳遞的兩種可能的方法（基于疊代和基于流程），這樣便于項目與客戶需求保持一緻，并根據需要進行調整。
基于疊代的靈活方法，團隊以疊代（相等的持續時間段）形式傳遞完整的功能。團隊集中于最重要的功能，合作完成其工作。然後，團隊再集中于下一項最重要的功能，并合作完成其工作。團隊可決定一次進行若幹功能的開發工作，但團隊不會同時完成所有的疊代工作。
基于流程的靈活方法，團隊将根據自身能力，從待辦事項清單中提取若幹功能開始工作，而不是按照基于疊代的進度計劃開始工作。團隊定義任務闆各列的工作流，并管理進行中的工作（Work In Progress,WIP）。完成不同功能所花費的時間可能有所不同。團隊一般會讓WIP的規模盡量小，以便盡早發現問題，并在需要變更時減少返工。采用靈活生存期模型，無須利用疊代定義計劃和稽核點，團隊和業務相關方決定規劃、産品評審與回顧的最适當的進度計劃。
靈活是許多方法的總稱，其中包括很多靈活開發管理實踐，如Scrum、XP（eXtreme Programming）、OpenUP、看闆方法、Scrumban、精益（lean）模型、持續傳遞、DevOps等。
3.5.1 Scrum
Scrum有明确的更高目标，具有高度自主權，它的核心是疊代和增量，緊密地溝通合作，以高度彈性解決各種挑戰，確定每天、每個階段都朝着目标有明确的推進。
Scrum是一個架構，由Scrum團隊及其相關的角色、活動、工件和規則組成，如圖312所示。在這個架構中可以應用各種流程和技術。Scrum基于經驗主義，經驗主義主張知識源于經驗，而決策基于已知的事物。Scrum采用疊代增量式的方法優化可預測性和管理風險。一個疊代就是一個Sprint（沖刺），Sprint的周期被限制在一個月左右。Sprint是Scrum的核心，其産出是可用的、潛在可釋出的産品增量。Sprint的長度在整個開發過程中保持一緻。新的Sprint在上一個Sprint完成之後立即開始。
如果Sprint周期過長，對“要建構什麼東西”的定義就有可能會改變，複雜度和風險也有可能會增加。Sprint通過確定至少每月一次對達成目标的進度進行檢視和調整來實作可預見性。Sprint也把風險限制在一個月的成本上。
Sprint由Sprint計劃會議（plan meeting）、每日站立會議（daily meeting）、開發工作、Sprint評審會議（review meeting）和Sprint回顧會議（retrospective meeting）構成。Scrum提倡所有團隊成員坐在一起工作，進行口頭交流，以及強調項目有關的規範（discipline），這些有助于創造自我組織的團隊。
1.團隊角色
Scrum團隊由産品負責人（product owner）、Scrum主管（master）和開發團隊組成。Scrum團隊是跨職能的自組織團隊。Scrum團隊疊代增量式地傳遞産品，最大化獲得回報的機會。增量式地傳遞“完成”的産品保證了可工作産品的潛在可用版本總是存在。
産品負責人：代表客戶的意願，從業務角度來保證Scrum團隊在做正确的事情。同時産品負責人代表項目的全體利益幹系人，負責編寫使用者需求（使用者故事），排出優先級，并放入産品訂單（product backlog），進而使項目價值最大化。産品負責人利用産品訂單，督促團隊優先開發最具價值的功能，并在其基礎上繼續開發，将最具價值的開發需求安排在下一個Sprint疊代中完成。産品負責人對項目産出的軟體系統負責，規劃項目初始總體要求、ROI目标和釋出計劃，并為項目赢得驅動及後續資金。
Scrum主管：負責Scrum過程正确實施和利益最大化的人，確定它既符合企業文化，又能傳遞預期利益。Scrum主管的職責是向所有項目參與者講授Scrum方法和正确的執行規則，確定所有項目相關人員遵守Scrum規則，這些規則形成了Scrum過程。
開發團隊：負責找出可在一個疊代中将Sprint訂單（Sprint backlog）轉化為功能增量的方法。開發團隊對每一次疊代和整個項目共同負責，在每個Sprint中通過實行自管理、自組織和跨職能的開發協作，實作Sprint目标和最終傳遞産品，一般由5～9名具有跨職能技能的人（設計者、開發者等）組成。
2.工件
Scrum模型的工件以不同的方式表現工作的任務和價值。Scrum中的工件就是為了最大化關鍵資訊的透明性，是以每個人都需要有相同的了解。
（1）增量
增量是一個Sprint完成的所有産品待辦清單項，以及之前所有Sprint所産生的增量價值的總和，它是在每個Sprint周期内完成的、可傳遞的産品功能增量。在Sprint的結尾，新的增量必須是“完成”的，這意味着它必須可用并且達到了Scrum團隊“完成”的定義的标準。無論産品負責人是否決定真正釋出它，增量必須可用。
（2）産品待辦事項清單
産品待辦事項清單也稱産品訂單，是Scrum中的一個核心工件。産品待辦事項清單是一個包含産品想法的有序清單，所有想法按照期待實作的順序來排序。它是所有需求的唯一來源。這意味着開發團隊的所有工作都來自産品待辦事項清單。
最初，産品待辦事項清單是一個長短不定清單，可以是模糊的或是不具體的。通常情況下，在開始階段，産品待辦事項清單比較短小且模糊，随着時間的推移，其逐漸變長，越來越明确。通過産品待辦事項清單梳理活動，即将被實作的産品待辦事項得到澄清，變得明确，粒度也拆得更小。産品負責人負責産品待辦事項清單的維護，并保證其狀态更新。産品待辦事項可能來自于産品負責人、團隊成員，或者其他利益幹系人。
産品待辦事項清單包含已劃分優先等級的、項目要開發的系統或産品的需求清單，包括功能性需求和非功能性需求及其他假設和限制條件。産品負責人和團隊主要按業務和依賴性的重要程度劃分優先等級，并做出估算。估算值的精确度取決于産品待辦事項清單中條目的優先級和細緻程度，入選下一個Sprint的最高優先等級條目的估算會非常精确。産品的需求清單是動态的，随着産品及其使用環境的變化而變化，并且隻要産品存在，它就随之存在。而且，在整個産品生命周期中，管理層不斷确定産品需求或對之做出改變，以保證産品的适用性、實用性和競争性。
（3）Sprint待辦事項清單
Sprint待辦事項清單也稱Sprint訂單，是一個需要在目前Sprint完成的且梳理過的産品待辦事項，包括産品待辦事項清單中的最高優先等級條目。該清單反映團隊對目前Sprint中需要完成工作的預測，定義團隊在Sprint中的任務清單，這些任務會将目前Sprint標明的産品待辦事項清單轉化為完整的産品功能增量。Sprint訂單在Sprint計劃會議中形成，任務被分解為以小時為機關。如果一個任務超過16小時，那麼它應該被進一步分解。每項任務資訊包括其負責人及其在Sprint中任一天時的剩餘工作量，且僅團隊有權改變其内容。在每個Sprint疊代中，團隊強調應用“整體團隊協作”的最佳實踐，保持可持續發展的工作節奏和每日站立會議。
有了Sprint待辦事項清單後，Sprint即開始，開發團隊成員按照Sprint待辦事項清單來開發新的産品增量。
（4）燃盡圖
圖3-13 燃盡圖燃盡圖（burndown chart）是一個公開展示的圖表，如圖3-13所示，縱軸代表剩餘工作量，橫軸代表時間，顯示目前Sprint中随時間變化而變化的剩餘工作量（可以是未完成的任務數目）。剩餘工作量趨勢線與橫軸之間的交集表示在那個時間點最可能的工作完成量。可以借助它設想在增加或減少釋出功能後項目的情況，可能縮短開發時間，或延長開發期限以獲得更多功能。燃盡圖可以展示項目實際進度與計劃之間的沖突。
3.Scrum活動
Scrum活動主要由産品待辦事項清單梳理、Sprint計劃會議、疊代式軟體開發、每日站立會議、持續內建、Sprint評審會議和Sprint回顧會議組成。
（1）産品待辦事項清單梳理
産品待辦事項通常會很多，也很寬泛，而且想法會變來變去，優先級也會變化，是以産品待辦事項清單梳理是一個貫穿整個Scrum項目始終的活動。該活動包含但不限于以下的内容。
1）保持産品待辦事項清單有序。
2）把看起來不再重要的事項移除或者降級。
3）增加或提升湧現出來的或變得更重要的事項。
4）将事項分解成更小的事項。
5）将事項歸并為更大的事項。
6）對事項進行估算。
産品待辦事項清單梳理的最大好處是為即将到來的Sprint做準備，為此梳理時會特别關注那些即将被實作的事項。
（2）Sprint計劃會議
Sprint計劃會議的目的是要為這個Sprint的工作做計劃。這份計劃是由整個Scrum團隊共同協作完成的。Sprint開始時，均需召開Sprint計劃會議，産品負責人和團隊共同探讨該Sprint的工作内容。産品負責人從最優先的産品待辦事項清單中進行篩選，告知團隊其預期目标，團隊則評估在接下來的Sprint内預期目标可實作的程度。Sprint計劃會議一般不超過8小時。在前4小時中，産品負責人向團隊展示最高優先級的産品，團隊則向他詢問産品待辦事項清單的内容、目的、含義及意圖，而在後4小時，進行本Sprint的具體安排。
Sprint計劃會議最終産生的待辦事項清單就是Sprint待辦事項清單，它為開發團隊提供指引，使團隊明确建構增量的目的。
（3）疊代式軟體開發
通過将整個軟體傳遞過程分成多個疊代周期，團隊可以更好地應對變更，應對風險，實作增量傳遞、快速回報。通過關注保持整個團隊可持續發展的工作節奏、每日站立會議群組織的工作配置設定，實作團隊的高效協作和工作，實作提高整個團隊生産力的目的。
（4）每日站立會議
在Sprint開發中，每天舉行的項目狀況會議稱為每日站立會議。每日站立會議有一些具體的指導原則，具體如下。
1）會議準時開始：對于遲到者，團隊常常會制定懲罰措施。
2）允許所有人參加。
3）不論團隊規模大小，會議被限制在15分鐘。
4）所有出席者應站立（有助于保持會議簡短）。
5）會議應在固定地點和每天的同一時間舉行。
6）在會議上，每個團隊成員需要回答3個問題：
- 今天完成了哪些工作？
- 明天打算做什麼？
- 完成目标是否存在什麼障礙？
（5）持續內建
通過進行更頻繁的軟體內建，實作更早地發現和回報錯誤，降低風險，并使整個軟體的傳遞過程變得更加可預測和可控，以傳遞更高品質的軟體。開發團隊在每個Sprint都傳遞産品功能增量。這個增量是可用的，是以産品負責人可以選擇立即釋出它。每個增量都添加到之前的所有增量上，并經過充分測試，以此保證所有的增量都能工作。
（6）Sprint評審會議
Sprint評審會議一般需要4小時，由團隊成員向産品負責人和其他利益幹系人展示Sprint周期内完成的功能或傳遞的價值，并決定下一次Sprint的内容。在每個Sprint結束時，團隊都會召開Sprint評審會議，團隊成員在會上分别展示他們開發出的軟體，并得到回報資訊，并決定下一次Sprint的内容。
（7）Sprint回顧會議
每一個Sprint完成後，都會舉行一次Sprint回顧會議，在會議上所有團隊成員都要反思這個Sprint。舉行Sprint回顧會議是為了進行持續過程改進。會議的時間限制在4小時。這些任務會将目前Sprint標明的産品待辦事項清單轉化為完整的産品功能增量。開始下一個疊代。
3.5.2 XP
XP是由Kent Beck提出的一套針對業務需求和軟體開發實踐的規則，它的作用在于将二者力量集中在共同的目标上，高效并穩妥地推進開發。其力圖在不斷變化的客戶需求的前提下，以持續的步調，提供高響應性的軟體開發過程及高品質的軟體産品，保持需求和開發的一緻性。
XP提出的一系列實踐旨在滿足程式員高效的短期開發行為和項目長期利益的共同實作，這一系列實踐長期以來被業界廣泛認可，實施靈活的公司通常會全面或者部分采用。
這些實踐如圖3-14所示，按照整體實踐（entire team practice）、開發團隊實踐（development team practice）、開發者實踐（developer practice）3個層面，XP提供如下13個核心實踐：整體實踐包括統一團隊（whole team）、策劃遊戲（planning game）、小型釋出（small release）及客戶驗收（customer test）。開發團隊實踐包括代碼集體所有（team code ownership）、編碼标準／規約（coding standard/convention）、恒定速率（sustainable pace，又名40小時工作）、系統隐喻（system metaphor）、持續內建（continuous integration/build）。開發者實踐包括簡單設計（simple design）、結對程式設計（pair programming）、測試驅動開發（testdriven development）、重構（refactoring）。具體介紹如下。
1.統一團隊
XP項目的所有貢獻者坐在一起。這個團隊必須包括一個業務代表“客戶”，提供要求，設定優先事項。客戶或他的助手之一是一個真正的最終使用者，是最好的；該小組也包括程式員；可能包括測試人員，幫助客戶定義客戶驗收測試；可能包括分析師，幫助客戶分析确定的要求；通常還有一個教練，幫助團隊保持在正确軌道上；可能有一個上層經理，提供資源，處理對外溝通，協調活動。一個XP團隊中的每個人都可以以任何方式做出貢獻。最好的團隊，沒有所謂的特殊人物。
2.策劃遊戲
預測在傳遞日期前可以完成多少工作，現在和下一步該做些什麼，不斷地回答這兩個問題，就是直接服務于如何實施及調整開發過程。與此相比，希望一開始就精确定義整個開發過程要做什麼事情及每件事情要花多少時間，則事倍功半。針對這兩個問題，XP中有兩個主要的相應過程：軟體釋出計劃（release planning）和周期開發計劃（iteration planning）。
3.小型釋出
每個周期開發達成的需求是使用者最需要的東西。在XP中，對于每個周期完成時釋出的系統，使用者都應該可以很容易地評估，或者已能夠投入實際使用。這樣，軟體開發不再是看不見摸不着的東西，而具有實實在在的價值。XP要求頻繁地釋出軟體，如果可能，應每天都釋出新版本，而且在完成任何一個改動、整合或者新需求後，應該立即釋出一個新版本。這些版本的一緻性和可靠性靠驗收測試和測試驅動開發來保證。
4.客戶驗收
客戶對每個需求都定義了一些驗收測試。通過驗收測試，開發人員和客戶可以知道開發出來的軟體是否符合要求。XP開發人員把這些驗收測試看得和單元測試一樣重要。為了不浪費時間，最好能将這些測試過程自動化。
5.代碼集體所有
在很多項目中，開發人員隻維護自己的代碼，而且不喜歡其他人修改自己的代碼，是以即使有相應的比較詳細的開發文檔，但一個程式員很少甚至不太願意去讀其他程式員的代碼；而且因為不清楚其他人的程式到底實作了什麼功能，一個程式員一般也不敢随便改動其他人的代碼。同時，因為自己維護自己的代碼，可能因為時間緊張或技術水準的局限性，某些問題一直不能被發現或比較好地得到解決。針對這點，XP提倡大家共同擁有代碼，每個人都有權利和義務閱讀其他代碼，發現和糾正錯誤，重整和優化代碼。這樣，這些代碼就不僅僅是一兩個人寫的，而是由整個項目開發隊伍共同完成的，錯誤會減少很多，重用性會盡可能地得到提高，代碼品質會非常好。
6.編碼标準／規約
XP開發小組中的所有人都遵循一個統一的程式設計标準，是以，所有的代碼看起來好像是一個人寫的。因為有了統一的程式設計規範，每個程式員更加容易讀懂其他人寫的代碼，這是實作集體代碼所有的重要前提之一。
7.恒定速率
XP團隊處于高效工作狀态，并保持一個可以無限期持續下去的狀态。大量的加班意味着原來的計劃是不準确的，或者是程式員不清楚自己到底什麼時候能完成什麼工作，而且開發管理人員和客戶也是以無法準确掌握開發速度，開發人員也是以非常疲勞而降低效率及品質。XP認為，如果出現大量的加班現象，則開發管理人員（如coach）應該和客戶一起确定加班的原因，并及時調整項目計劃、進度和資源。
8.系統隐喻
為了幫助每個人一緻清楚地了解要完成的客戶需求、要開發的系統功能，XP開發小組用很多形象的比喻來描述系統或功能子產品是怎樣工作的。
9.持續內建
在很多項目中，往往很遲才能把各個子產品整合在一起，在整合過程中，開發人員經常發現很多問題，但不能肯定到底是誰的程式出了問題，而且隻有整合完成後，開發人員才開始使用整個系統，然後馬上傳遞客戶驗收。對于客戶來說，即使這些系統能夠通過最終驗收測試，因為使用時間短，客戶心裡并沒有多少把握。為了解決這些問題，XP提出，在整個項目過程中，應該頻繁地、盡可能早地整合已經開發完的使用者故事(user story)。每次整合，都要進行相應的單元測試和驗收測試，保證軟體符合客戶和開發的要求。整合後，釋出一個新的應用系統。這樣，在整個項目開發過程中，幾乎每隔一兩天，都會釋出一個新系統，有時甚至會一天釋出若幹個版本。通過這個過程，客戶能非常清楚地掌握已經完成的功能和開發進度，并基于這些情況和開發人員進行有效、及時交流，以確定項目順利完成。
10.簡單設計
XP要求用最簡單的辦法實作每個小需求，前提是按照簡單設計開發的軟體必須通過測試。這些設計隻要能滿足系統和客戶當下的需求即可，不需要任何多餘的設計，而且所有這些設計都将在後續的開發過程中被不斷地重整和優化。在XP中，沒有傳統開發模式中一次性的、針對所有需求的總體設計。在XP中，設計過程幾乎一直貫穿着整個項目開發：從制定項目的計劃，到制定每個開發周期的計劃，到針對每個需求子產品的簡捷設計，再到設計的複核，以及一直不間斷的設計重整和優化。整個設計過程是一個螺旋式的、不斷前進和發展的過程。從這個角度看，XP把設計做到了極緻。
11.結對程式設計
在XP中，所有的代碼是由兩個程式員在同一台機器上一起寫的，這保證了所有的代碼、設計和單元測試至少被另一個人複核過，代碼、設計和測試的品質是以得到提高。看起來這樣是在浪費人力資源，但是各種研究表明這種工作方式極大地提高了工作強度和工作效率。在項目開發中，每個人會不斷地更換合作程式設計的夥伴，結對程式設計不但提高了軟體品質，而且增強了互相之間的知識交流和更新，增強了互相之間的溝通和了解，這不但有利于個人，也有利于整個項目、開發隊伍和公司。從這點看，結對程式設計不僅僅适用于XP，也适用于其他的軟體開發方法。
12.測試驅動開發
在軟體開發中，隻有通過充分的測試才能獲得充分的回報。XP中提出的測試在其他軟體開發方法中都可以見到，如功能測試、單元測試、系統測試和負荷測試等。與衆不同的是，XP将測試結合到它獨特的螺旋式增量型開發過程中，測試随着項目的進展而不斷積累。另外，由于強調整個開發小組擁有代碼，測試也是由大家共同維護的，即任何人在往代碼庫中放程式（check in）前，都應該運作一遍所有的測試；任何人如果發現了一個Bug，都應該立即為這個Bug增加一個測試，而不是等待寫那個程式的人來完成；任何人接手其他人的任務，或者修改其他人的代碼和設計，改動完以後如果能通過所有測試，就證明他的工作沒有破壞原系統，這樣測試才能真正起到幫助獲得回報的作用；而且，通過不斷地優先編寫和累積，測試應該可以基本覆寫全部的客戶和開發需求，是以開發人員和客戶可以得到盡可能充分的回報。
13.重構
XP強調簡單的設計，但簡單的設計并不是沒有設計的流水賬式的程式，也不是沒有結構、缺乏重用性的程式設計。開發人員雖然對每個使用者故事都進行簡單設計，但同時也在不斷地對設計進行改進，這個過程叫作設計的重構。重構的主要作用是努力減少程式和設計中重複出現的部分，增強程式和設計的可重用性。重構概念并不是XP首創的，它已被提出了多年，一直被認為是高品質代碼的特點之一。但XP強調把重構做到極緻，應随時随地盡可能地進行重構，程式員需要不斷地改程序式。每次改動後，都應運作測試程式，保證新系統仍然符合預定的要求。
總之，XP實施原則是：①快速回報；②假設簡單；③包容變化。
3.5.3 OpenUP
OpenUP方法最早源自IBM内部對RUP（Rational Unified Process）的靈活化改造，通過裁剪掉RUP中複雜和可選的部分，IBM于2005年推出了BUP（Basic Unified Process）和EPF（Eclipse Process Framework）。此後為了進一步推動UP族方法的發展，IBM将BUP方法捐獻給Eclipse開源社群，于2006年初将BUP改名為OpenUP。OpenUP雖然受到Scrum、XP、Eclipse Way、DSDM、AMDD等各種靈活方法的影響，但是主體仍然是RUP，即在一組被驗證的結構化生命周期過程中應用增量疊代研發模式。OpenUP基于用例和場景、風險管理和以架構為中心的模式來驅動開發。圖3-15顯示了OpenUP的總體組織架構。OpenUP方法包含3個層次/領域的實踐活動，分别針對利益幹系人領域、項目團隊領域和個人領域。
1.利益幹系人領域
利益幹系人通過項目周期計劃獲知産品的進展情況。項目周期計劃被分成4個階段，每個階段都是一個裡程碑，在裡程碑處重點關注風險和傳遞。在每個裡程碑處需要進行下列工作：對上一個裡程碑的評審、對下一個裡程碑的認可、風險識别和規避。
2.項目團隊領域
項目團隊需要以周為機關完成産品疊代開發。通常以2～6周為一個疊代周期。每個疊代周期起始時需要進行估算并完成周期疊代計劃。通常以輸出可示範版本為目标。每個疊代的策劃工作通常以小時為機關完成，而不是傳統意義上以天為機關的估算，同時需要以天為機關完成本次疊代的架構細化工作。此後進入實際研發，建議在疊代中定期完成每周Build,在疊代結束時完成穩定的疊代傳遞Build，同時花費少量時間（以小時為機關）完成疊代評審和反思。
3.個人領域
個人領域采用微增量的研發模式。一個微增量周期為幾小時或幾天不等，通常由一個人或者幾個人完成。引入微增量可以将工作分成更為細小、更易于控制的部分。微增量可以是Vision的定義，也可以是子產品設計，還可以是具體的研發和Bug修複工作。通過每日團隊會議、團隊協作工具，團隊成員之間可以分享各自的工作進展和成果，同時可以示範自己的微增量成果來加深團隊之間的溝通與了解。OpenUP并不明确定義研發中需要哪些微增量，這個部分可以結合項目實際情況或者其他模型加以确定。如何因地制宜、因項目制定靈活實施方法？如何讓靈活在軟體項目管理流程中發揮巨大作用？這是我們要認真思考的問題。
3.5.4 看闆方法
看闆一詞來自日本，源于精益生産實踐，大野耐一開發了看闆，并在1953年将其應用于豐田的主要制造廠。靈活開發将其背後的可視化管理理念借鑒過來。看闆使得項目管理實作最大的可視化，并且可以對研發的過程進行管理，記錄下使用者故事研發過程中的細節和曆程。
看闆可以讓研發過程最大限度地可視化，同時是解決團隊溝通障礙（實踐中發現也可以作為和上級溝通項目進展的重要資訊）的主要方法之一。通過看闆，項目團隊可以清楚了解已經完成的情況，正在做的及後續将有可能需要做的使用者故事，如圖3-16所示。
看闆可以作為靈活團隊每天站會讨論的核心，及時變更看闆各個使用者故事的狀态。通過看闆，靈活團隊可以清楚地了解其他成員的工作狀況及和自己相關工作的進展。
在狀态牆上，除了使用者故事、Bug之外，還會有一些諸如重構、搭建測試環境這樣的不直接産生業務價值的任務，這些任務用不同顔色的卡片，放到狀态牆上統一管理。
3.5.5 Scrumban方法
Scrumban最初設計為Scrum到看闆之間的過渡方法。它是通過其自身衍生演變而成的一種混合靈活架構和方法。團隊将Scrum作為架構，而将看闆作為過程改進方法。
在Scrumban中，工作被分解到許多小的“沖刺”，并利用看闆面闆來可視化和監督工作。将故事列在看闆面闆上，團隊通過使用在制品限制（WIP limit）來管理其工作;團隊通過召開每日例會來維持團隊之間的協作并消除阻礙；通過設定規劃觸發因素來了解何時規劃下一步工作，通常發生于在制品級别低于預設限制時。
3.5.6 精益模型
精益軟體開發模式從一開始便側重于提高過程的效率。它最初來自豐田公司的制造工業，其主要思想是分析所有的流程，以查明和消除浪費，不斷提高效率。為了達到這個目的，精益模式提出了一些概念和實用的工具。大部分的工具在制造業使用而不能直接應用于軟體開發。精益軟體開發經常提及兩個概念。一個是拉式系統（pull system）。在拉式系統中，一個流水線上的任何一個環節的任務完成後，都會從前一個環節自動提取下一個任務。該模式以客戶的需求而不是市場預測來推動工作程序。另外，通過精益模式可以最小化未完成工作及半成品的數量，它們通常被認為是開發過程中的浪費。除了拉式系統，價值流圖（value stream mapping）也經常被應用于軟體開發過程中。價值流圖能夠有效地識别過程中的浪費。
對于軟體開發而言，在開發者或者最終使用者的視角上觀察軟體開發過程，并發現和消除無益于快速傳遞的行為，即為精益的軟體開發。
3.5.7 持續傳遞
持續傳遞是經典的靈活軟體開發方法（如XP、Scrum）的自然延伸。以往的靈活方法并沒有過多關注開發測試前後的活動（如前期的需求分析、産品的使用者體驗設計、産品的部署和運作維護等），然而伴随着靈活的很多思想和原則在前後端領域的運用和升華，我們在持續傳遞這個新的大概念下看到了靈活方法和更多實踐活動的結合和更大範圍的應用。
持續傳遞所描述的軟體開發，是從原始需求識别到最終産品部署到生産環境這個過程中，需求以小批量形式在團隊的各個角色間順暢流動，能夠以較短的周期完成需求的小粒度頻繁傳遞。頻繁的傳遞周期帶來了更迅速的對軟體的回報，并且在這個過程中，需求分析、産品的使用者體驗和互動設計、開發、測試、運維等角色密切協作。持續傳遞也需要持續內建、持續部署的支援。持續內建是指個人代碼向軟體整體部分傳遞，以便盡早發現個人開發部分的問題；持續部署是指內建的代碼盡快向可運作環境傳遞，以便盡早測試；持續傳遞是指盡快向客戶傳遞，以便盡早發現生産環境中存在的問題。
持續傳遞的前提是持續部署，持續部署和持續傳遞之間的一個差別在于，部署可以很頻繁，然而實際傳遞給使用者使用則可能根據計劃進行，比部署的頻率低。要實作産品的持續部署，還需要自動化建構流水線（build pipeline）。以自動化生産線作比，自動化測試隻是其中一道品質保證工序，而要将産品從原料（需求）轉變為最終傳遞給客戶的産品，自動化的生産線起着核心作用。特别對于軟體産品，多個産品往往要內建在一起才能為客戶提供服務。多個産品的自動化建構流水線的設計也就成了一個很重要的問題。
産品在從需求到部署的過程中，會經曆若幹種不同的環境，如QA環境、各種自動化測試運作環境、生産環境等。這些環境的搭建、配置、管理，以及産品在不同環境中的具體部署，都需要完善的工具支援。缺乏這些工具，生産流水線就不可能做到完全自動化和高效。
3.5.8 DevOps
DevOps（Development和Operations的組合）是一組過程、方法與系統的統稱，用于促進開發（應用程式/軟體工程）、技術營運和品質保障（Quality Assurance,QA）部門之間的溝通、協作與整合，如圖3-17所示。它的出現是由于軟體行業日益清晰地認識到：為了按時傳遞軟體産品和服務，開發和營運工作必須緊密合作，由持續傳遞演變出了DevOps，即開發端和運維端的全程靈活思維。傳統運維人員和開發者之間的目标是有差異的，開發和營運原本有着不同的目标，開發人員希望快速送出産品，營運人員希望産品的更合理化、高性能、高可靠等，減少維護成本，開發者和運維人員之間目的上的差異就叫作“混亂之牆”。
可以把DevOps看作開發、技術營運和品質保障（QA）三者的交集，傳統的軟體組織将開發、技術營運和品質保障設為各自分離的部門。在這種環境下如何采用新的開發方法（如靈活軟體開發），這是一個重要的課題：按照從前的工作方式，開發和部署不需要技術支援或者QA深入的、跨部門的支援，而需要極其緊密的多部門協作。然而DevOps考慮的不僅是軟體部署，還包括一套針對這幾個部門間溝通與協作問題的流程和方法。
DevOps的引入能對産品傳遞、測試、功能開發和維護起到意義深遠的影響。在缺乏DevOps能力的組織中，開發與營運之間存在着資訊“鴻溝”——例如，營運人員要求更好的可靠性和安全性，開發人員則希望基礎設施響應更快，而業務使用者的需求則是更快地将更多的特性釋出給最終使用者使用。這種資訊鴻溝就是最常出問題的地方。DevOps融合一系列基本原則和實踐的方法論，将開發和運維端融合在一起，進而可以更有效地解決這類問題。
3.5.９ 其他靈活模型簡介
1.功能驅動開發
功能驅動開發（Feature Driven Development,FDD）的開發目的是滿足大型軟體開發項目的特定需求。小型商業價值功能重視能力。
2.動态系統開發方法
動态系統開發方法（Dynamic System Development Method,DSDM）是一種靈活項目傳遞架構，最初的設計目的是提高20世紀90年代普及的疊代方法的嚴格程度。該架構開發為行業上司者之間的非商業性協作方式。DSDM因強調制約因素驅動傳遞而著稱。該架構從一開始便可設定成本、品質和時間，然後利用正式的範圍優先級來滿足這些制約因素的要求。
3.SoS
SoS（Scrum of Scrums）也稱為meta Scrum，是一種由兩個或多個Scrum團隊而不是一個大型Scrum團隊所使用的技術，其中一個團隊包含3～9名成員來協調其工作。每個團隊的代表與其他團隊的代表定期召開會議，可能是每日例會，但通常是一周兩次或三次。每日例會的執行方式類似于Scrum的每日站會，與會代表将報告已完成的工作、下一步工作設定、任何目前障礙及可能會阻礙其他團隊的潛在未來障礙。其目标是確定團隊協調工作并清除障礙，以優化所有團隊的效率。具有多個團隊的大型團隊可能要求執行SoS，其遵循的模式與SoS相同，每個SoS代表向更大組織的代表報告。
當然還有其他大規模項目的靈活方法模型，如大規模靈活架構SAFe、大規模靈活開發（LeSS）等，限于篇幅，這裡不再一一介紹，感興趣的讀者可以查閱相關資料以進一步了解。
3.6 混合型生存期模型
對于整個項目，沒有必要使用單一的方法。為達到特定的目标，項目經常要結合不同的生命周期要素。預測、疊代、增量和靈活方法的組合就是一種混合方法。
1.先靈活後預測型綜合方法
圖3-１8描述了先靈活後預測型綜合方法，它們結合起來就形成一種混合模型。早期過程采用一個靈活開發生命周期，之後往往是一個預測型的釋出階段。當項目可以從靈活方法中受益并且項目的開發部分中存在不确定性、複雜性和風險時，可以使用這種方法，然後是一個明确的、可重複的釋出階段，該階段适合采用預測方法進行，可能由不同的團隊實施。例如，開發某種新的高科技産品，然後面向成千上萬的使用者推出，并對他們進行教育訓練。
2.靈活和預測綜合方法
靈活和預測綜合方法是指同一項目在整個生命周期中結合使用靈活方法和預測法，如圖3-１9所示。也許團隊正在逐漸地向靈活過渡，并使用一些方法，如短疊代、每日站會和回顧，但在項目的其他方面，如前期評估、工作配置設定和進度跟蹤等，仍然遵循了預測法。
同時使用預測法和靈活方法是一個常見的情況。将這種方法稱為靈活方法是一種誤導，因為它顯然沒有充分展現靈活思維模式、價值觀和原則。不過，由于這是一種混合方法，是以稱其為預測法也是不準确的。
3.以預測法為主、靈活方法為輔的方法
如圖3-20所示，在一個以預測法為主的項目中增加靈活要素，在這種情況下，以靈活方法處理具有不确定性、複雜性或範圍蔓延機會項目的一部分，而使用預測法管理項目的其餘部分。
4.以靈活方法為主、預測法為輔的方法
圖3-２1描述了一個以靈活方法為主、預測法為輔的方法。當某個特定要素不可協商，或者使用靈活方法不可執行時，可能會使用這種方法。例如，內建由不同供應商開發的外部元件，這些外部元件不能或不會以協作或增量方式合作。在元件傳遞之後，需要單獨內建。
3.7 “醫療資訊商務平台”生存期模型案例分析
本項目采用Scrum靈活生存期模型，産品目錄及優先級如表3-2所示，整個項目分4個疊代，即4個Sprint（沖刺疊代），表3-2也說明了每個Sprint包括的需求内容，第一個Sprint包括産品目錄中前4優先級内容。每個沖刺訂單（疊代）的周期大概是4周，每個沖刺訂單完成之後送出一個可以運作的版本。是以，本項目的Scrum靈活模式可以通過圖3-22展示。具體生存期定義如圖3-23所示。
生存期中的各階段定義如下。
1.需求分析階段
階段目标：确定需求的功能和服務。
進入條件：使用者提出初始需求。
輸入：示範系統。
輸出：關鍵特性表(Key Feature List，KFL)、業務過程定義(business process definition)、需求定義文檔。
完成标志：輸出通過使用者确認。
2.系統設計階段
階段目标：根據已有的系統結構确定應用邏輯結構、資料庫結構和頁面結構。
進入條件：送出需求分析初步結果。
輸入：關鍵特性表、商務過程定義文檔、需求定義文檔。
輸出：系統設計報告、Data Medel和資料庫、頁面流(page flow)。
完成标志：設計通過專家的對等評審。
3.項目規劃階段
階段目标：根據需求分析和系統設計結果确定本階段的時間計劃、資源需求和資金預算。
輸入：需求定義文檔、系統設計文檔。
輸出：項目計劃。
完成标志：項目計劃經合同管理者審批。
4.疊代n設計
階段目标：設計與疊代n相關的頁面、應用邏輯。
進入條件：設計通過專家的對等評審。
輸入：系統設計檔案、資料庫結構定義。
輸出：詳細設計報告。
完成标志：設計通過對等評審。
5.疊代n開發
階段目标：實作疊代n。
輸入：詳細設計報告。
輸出：程式包。
完成标志：疊代n與網站系統內建調試完畢。
6.內建測試
階段目标：通過內建環境下的軟體測試。
進入條件：疊代n與網站系統內建調試完畢。
輸入：網站系統和疊代n功能包、QA資料庫、測試案例。
輸出：測試報告。
完成标志：測試報告通過稽核。
7.确認測試
階段目标：通過QA環境下的确認測試。
進入條件：內建測試完畢，WDB可以轉入QA DB。
輸入：網站系統軟體包、QA資料庫、測試案例。
8.産品送出
階段目标：系統投入使用。
進入條件：測試報告通過稽核。
輸入：網站系統軟體包。
輸出：CD。
完成标志：使用者完成産品接收。
3.8 小結
本章介紹了軟體項目生存期模型的類型和特點，總體分預測型模型和适應型模型，适應型可以是疊代型、增量型、靈活型，混合型生存期模型是預測型和适應模型的組合。瀑布模型、V模型屬于預測型模型，快速原型模型屬于疊代型模型，漸進式階段模型屬于增量型模型，特别展開介紹Ｓcｒｕｍ、ＸＰ、看闆方法、精益模型、持續傳遞、DevOps等各靈活模型。
3.9 練習題
一、填空題
1. 生存期模型要求項目所有的活動都嚴格按照順序執行，一個階段的輸出是下一個階段的輸入。
2.總體上，項目生存期模型可以是預測型或 。
- DevOps是 和 的組合。
二、判斷題
1.瀑布模型不适合短期項目。（ ）
2.增量型生存期模型可以避免一次性投資太多帶來的風險。（ ）
3.V模型适合的項目類型是需求很明确、解決方案很明确，而且對系統的性能要求比較嚴格的項目。（ ）
4.瀑布模型和V模型都屬于預測型生存期模型。（ ）
5.瀑布模型要求項目所有的活動都嚴格按照順序執行，一個階段的輸出是下一個階段的輸入。（ ）
6.極限程式設計（eXtreme Programming，XP）從3個層面提供了13個靈活實踐。（ ）
7.靈活包括《靈活宣言》的價值觀、12個原則，以及一些通用實踐等。（ ）
三、選擇題
1.對于某項目，甲方提供了詳細、準确的需求文檔，我們的解決方案也很明确，且安全性要求非常嚴格，此項目采用（ ）比較合适。
A.瀑布模型
B.增量型生存期模型
C.V模型
D.XP模型
2.下面屬于預測型生存期模型的是（ ）。
C.Scrum模型
D.原型模型
3.下面關于靈活模型描述不正确是（ ）。
A.與傳統模型相比，靈活模型屬于自适應過程
B.可以應對需求的不斷變化
C.Scrum模型、XP模型、DevOps模型等都屬于靈活模型
D.靈活模型是預測型和疊代型的混合模型。
4.XP模型的實踐原則不包括（ ）。
A.快速回報
B.假設簡單
C.包容變化
D.詳細設計
5.在項目初期，一個項目需求不明确的情況下，應避免采用以下哪種生存期模型？（ ）
A.快速原型模型
D.Scrum模型
6.關于疊代模型，下列說法不正确的是（ ）。
A.不斷回報原型
B.可以加快開發速度
C.項目需求變化大
D.不多次送出
四、問答題
1.寫出3種你熟悉的生存期模型，并說明這些模型适用什麼情況下的項目。
2.混合模型是什麼模型？