3 開發模式選取
3.1 瀑布式開發模式
3.2 迭代式開發模式
3.3 螺旋式開發模式
3.4 敏捷開發模式
3.5 隨意模式
3.6 開發模式選取**
開發模式主流有瀑布式開發模式、迭代式開發模式、螺旋式開發模式和敏捷開發模式，還有實際上大部分研發團隊使用的隨意模式。
正確認識不同開發模式的優劣，選取合適的開發模式，是軟體專案成功的基礎。
何謂專案成功？我認為，最低程度是產品的各個roadmap節點都能很好地交付且被大量或正式使用；更高的層面，是產品能在應付意外需求變更或未知的需求時，仍能有較好適應性，並且有較長的生命期。某天，專案團隊成員如果談到某個軟體專案，是興奮和自豪，說明這個專案是成功的。
下文中的瀑布式開發模式、迭代式開發模式、螺旋式開發模式和敏捷開發模式章節內容，大部分取自網上，再加上我自己的一點觀點。
瀑布式開發模式（wate***ll）是早期比較流行的模式，其特點如下：
普遍認為，瀑布開發模式有如下缺點：
迭代式開發模式也被稱作迭代增量式開發或迭代進化式開發，是一種與傳統的瀑布式開發相反的軟體開發過程，它彌補了傳統開發方式中的一些弱點，具有更高的成功率和生產率。
迭代式開發，每次只設計和實現這個產品的一部分，逐步逐步完成的方法叫迭代開發，每次設計和實現乙個階段叫做乙個迭代。
在迭代式開發方法中，整個開發工作被組織為一系列的短小的、固定長度（如2~4周）的小專案，被稱為一系列的迭代。每一次迭代都包括了需求分析、設計、實現與測試。採用這種方法，開發工作可以在需求被完整地確定之前啟動，並在一次迭代中完成系統的一部分功能或業務邏輯的開發工作。再通過客戶的反饋來細化需求，並開始新一輪的迭代。
迭代式開發的優點：
迭代式開發模式的不足之處：
如果對需求沒有整體把握時就開始迭代開發，可能無法避免結構性風險，如新增的某個需求導致整個結構或系統設計不可用或需要大幅度調整。
螺旋式開發模式兼顧了快速原型的迭代特徵及瀑布模型的系統化和嚴格監控，其最大的特點是引入了其他模型不具備的風險分析，使軟體在無法排除重大風險時有機會停止，以減少損失。同時，在每個迭代階段構建原型是螺旋模型用來減少風險的方法。
螺旋模型更適合大型的昂貴的系統級的軟體開發，一開始應用的規模很小，當專案被定義得更好、更穩定時逐漸展開。其核心在於不需要在剛開始時就把所有事情都定義清楚，可以先定義最重要的功能去實現它，然後聽取客戶的意見，再進入下乙個階段，入此不斷迴圈、重複，直到得到滿意的產品。螺旋模型在很大程度上是一種風險驅動的方法體系，因為在每個階段及經常發生的迴圈之前，都必須先進行風險評估。強調可選方案和約束條件從而支援軟體的重用，有助於將軟體質量作為特殊目標融入產品開發之中。
螺旋式開發有如下特點：
螺旋式開發模式也有不足之處：
敏捷開發模式，是當前最流行的開發模式。
敏捷開發，英文是agile development，是一種以人為核心、迭代、循序漸進的開發方式，是一種軟體開發的流程。它會指導開發人員用規定的環節去一步一步完成專案的開發。由於它採用迭代式開發，所以它主要的驅動核心是人，而不是像瀑布模型那樣，以文件為核心。
敏捷開發模式，具有應對快速變化的需求的軟體開發能力。它的具體名稱、理念、過程、術語都不盡相同，相對於非敏捷開發，更強調程式設計師團隊與業務專家之間的緊密協作及面對面溝通，比單純通過書面文件溝通更有效，能更頻繁地交付新的軟體版本，使自我組織、自我約束的團隊能夠更好地適應需求的變化，也更注重軟體開發過程中人的作用。
敏捷開發提出了以下的一些原則：
敏捷軟體開發有如下特點：
敏捷開發，有scrum、xp、crystal、fdd等方法，我之前採用的是scrum方法。
敏捷開發的缺點是，恰恰是它追求的，即人的因素：
隨意模式在不成熟的研發團隊，是最常見的，上面四種模式都不像，可以稱為「四不像」。但他們往往宣稱採用的是敏捷開發模式。
隨意模式，沒有需求分析和系統設計的階段，需求加入很隨意，產品經理或市場人員整乙個feature list，描述下功能要求，然後在白板或白紙上畫幾個框圖，就開始編碼實現了，也沒有文件輸出和積累。很多情況也沒有軟體質量保障體系，軟體質量取決於開發人員的素質。
根據熵增原理，隨著需求的不斷加入，沒有良好設計或重構的系統結構往往難以為繼，軟體產品揹負越來越多的技術負債，開發人員苦不堪言，指望縫縫補補趟過去，或自己跳出泥潭，專案成功的機率往往很低。
在需求相對穩定的情況下，使用瀑布式開發模式，仍是可行的。
在敏捷開發大行其道之時，我們要盡量吸收敏捷開發的精髓。其次必要的文件還是需要的。
快速迭代僅僅是外部表徵，每日站會也不能淪為形式，目的是充分溝通和消除風險。
我認為，這些開發模式並不是非此即彼、相互排斥的，可以相互參考，形成更為實用的開發模式。
我認可的合適的開發模式如下：
全面了解產品需求，不能忽視效能和非功能性需求。
根據全面的產品需求，進行軟體需求分析，某些產品需求，只需要了解其有無特別的技術要求或限制，無需詳細展開；目的是消除結構性風險，免得系統設計考慮不全面。
進行系統設計，並驗證各產品需求點是否都可以在此架構中實現，以及對未來可能需求的擴充套件靈活性。
抽取出mvp，即最小可行產品（minimum viable product，簡稱mvp）。快速地構建出符合產品預期功能的最小功能集合，這個最小集合所包含的功能足以滿足產品部署的要求並能夠檢驗有關客戶與產品互動的關鍵假設。用最快、最簡明的方式建立乙個可用的產品原型，這個原型要表達出你產品最終想要的效果，然後通過迭代來完善細節。（此處借鑑了螺旋式開發模式的思想）。
使用敏捷開發模式，開發mvp。包括任務拆解，工作量評估，編碼實現，單元測試，聯調測試，整合測試等各個環節。
mvp開發過程輸出下列文件：子系統或模組的概要設計文件；資料庫設計文件；介面文件；重要功能的詳細設計文件。（此處借鑑了瀑布式開發模式的思想）。
mvp驗收或上線，專案覆盤。
然後下一次mvp迭代。
這種模式，有幾個關鍵點，可以**：
1）全面了解產品需求，是基礎。
問題是，產品經理說，有些模組或功能，需求暫時沒法清楚地描述出來。
如對接外部系統，只知道對接，資料內容、格式和互動方式沒法搞清楚，是乙個黑盒子，不同外部系統對接方式也可能不同。
還有如某個功能模組，涉及一大塊業務，業務邏輯還沒理順，想想頭都要炸了，到時候做不做還兩說呢。
怎麼說呢，反正是朦朧派。
我的觀點，如能了解，僅盡量多了解一點，反正還沒開始開發，代價不大。然後將已知的資訊記下來。
不全面的需求，對架構設計是乙個考驗，比如知道需要對接外部系統，不妨設立乙個閘道器子系統，從而進行隔離；如果某個沒法確定的模組，了解大概的業務特點，分析是否可以從本專案中剝離出來等等。
2）關於mvp迭代。
每次mvp迭代，首先對上個mvp進行檢查，確定哪些需要修正。然後再確定哪些需求項是本次必須的，檢查如果必須要砍需求，可砍掉哪個需求，會有什麼後果？直到沒法精減。
mvp開發採用偽敏捷開發模式，即不完全等同於敏捷開發，輕文件是總體指導思想，但必要的文件還是需要的。
資料庫文件，可使用ddl檔案；介面文件，可考慮yapi（或直接讓**支援swagger，然後將介面視覺化）。
其它按照研發管理制度來執行即可，如遵循開發約定。
特別需要提及的一點，關於mvp的測試，在使用者故事（敏捷開發的需求項）之處要約定驗收標準，對初期的使用者故事，測試往往只是乙個正向用例，不同階段的mvp，驗收標準是不同的。
初期**實現時，仍然需要考慮異常場景，但只需要預留處理介面，不必有具體實現**，留待後期mvp完善時填充豐富。對於mvp簡化處理的情況，也類似處理。
3）關於文件。
必要的文件是非常需要的，要知道軟體產品，不僅是**，還應包括相關文件。
計算機語言是表達思想的一種方式，**不僅輸入給編譯器（或解析器）的，同時，也是呈現給軟體工程師的。
由於it行業人員的高流動性，以及業務擴充套件和變動帶來的**維護和變動需求，僅有**無文件或文件稀少的情況給**維護工作帶來極大的困難，容易埋下更多的坑，此將大大縮短軟體的生命期。
敏捷開發是輕文件，而不是沒文件！但可惜現狀是幾乎沒文件。開發人員也許幹得很high，但後期維護人員卻苦不堪言，在我看來，這就不是乙個成功的產品，只能算是一次成功的專案實施。
4）關於配置管理。
在mvp迭代乙個階段完成後，進行專案覆盤。此時要將資料庫指令碼和介面文件納入git配置管理。介面文件（**支援swagger，或從yapi匯出），放入**docs/api目錄下；資料庫指令碼，放入docs/sql目錄下；還可以考慮將markdown格式的設計、分析文件納入基線管理。這樣，文件與**的基線版本就對齊了。
軟體開發周期（各個階段）
需求階段 開發階段 測試階段 灰度發布階段 發布階段 通過溝通交流，產出需求文件，包含頁面的內容，則需要對應的進行設計稿的設計。通過評審會，使涉及到的人都有自己的了解，同時對需求進行改進。涉及到的人包含 產品 專案pm 分析 編寫需求文件 設計人員 設計設計稿 開發人員 了解需求，了解需求所對應的用...
軟體開發模式
軟體的開發模式包括 大棒開發法 邊寫邊改法 瀑布法 快速原型法和螺旋模式法，它們的定義及特點如下 第一，大棒開發法。它是源於能量爆發創造宇宙，萬物都由能量和物質積聚而成的理論，但如果不是遵循某種正確的排列和組合，形成的將不是預先期望的事物 大棒模式與上述理論一樣 一大堆能量 這裡指開發軟體所需的人力...
軟體開發模式
軟體開發模式大概有11種，如下所示 邊做邊改模型 build and fix model 瀑布模型 wate ll model 快速原型模型 rapid prototype model 增量模型 incremental model 迭代模型 stagewise model 螺旋模型 spiral m...