理順軟件開發各個環節-2

目錄

3 開發模式選取

　　3.1 瀑布式開發模式

　　3.2 迭代式開發模式

　　3.3 螺旋式開發模式

　　3.4 敏捷開發模式

　　3.5 隨意模式

　　3.6 開發模式選取探討

 

3 開發模式選取

　　開發模式主流有瀑布式開發模式、迭代式開發模式、螺旋式開發模式和敏捷開發模式，還有實際上大部分研發團隊使用的隨意模式。

　　正確認識不一樣開發模式的優劣，選取合適的開發模式，是軟件項目成功的基礎。

　　何謂項目成功？我認爲，最低程度是產品的各個Roadmap節點都能很好地交付且被大量或正式使用；更高的層面，是產品能在應付意外需求變動或未知的需求時，仍能有較好適應性，而且有較長的生命期。某天，項目團隊成員若是談到某個軟件項目，是興奮和自豪，說明這個項目是成功的。

　　下文中的瀑布式開發模式、迭代式開發模式、螺旋式開發模式和敏捷開發模式章節內容，大部分取自網上，再加上我本身的一點觀點。

3.1 瀑布式開發模式

　　瀑布式開發模式（Waterfall）是早期比較流行的模式，其特色以下：

• 注重軟件開發的各個階段：需求分析、系統設計、編程實現、軟件測試、軟件維護，使用里程碑的方式，嚴格定義了各開發階段的輸入和輸出。若是達不到要求的輸出，下一階段的工做就不展開；爲項目提供了按階段劃分的檢查點；

• 強調文檔輸出，文檔的重要性高於代碼；

• 瀑布模型把每一個開發階段都定義爲黑盒，但願每一個階段的人員只關心本身階段的工做，不須要關注其餘階段的工做。

 

　　廣泛認爲，瀑布開發模式有以下缺點：

• 不適應需求變動，特別是需求不肯定的項目；

• 文檔量太重，在需求變更時，文檔一致性維護成本太高；

• 開發模型是線性的，用戶只有等到整個過程的末期才能見到開發成果，從而大大增長了開發風險；

• 若是需求與用戶的設想出現了偏離，這種錯誤將會貫穿整個項目週期，設計受需求的影響，代碼受設計的影響，直到項目接近完成，將產品交付給用戶使用測試時，錯誤才被用戶提出，這時項目已處於尾聲，爲時已晚。

 

3.2 迭代式開發模式

　　迭代式開發模式也被稱做迭代增量式開發或迭代進化式開發，是一種與傳統的瀑布式開發相反的軟件開發過程，它彌補了傳統開發方式中的一些弱點，具備更高的成功率和生產率。

　　迭代式開發，每次只設計和實現這個產品的一部分，逐步逐步完成的方法叫迭代開發，每次設計和實現一個階段叫作一個迭代。

　　在迭代式開發方法中，整個開發工做被組織爲一系列的短小的、固定長度（如2~4周）的小項目，被稱爲一系列的迭代。每一次迭代都包括了需求分析、設計、實現與測試。採用這種方法，開發工做能夠在需求被完整地肯定以前啓動，並在一次迭代中完成系統的一部分功能或業務邏輯的開發工做。再經過客戶的反饋來細化需求，並開始新一輪的迭代。

　　迭代式開發的優勢：

• 下降風險；

• 獲得早期用戶反饋；

• 持續的測試和集成；

• 使用變動；

• 提升複用性。

 

　　迭代式開發模式的不足之處：

　　若是對需求沒有總體把握時就開始迭代開發，可能沒法避免結構性風險，如新增的某個需求致使整個結構或系統設計不可用或須要大幅度調整。

 

3.3 螺旋式開發模式

　　螺旋式開發模式兼顧了快速原型的迭代特徵及瀑布模型的系統化和嚴格監控，其最大的特色是引入了其餘模型不具有的風險分析，使軟件在沒法排除重大風險時有機會中止，以減小損失。同時，在每一個迭代階段構建原型是螺旋模型用來減小風險的方法。

　　螺旋模型更適合大型的昂貴的系統級的軟件開發，一開始應用的規模很小，當項目被定義得更好、更穩定時逐漸展開。其核心在於不須要在剛開始時就把全部事情都定義清楚，能夠先定義最重要的功能去實現它，而後聽取客戶的意見，再進入下一個階段，入此不斷循環、重複，直到獲得滿意的產品。螺旋模型在很大程度上是一種風險驅動的方法體系，由於在每一個階段及常常發生的循環以前，都必須先進行風險評估。強調可選方案和約束條件從而支持軟件的重用，有助於將軟件質量做爲特殊目標融入產品開發之中。

　　螺旋式開發有以下特色：

• 制定計劃：肯定軟件目標，選定實施方案，弄清楚項目開發的限制條件；

• 風險分析：分析、評估所選方案，考慮如何識別和消除風險；

• 實施工程：實施軟件開發和驗證；

• 客戶評估：評價開發工做，提出修正建議，制定下一步計劃。

 

　　螺旋式開發模式也有不足之處：

• 很難讓用戶確信這種演化方法的結果是能夠控制的；

• 建設週期長，而軟件技術發展比較快，因此常常出現軟件開發完畢後，和當前的技術水平有了較大的差距，沒法知足當前用戶需求。

 

3.4 敏捷開發模式

　　敏捷開發模式，是當前最流行的開發模式。

　　敏捷開發，英文是Agile Development，是一種以人爲核心、迭代、按部就班的開發方式，是一種軟件開發的流程。它會指導開發人員用規定的環節去一步一步完成項目的開發。因爲它採用迭代式開發，因此它主要的驅動核心是人，而不是像瀑布模型那樣，以文檔爲核心。

　　敏捷開發模式，具備應對快速變化的需求的軟件開發能力。它的具體名稱、理念、過程、術語都不盡相同，相對於非敏捷開發，更強調程序員團隊與業務專家之間的緊密協做及面對面溝通，比單純經過書面文檔溝通更有效，能更頻繁地交付新的軟件版本，使自我組織、自我約束的團隊可以更好地適應需求的變化，也更注重軟件開發過程當中人的做用。

　　敏捷開發提出瞭如下的一些原則：

• 假設需求老是會變化的，並歡迎需求的變化，由於需求的變化可能意味着能夠提高產品的商業價值；

• 設計是演進式的，並要保持簡單設計和彈性設計，以便能快速響應需求的變化，而需求變化老是會引發設計的腐化，所以，常常性的對代碼進行重構是必須的；

• 短時間持續交付可運行的系統給用戶，目的是儘早取得用戶的反饋；

• 更多原則可參考相關敏捷開發的書籍和文章。

 

　　敏捷軟件開發有以下特色：

• 首要任務是儘早地、持續地交付可評價的軟件，以使客戶滿意；

• 樂於接受需求變動，即便在開發後期也是如此。敏捷軟件開發可以駕馭需求的變化，從而贏得競爭優點；

• 頻繁交付可以使用的軟件，交付的間隔越短越好，能夠從幾個月縮減到幾個星期；

• 在整個項目開發期間，業務人員和開發人員必須朝夕工做在一塊兒；

• 圍繞那些有推進力的人們來構建項目，給予他們所需的環境和支持，而且相信他們可以把工做作好；

• 開發團隊及在開發團隊內部進行最快速、有效的傳遞信息的方法是面對面交談；

• 可以使用的軟件是進度的主要衡量指標；

• 提倡可持續發現。出資人、開發人員及使用者應該共同維持穩定的開發速度；

• 爲了加強敏捷能力，應持續關注技術上的傑出成果和良好的設計；

• 簡潔，最小化那些沒有必要投入的工做量是相當重要的；

• 最好的架構、需求和設計都源於自我組織的團隊；

• 團隊按期反思如何變得更有戰鬥力，而後相應地轉變並調整其行爲。

 

　　敏捷開發，有scrum、XP、crystal、FDD等方法，我以前採用的是scrum方法。

 

　　敏捷開發的缺點是，偏偏是它追求的，即人的因素：

• 對人員的素質要求較高，須要有較好的溝通能力；

• 彼此信任的基礎是各自的能力，不能因爲個別成員的能力拖累總體進度；

• 對人員的穩定性要求較高，在輕文檔的思想下，人員流動致使後期維護問題較多。

 

3.5 隨意模式

　　隨意模式在不成熟的研發團隊，是最多見的，上面四種模式都不像，能夠稱爲「四不像」。但他們每每宣稱採用的是敏捷開發模式。

　　隨意模式，沒有需求分析和系統設計的階段，需求加入很隨意，產品經理或市場人員整一個feature list，描述下功能要求，而後在白板或白紙上畫幾個框圖，就開始編碼實現了，也沒有文檔輸出和積累。不少狀況也沒有軟件質量保障體系，軟件質量取決於開發人員的素質。

　　根據熵增原理，隨着需求的不斷加入，沒有良好設計或重構的系統結構每每難覺得繼，軟件產品揹負愈來愈多的技術負債，開發人員苦不堪言，期望縫縫補補趟過去，或本身跳出泥潭，項目成功的概率每每很低。

3.6 開發模式選取探討

　　在需求相對穩定的狀況下，使用瀑布式開發模式，還是可行的。

　　在敏捷開發大行其道之時，咱們要儘可能吸取敏捷開發的精髓。其次必要的文檔仍是須要的。

　　快速迭代僅僅是外部表徵，每日站會也不能淪爲形式，目的是充分溝通和消除風險。

　　我認爲，這些開發模式並非非此即彼、相互排斥的，能夠相互參考，造成更爲實用的開發模式。

 

　　我承認的合適的開發模式以下：

1. 全面瞭解產品需求，不能忽視性能和非功能性需求。

2. 根據全面的產品需求，進行軟件需求分析，某些產品需求，只須要了解其有無特別的技術要求或限制，無需詳細展開；目的是消除結構性風險，省得系統設計考慮不全面。

3. 進行系統設計，並驗證各產品需求點是否均可以在此架構中實現，以及對將來可能需求的擴展靈活性。

4. 抽取出MVP，即最小可行產品（Minimum Viable Product，簡稱MVP）。快速地構建出符合產品預期功能的最小功能集合，這個最小集合所包含的功能足以知足產品部署的要求並可以檢驗有關客戶與產品交互的關鍵假設。用最快、最簡明的方式創建一個可用的產品原型，這個原型要表達出你產品最終想要的效果，而後經過迭代來完善細節。（此處借鑑了螺旋式開發模式的思想）。

5. 使用敏捷開發模式，開發MVP。包括任務拆解，工做量評估，編碼實現，單元測試，聯調測試，集成測試等各個環節。

6. MVP開發過程輸出下列文檔：子系統或模塊的概要設計文檔；數據庫設計文檔；接口文檔；重要功能的詳細設計文檔。（此處借鑑了瀑布式開發模式的思想）。

7. MVP驗收或上線，項目覆盤。

8. 而後下一次MVP迭代。

 

　　這種模式，有幾個關鍵點，能夠探討：

　　1）全面瞭解產品需求，是基礎。

　　問題是，產品經理說，有些模塊或功能，需求暫時無法清楚地描述出來。

　　如對接外部系統，只知道對接，數據內容、格式和交互方式無法搞清楚，是一個黑盒子，不一樣外部系統對接方式也可能不一樣。

　　還有如某個功能模塊，涉及一大塊業務，業務邏輯還沒理順，想一想頭都要炸了，到時候作不作還兩說呢。

　　怎麼說呢，反正是朦朧派。

 

　　個人觀點，如能瞭解，僅儘可能多瞭解一點，反正還沒開始開發，代價不大。而後將已知的信息記下來。

　　不全面的需求，對架構設計是一個考驗，好比知道須要對接外部系統，不妨設立一個網關子系統，從而進行隔離；若是某個無法肯定的模塊，瞭解大概的業務特色，分析是否能夠從本項目中剝離出來等等。

 

　　2）關於MVP迭代。

　　每次MVP迭代，首先對上個MVP進行檢查，肯定哪些須要修正。而後再肯定哪些需求項是本次必須的，檢查若是必需要砍需求，可砍掉哪一個需求，會有什麼後果？直到無法精減。

　　MVP開發採用僞敏捷開發模式，即不徹底等同於敏捷開發，輕文檔是整體指導思想，但必要的文檔仍是須要的。

　　數據庫文檔，可以使用DDL文件；接口文檔，可考慮YApi（或直接讓代碼支持swagger，而後將接口可視化）。

　　其它需求分析、設計文檔可使用MarkDown格式，用知識庫管理，便於在線瀏覽和更新。

　　其它按照研發管理制度來執行便可，如遵循開發約定。

　　特別須要說起的一點，關於MVP的測試，在用戶故事（敏捷開發的需求項）之處要約定驗收標準，對初期的用戶故事，測試每每只是一個正向用例，不一樣階段的MVP，驗收標準是不一樣的。

　　初期代碼實現時，仍然須要考慮異常場景，但只須要預留處理接口，沒必要有具體實現代碼，留待後期MVP完善時填充豐富。對於MVP簡化處理的狀況，也相似處理。

 

　　3）關於文檔。

　　必要的文檔是很是須要的，要知道軟件產品，不只是代碼，還應包括相關文檔。

　　計算機語言是表達思想的一種方式，代碼不只輸入給編譯器（或解析器）的，同時，也是呈現給軟件工程師的。

　　因爲IT行業人員的高流動性，以及業務擴展和變更帶來的代碼維護和變更需求，僅有代碼無文檔或文檔稀少的狀況給代碼維護工做帶來極大的困難，容易埋下更多的坑，此將大大縮短軟件的生命期。

　　敏捷開發是輕文檔，而不是沒文檔！但惋惜現狀是幾乎沒文檔。開發人員也許乾得很high，但後期維護人員卻苦不堪言，在我看來，這就不是一個成功的產品，只能算是一次成功的項目實施。

 

　　4）關於配置管理。

　　在MVP迭代一個階段完成後，進行項目覆盤。此時要將數據庫腳本和接口文檔歸入git配置管理。接口文檔（代碼支持swagger，或從YApi導出），放入代碼docs/api目錄下；數據庫腳本，放入docs/sql目錄下；還能夠考慮將markdown格式的設計、分析文檔歸入基線管理。這樣，文檔與代碼的基線版本就對齊了。