上面一篇文章我們提過為什麼分散式需要做前後端分離，今天這篇我們從開發模式來詳解為什麼網際網路專案使用於敏捷開發？

因為筆主經歷過瀑布開發模式和敏捷開發模式這兩種開發模式，所以存在有一些自己的見解跟大家交流。

下面所以我們這邊先來簡單介紹下這兩種模式：

瀑布開發模式：

瀑布開發模式是由W.W.Royce在1970年最初提出的軟體開發模型，瀑布式開發是一種老舊的計算機軟體開發方法。
瀑布模型式是最典型的預見性的方法，嚴格遵循預先計劃的需求分析、設計、編碼、整合、測試、維護的步驟順序進行。
步驟成果作為衡量進度的方法，例如需求規格，設計文件，測試計劃和程式碼審閱等等。 總的來說，迭代週期長一些，一次性解決所有的任務，一次上線。

下面我們說說瀑布開發模式的幾個特點：

1.嚴格把軟體專案的開發分隔成各個開發階段：需求分析，要件定義，基本設計，詳細設計，編碼，單體測試，結合測試，系統測試等。使用里程碑的方式，嚴格定義了各開發階段的輸入和輸出。如果達不到要求的輸出，下一階段的工作就不展開。

2.重視和強調過程文件，在開發的中後期才會看到軟體原型，早起只能通過文件來了解系統的模樣。在這種情況下，文件的重要性彷彿已經超過了程式碼的重要性。

3.瀑布模型每個階段的人員只關心自己階段的工作，不需要關注其他階段的工作。

優點：

1、可以讓開發人員能夠更專注於本職工作，提高階段效率。

缺點：

1、在專案各個階段之間極少有反饋，風險往往遲至後期才顯露，失去及早糾正的機會。

2、專案早期即作出承諾導致對後期需求的變化難以調整，代價高昂。

3、測試人員最後才參與到專案中來，後期風險較大。

4、只有在專案生命週期的後期才能看到結果。

敏捷開發模式：

敏捷開發模式是一種從1990年代開始逐漸引起廣泛關注的一些新型軟體開發方法，是一種應對快速變化的需求的一種軟體開發能力。它們的具體名稱、理念、過程、術語都不 盡相同，相對於“非敏捷”，更強調程式設計師團隊與業務專家之間的緊密協作、面對面的溝通（認為比書面的文件更有效）、頻繁交付新的軟體版本、緊湊而自我組織 型的團隊、能夠很好地適應需求變化的程式碼編寫和團隊組織方法，也更注重軟體開發中人的作用。

在敏捷開發中，軟體專案在構建初期被切分成多個子專案，各個子專案的成果都經過測試，具備可視、可整合和可執行使用的特徵。換言之，就是把一個大專案分為多個相互聯絡，但也可獨立執行的小專案，並分別完成，在此過程中軟體一直處於可使用狀態。總的來說，拆分成多個小迭代，多次上線。

下面我們說說敏捷開發模式的幾個特點：

1、最核心的功能最先完成，容易出成果。

2、小步快跑，儘早交付，拆分各個小迭代（spring），一定的迭代週期內需要確保開發的完成，規避了一定的上線風險。

3、各組人員分迭代來有序工作，比如：設計人員出一個模組RP，開發人員完成這個模組編碼，測試人員完成這個模組測試。

4、敏捷的管理是團隊的自我管理和專案經理的服務式管理，專案經理需要根據當前開發資源確保每個迭代的的可完成性，團隊成員需有良好的自我管理能力，來確保小迭代內功能的完善；專案經理需要對整體啟到把控作用，迭代中可以根據開發進度進行各成員工作的微調，保證迭代進度的完成。

優點：

1、容易出成果，可以快速提高軟體釋出週期，敏捷確實是專案進入實質開發迭代階段，使用者很快可以看到一個基線架構版的產品。

2、測試人員能夠儘早參與進專案中來，規避了一定的風險。​​​​

3、每次迭代週期應儘可能短,以便能及時地處理需求變化和使用者反饋​​​。

缺點：

1、迭代週期端，為了不影響迭代完整，需要專案中存在經驗較強的人，要不大專案中容易遇到瓶頸問題，延誤迭代進度。

2、敏捷開發要求各員工自我管理要強，所以對人員素質和穩定性的要求又更高。

那為什麼網際網路專案要用敏捷開發呢？

1、出成果（版本）快，網際網路就是以快吃慢，一般都是迭代釋出的，追求創新，說明了需要快速響應使用者的變化，時間就是一切，需求不確定性高，這個在軟體行業也很常見;關注使用者行為，倡導以使用者為中心的產品設計。很典型的例子微信，騰訊一個月開發出來的產品，根據使用者體驗和反饋，通過反覆的小迭代來優化。

2、網際網路專案中市場反響和客戶體驗尤為重要，需要有一個快速迭代來響應客戶的需求，確保客戶的滿意度。如果是瀑布式開發，迭代慢，更改的成本也比較高。

3、隨時應對變化，因為迭代週期的減小，使得專案的彈性更足，可以更好的適應網際網路專案上更多的不確定性。

那如何從瀑布開發模式往敏捷開發模式切換？

任何開發模組的切換都是存在風險點的，包括我們前面介紹的前後端分離模式，那我們需要做什麼來減少這些風險呢？

1、優先選擇週期比較長的專案，資源較充足、素質較高的團隊來試行。

2、需要制定一套較為完整的敏捷體系，從產品到開發到測試，選型敏捷工具。

3、剛切換過來的迭代，可以適當減少迭代內容，切換過程需要緩衝時間，避免因為試行階段出現的問題，從而團隊的整個心態。

4、專案經理需要把控好任務進度，需要在迭代的中間，每天瞭解迭代執行情況，最好是每天團隊可以有晨會。