幾種常用的軟體生命周期模型與靈活開發解讀

瀑布式開發和靈活開發，看過軟體工程相關的書籍的同學，對瀑布模型，增量模型 ，噴泉模型，W模型，V模型以及H模型都是知道一些的，那麼現在提到更多的靈活開發它們之間有什麼不同和适用的範圍，是否靈活開發适用于所有的開發模式？在實際的實踐中又遇到了什麼樣的困難？平時各個團隊的靈活開發是靈活開發嗎？傳統項目型開發是絕對要摒棄的呢？

比如：XXXX存管：需要與銀行确定對接内容，保證符合監管要求

瀑布式開發【生命周期模型】，将軟體生命周期劃分為制定計劃、需求分析、軟體設計、程式編寫、軟體測試和運作維護等六個基本活動，并且規定了它們自上而下、互相銜接的固定次序，如同瀑布流水，逐級下落。嚴格産出各種文檔，按着流程一步步走下去。這種模式一般适用于需求比較明确、toB項目

傳統項目型開發：産品經理，需求分析師，研發負責人，測試負責人，項目經理 ，

1. 強調文檔。是以産品經理（需求文檔），需求分析師（需求說明文檔），研發負責人（研發計劃，項目研發日報），測試負責人（測試計劃，項目測試日報）
2. 每個階段有明顯的界限。嚴格定義了各開發階段的輸入和輸出；如果達不到要求的輸出，下一個階段不開展

3. 抵觸變化。各個階段的人員隻接觸到自己工作範圍内的東西，是以客戶需求的了解程度不一緻，導緻越到後面的人員對需求的變更越抵觸

   4.管理模式:PMBOK的項目管理是自上而下的指令式管理,有意識的保持資訊不透傳。

4. 比較适合相對穩定的大型項目

缺點：

a.由于各階段的開發人員隻能接觸到自己工作範圍内的東西，是以對客戶需求的了解程度高低不等，開發人員更像是定義為流水線上的勞工。

b.對于客戶需求變更，編碼人員會比設計人員更容易産生很強的抵觸情緒。

c.在每個開發階段都會有一些資訊刻意的不讓其他開發階段的人員知道（本意是為了提到效率，但實際上有時候産生的是互相的了解偏差）。

比如：減免需求：一期 完成申請；二期：完成對接賬務

疊代式開發【生命周期模型】，在某種程度上，開發疊代是一次完整地經過所有工作流程的過程：需求、分析設計、實施和測試工作流程。實質上，它類似小型的瀑布式項目。RUP認為，所有的階段都可以細分為疊代。每一次的疊代都會産生一個可以釋出的産品，這個産品是最終産品的一個子集。

不要求每一個階段的任務做的都是最完美的，而是明明知道還有很多不足的地方，卻偏偏不去完善它，而是把主要功能先搭建起來為目的，以最短的時間，最少的損失先完成一個“不完美的成果物”直至送出。然後再通過客戶或使用者的回報資訊，在這個“不完美的成果物”上逐漸進行完善。

傳統的瀑布模型相比較，疊代過程具有以下優點：

1）降低了在一個增量上的開支風險。如果開發人員重複某個疊代，那麼損失隻是這一個開發有誤的疊代的花費。

2）降低了産品無法按照既定進度進入市場的風險。通過在開發早期就确定風險，可以盡早來解決而不至于在開發後期匆匆忙忙。

3）加快了整個開發工作的進度。因為開發人員清楚問題的焦點所在，他們的工作會更有效率。

4）由于使用者的需求并不能在一開始就作出完全的界定，它們通常是在後續階段中不斷細化的。是以，疊代過程這種模式使适應需求的變化會更容易些。

疊代模型缺點是：

在項目早期開發可能有所變化 ，需有一個高素質的項目管理者和一個高技術水準的開發團隊。

比如：項目上線後的後期維護，已有項目的重構

增量模型【生命周期模型】該模型采用随着日程時間的進展而交錯的線性序列，每一個線性序列産生軟體的一個可釋出的“增量”。客戶對每一個增量的使用和評估都作為下一個增量釋出的新特征和功能，這個過程在每一個增量釋出後不斷重複，直到産生了最終的完善産品。增量模型強調每一個增量均釋出一個可操作的産品。

優點：

1)整個項目的資金不會被提前消耗，因為首先開發和傳遞了主要功能和高風險功能。

　　每個增量傳遞一個可操作的産品。

　　2)每次增量傳遞過程中擷取的經驗，有利于後面的改進，客戶也有機會對建立好的模型作出反應。

　　3)采用連續增量的方式，可把使用者經驗融入到細化的産品，這比完全重新開發要便宜得多。

　　4)“分而治之”的政策，使問題分解成可管理的小部分，避免開發團隊由于長時間的需求任務而感到淚喪。

　　5)通過同一個團隊的工作來傳遞每個增量，保持所有團隊處于工作狀态，減少了員工的工作量，工作分布曲線通過項目中的時間階段被拉平。

　　6)每次增量傳遞的結果，可以重新修訂成本和進度的風險。

　　7)便于根據市場作出反應。

　　8)降低了失敗和更改需求的風險。

　　9)更易于控制使用者需求，因為每次曾兩開發的時間很短。

　　10)由于不是一步跳到未來，是以使用者能逐漸适應新技術。

　　11)切實的項目進展，有利于進度控制。

　　12)風險分布到幾個更小的增量中，而不是集中于一個大型開發中。

　　13)由于使用者能夠從早期的增量中了解系統，是以更加了解後面增量中的需求。

需要注意的地方：

　 1)良好的可擴充性架構設計，是增量開發成功的基礎。

　　2)由于一些子產品必須在另一個子產品之前完成，是以必須定義良好的接口。

　　3)與完整的系統相比，增量方式正式的回顧和評審更難于實作，是以必須定義可行的過程。

　　4)要避免把難題往後推，首先完成的應該是高風險和重要的部分。

　　5)客戶必須認識到總體成本不會更低。

　　6)分析階段采用總體目标而不是完整的需求定義，可能不适應管理。

　　7)需要更加良好的計劃和設計，管理必須注意動态配置設定工作，技術人員必須注意相關因素的變化。

項目：AI機器人

靈活開發【項目管理方法集合】，首先把客戶最關注的軟體原型先做出來，傳遞或者上線，在實際場景中去修改彌補需求中的不足，快速修改，再次釋出版本。再次上線或者傳遞。通過一些靈活實踐方式，細化story，可以提供更小的疊代。如此循環，直到使用者（客戶）滿意。适用于需求不明确的項目、創新性的項目或者需要搶占市場的項目。

核心是疊代。

1. 客戶合作勝過合同談判，要求客戶有時間對每次疊代的成果進行确認，提出改進意見。

2. 靈活就是“快”。響應變化勝過遵循計劃。因為最終目标是讓客戶滿意，是以能夠主動接受需求變更，這就使設計出來的軟體有靈活性，可擴充性。

   3.疊代。客戶最關心的功能最先完成，軟體的功能是客戶的需求，界面的操作是客戶的“感覺”。對疊代的強調是縮短了軟體版本的周期。

   4.溝通是非常重要的，所有的開發人員對項目活動的了解應該是一緻的。開發團隊：業務團隊和技術團隊；

   如果任何一方控制了溝通，那麼項目注定會失敗。

   如果業務一方控制，項目會議上就會不斷的要求功能和傳遞日，而不太關心開發人員是否能夠全部完成或開發人員是否明白他們的真正要求；如果開發人員控制了溝通，那麼項目會議上技術術語會代替面向客戶的業務語言，開發人員也失去了通過傾聽來了解客戶真正需求的機會。

   5.個體和互動勝過過程和工具。快才可以适應目前社會的快節奏，要快就要發揮個人的個性思維多一些個性思維的增多

   6.設計周密是為了最終軟體的品質，但不表明設計比實作更重要。可以工作的軟體 勝過 面面俱到的文檔。 簡單設計，重複疊代。減少不必要的文檔。

   7.story細化，小版本。快速功能的展現，看似簡單，但對于複雜的客戶需求合理地分割與總體上的統一，要很好地二者兼顧是不容易的。

   8.需要更強的個人和團隊能力。

缺點：

靈活開發不能在一開始就給出項目的成本計劃。

在有技術問題還沒有解決的情況下不适合展開疊代.

是以靈活方法更适用于較小的隊伍，40、30、20、10人或者更少

但總的來說，在現在管理項目過程中，并沒有嚴格的按照完全的靈活或者完全的瀑布模式，都是各自摻雜了其他的方式。在實際項目過程中，過于強調模式并沒有意義，重要的是能不能預防問題的發生，在問題發生之後能不能用最小的成本解決，模式更多起一個參考作用。