3 開發(fā)模式選取

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

　　正確認識不同開發(fā)模式的優(yōu)劣，選取合適的開發(fā)模式，是軟件項目成功的基礎。

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

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

3.1 瀑布式開發(fā)模式

　　瀑布式開發(fā)模式（Waterfall）是早期比較流行的模式，其特點如下：

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

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

• 瀑布模型把每個開發(fā)階段都定義為黑盒，希望每個階段的人員只關心自己階段的工作，不需要關注其他階段的工作。

 

　　普遍認為，瀑布開發(fā)模式有如下缺點：

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

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

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

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

 

3.2 迭代式開發(fā)模式

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

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

　　在迭代式開發(fā)方法中，整個開發(fā)工作被組織為一系列的短小的、固定長度（如2~4周）的小項目，被稱為一系列的迭代。每一次迭代都包括了需求分析、設計、實現與測試。采用這種方法，開發(fā)工作可以在需求被完整地確定之前啟動，并在一次迭代中完成系統的一部分功能或業(yè)務邏輯的開發(fā)工作。再通過客戶的反饋來細化需求，并開始新一輪的迭代。

　　迭代式開發(fā)的優(yōu)點：

• 降低風險；

• 得到早期用戶反饋；

• 持續(xù)的測試和集成；

• 使用變更；

• 提高復用性。

 

　　迭代式開發(fā)模式的不足之處：

　　如果對需求沒有整體把握時就開始迭代開發(fā)，可能無法避免結構性風險，如新增的某個需求導致整個結構或系統設計不可用或需要大幅度調整。

 

3.3 螺旋式開發(fā)模式

　　螺旋式開發(fā)模式兼顧了快速原型的迭代特征及瀑布模型的系統化和嚴格監(jiān)控，其最大的特點是引入了其他模型不具備的風險分析，使軟件在無法排除重大風險時有機會停止，以減少損失。同時，在每個迭代階段構建原型是螺旋模型用來減少風險的方法。

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

　　螺旋式開發(fā)有如下特點：

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

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

• 實施工程：實施軟件開發(fā)和驗證；

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

 

　　螺旋式開發(fā)模式也有不足之處：

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

• 建設周期長，而軟件技術發(fā)展比較快，所以經常出現軟件開發(fā)完畢后，和當前的技術水平有了較大的差距，無法滿足當前用戶需求。

 

3.4 敏捷開發(fā)模式

　　敏捷開發(fā)模式，是當前最流行的開發(fā)模式。

　　敏捷開發(fā)，英文是Agile Development，是一種以人為核心、迭代、循序漸進的開發(fā)方式，是一種軟件開發(fā)的流程。它會指導開發(fā)人員用規(guī)定的環(huán)節(jié)去一步一步完成項目的開發(fā)。由于它采用迭代式開發(fā)，所以它主要的驅動核心是人，而不是像瀑布模型那樣，以文檔為核心。

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

　　敏捷開發(fā)提出了以下的一些原則：

• 假設需求總是會變化的，并歡迎需求的變化，因為需求的變化可能意味著可以提升產品的商業(yè)價值；

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

• 短期持續(xù)交付可運行的系統給用戶，目的是盡早取得用戶的反饋；

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

 

　　敏捷軟件開發(fā)有如下特點：

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

• 樂于接受需求變更，即使在開發(fā)后期也是如此。敏捷軟件開發(fā)能夠駕馭需求的變化，從而贏得競爭優(yōu)勢；

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

• 在整個項目開發(fā)期間，業(yè)務人員和開發(fā)人員必須朝夕工作在一起；

• 圍繞那些有推動力的人們來構建項目，給予他們所需的環(huán)境和支持，并且相信他們能夠把工作做好；

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

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

• 提倡可持續(xù)發(fā)現。出資人、開發(fā)人員及使用者應該共同維持穩(wěn)定的開發(fā)速度；

• 為了增強敏捷能力，應持續(xù)關注技術上的杰出成果和良好的設計；

• 簡潔，最小化那些沒有必要投入的工作量是至關重要的；

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

• 團隊定期反思如何變得更有戰(zhàn)斗力，然后相應地轉變并調整其行為。

 

　　敏捷開發(fā)，有scrum、XP、crystal、FDD等方法，我之前采用的是scrum方法。

 

　　敏捷開發(fā)的缺點是，恰恰是它追求的，即人的因素：

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

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

• 對人員的穩(wěn)定性要求較高，在輕文檔的思想下，人員流動導致后期維護問題較多。

 

3.5 隨意模式

　　隨意模式在不成熟的研發(fā)團隊，是最常見的，上面四種模式都不像，可以稱為“四不像”。但他們往往宣稱采用的是敏捷開發(fā)模式。

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

　　根據熵增原理，隨著需求的不斷加入，沒有良好設計或重構的系統結構往往難以為繼，軟件產品背負越來越多的技術負債，開發(fā)人員苦不堪言，指望縫縫補補趟過去，或自己跳出泥潭，項目成功的幾率往往很低。

3.6 開發(fā)模式選取探討

　　在需求相對穩(wěn)定的情況下，使用瀑布式開發(fā)模式，仍是可行的。

　　在敏捷開發(fā)大行其道之時，我們要盡量吸收敏捷開發(fā)的精髓。其次必要的文檔還是需要的。

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

　　我認為，這些開發(fā)模式并不是非此即彼、相互排斥的，可以相互參考，形成更為實用的開發(fā)模式。

 

　　我認可的合適的開發(fā)模式如下：

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

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

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

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

5. 使用敏捷開發(fā)模式，開發(fā)MVP。包括任務拆解，工作量評估，編碼實現，單元測試，聯調測試，集成測試等各個環(huán)節(jié)。

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

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

8. 然后下一次MVP迭代。

 

　　這種模式，有幾個關鍵點，可以探討：

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

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

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

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

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

 

　　我的觀點，如能了解，僅盡量多了解一點，反正還沒開始開發(fā)，代價不大。然后將已知的信息記下來。

　　不全面的需求，對架構設計是一個考驗，比如知道需要對接外部系統，不妨設立一個網關子系統，從而進行隔離；如果某個沒法確定的模塊，了解大概的業(yè)務特點，分析是否可以從本項目中剝離出來等等。

 

　　2）關于MVP迭代。

　　每次MVP迭代，首先對上個MVP進行檢查，確定哪些需要修正。然后再確定哪些需求項是本次必須的，檢查如果必須要砍需求，可砍掉哪個需求，會有什么后果？直到沒法精減。

　　MVP開發(fā)采用偽敏捷開發(fā)模式，即不完全等同于敏捷開發(fā)，輕文檔是總體指導思想，但必要的文檔還是需要的。

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

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

　　其它按照研發(fā)管理制度來執(zhí)行即可，如遵循開發(fā)約定。

　　特別需要提及的一點，關于MVP的測試，在用戶故事（敏捷開發(fā)的需求項）之處要約定驗收標準，對初期的用戶故事，測試往往只是一個正向用例，不同階段的MVP，驗收標準是不同的。

　　初期代碼實現時，仍然需要考慮異常場景，但只需要預留處理接口，不必有具體實現代碼，留待后期MVP完善時填充豐富。對于MVP簡化處理的情況，也類似處理。

 

　　3）關于文檔。

　　必要的文檔是非常需要的，要知道軟件產品，不僅是代碼，還應包括相關文檔。

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

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

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

 

　　4）關于配置管理。

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