傳統開發模型vs敏捷開發模型——過程模型的變革

1、概念框架

    在瞭解一個新概念的時候，最好的方法就是把它插入到原有的概念體系中。在不只有助於對概念的記憶，更利於深入地認識概念的本質、精髓。下圖說明了「敏捷開發」在軟件工程理論體系中的位置。

 

    爲何須要軟件工程？很簡單，爲了讓咱們更好地生產軟件。這裏的「好」包含多重含義，有成本上的「好」、維護上的「好」等等。可是咱們知道，不可能坐着想「我要寫好軟件」，而後就軟件就能寫好了。咱們須要一套系統化、理論化、工程化的方法，這就是軟件工程。咱們經過研究以往的經驗整理出來一系列活動，包括：溝通、策劃、建模、構建、部署等。可是隻知道可能須要這些活動還不太夠，最好還能提供一些模型，告訴咱們設計一個軟件先進行什麼？接着進行什麼？出了問題怎麼辦？等等。換言之，咱們不僅須要活動的集合，咱們須要一種更精細的結構來指導咱們作軟件，這就是過程模型。典型的過程模型有：瀑布模型、增量模型、螺旋模型、協同模型等等，固然還包括敏捷開發模型。也就是說，「敏捷開發」是一種軟件開發的過程模型。

2、傳統過程模型

    什麼是傳統過程模型？很遺憾，我沒有找到一個權威、詳細的說法。不過，雖然這個概念的邊界可能不是很清晰，可是其核心的部分仍是獲得必定的公認。這裏，咱們分析三個典型的傳統過程模型：瀑布模型、增量模型和螺旋模型。

瀑布模型

    在20世紀80年代以前，瀑布模型是最先也是應用最普遍的軟件過程模型，如今它仍然是軟件工程中應用最普遍的過程模型。瀑布模型提供了軟件開發的基本框架。其過程是從上一項活動接收該項活動的工做對象做爲輸入，利用這一輸入實施該項活動應完成的內容，給出該項活動的工做成果，並做爲輸出傳給下一項活動。同時評審該項活動的實施，若確認，則繼續下一項活動；不然返回前面，甚至更前面的活動。

 

    由於瀑布模型把關鍵的活動明確的劃分，而且以線性的順序依次完成，因此咱們可讓活動之間的聯繫下降。這是一種優秀的性質，意味着咱們在進行一個活動的時候，只須要和上一個活動進行交互，而不須要關注過多的活動。一旦某一個活動出現問題，那麼咱們只須要去糾正上一個活動的問題便可。同時，這種線性的方式很簡單，方便了過程過程管理。

    然而，瀑布模型的線性特徵也是它問題的根源。瀑布模型老是試圖作好一件事情以後才作下一件事，可是錯誤是不可避免的。能夠看出，在整個開發過程當中，只有在最後的部署階段才能讓客戶看到這個軟件。而一般需求分析階段是最容易出現錯誤的階段，因此極可能最開始的錯誤會一直流傳到最後纔會被發現，這意味着咱們必需要更改全部的活動以求改正錯誤，一樣的問題還會出如今需求變動時。因此，瀑布模型在實際應用中經常會變爲V模型，以下圖所示。

 

 

增量模型

 

    增量模型（Incremental Model）是在項目的開發過程當中以一系列的增量方式開發系統。在增量模型中，軟件被做爲一系列的增量構件來設計、實現、集成和測試，每個構件是由多種相互做用的模塊所造成的提供特定功能的代碼片斷構成。

    增量方式包括增量開發和增量提交。增量開發是指在項目開發週期內，以必定的時間間隔開發部分工做軟件；增量提交是指在項目開發週期內，以必定的時間間隔增量方式向用戶提交工做軟件及相應文檔。根據增量的方式和形式的不一樣，分爲漸增模型和原型模型。

    增量模型融合了線性順序模型的基本成分和原型模型的迭代特徵。增量模型採用隨着日程時間的進展而交錯的線性序列。每個線性序列產生軟件的一個可發佈的「增量」。當使用增量模型時，第一個增量每每是核心的產品，也就是說第一個增量實現了基本的需求，但不少補充的特徵尚未發佈。客戶對每個增量的使用和評估，都做爲下一個增量發佈的新特徵和功能。這個過程在每個增量發佈後不斷重複，直到產生了最終的完善產品。增量模型強調每個增量均發佈一個可操做的產品。

    增量模型引進了增量包的概念，無須等到全部需求都出來，只要某個需求的增量包出來便可進行開發。雖然某個增量包可能須要進一步適應客戶的需求而且更改，但只要這個增量包足夠小，其影響對整個項目來講是能夠承受的。

    因爲增量模型可以在較短的時間內向用戶提交一些有用的工做產品，所以可以解決用戶的一些急用功能。同時，交付給用戶部分功能後，用戶學習、試用過程能夠和軟件下一個功能的開發並行。可是，增量模型也有以下缺點：

1） 因爲各個構件是逐漸併入已有的軟件體系結構中的，因此加入構件必須不破壞已構造好的系統部分，這須要軟件具有開放式的體系結構。

2） 在開發過程當中，需求的變化是不可避免的。增量模型的靈活性可使其適應這種變化的能力大大優於瀑布模型和快速原型模型，但也很容易退化爲邊作邊改模型，從而使軟件過程的控制失去總體性。

3）若是增量包之間存在相交的狀況且未很好處理，則必須作全盤系統分析，這種模型將功能細化後分別開發的方法較適應於需求常常改變的軟件開發過程。

 

3、敏捷開發模型

    敏捷軟件開發又稱敏捷開發，是一種從1990年代開始逐漸引發普遍關注的一些新型軟件開發方法，是一種應對快速變化的需求的一種軟件開發能力。雖然在國外已經獲得了普遍應用，在中國國內，敏捷開發用的還不算不少。可是隨着Agile敏捷開發的流行，愈來愈多的公司採用敏捷開發用於軟件產品和應用的開發。

    敏捷開發是一種以人爲核心、迭代、按部就班的開發方法，相對於傳統軟件開發方法的「非敏捷」，更強調程序員團隊與業務專家之間的緊密協做、面對面的溝通（認爲比書面的文檔更有效）、頻繁交付新的軟件版本、緊湊而自我組織型的團隊、可以很好地適應需求變化的代碼編寫和團隊組織方法，也更注重軟件開發中人的做用。

 

4、敏捷開發過程VS傳統開發過程

    敏捷開發區別於瀑布式的特徵很明顯，敏捷開發是以一種迭代的方式推動的，而瀑布模型式是最典型的預見性的方法，嚴格遵循預先計劃的需求分析、設計、編碼、集成、測試、維護的步驟順序進行，步驟成果做爲衡量進度的方法，例如需求規格，設計文檔，測試計劃和代碼審閱等等。敏捷開發過程當中，軟件一直處於可以使用狀態，它將項目分紅若干相互聯繫、能夠獨立運行的子項目，所以，每一個階段軟件都是可見的，客戶能夠直觀的體驗並提出意見。若是按照瀑布式流程，客戶可能在簽定開發合同3個月後，看到的還只是各類文檔（需求文檔、設計文檔、詳細設計文檔等等），客戶心理或許會不踏實。瀑布式的主要的問題是它的嚴格分級致使的自由度下降，項目早期即做出承諾致使對後期需求的變化難以調整，代價高昂。瀑布式方法在需求不明而且在項目進行過程當中可能變化的狀況下基本是不可行的。在瀑布式開發中，需求修改的時間越靠後，成本越大，因此需求分析人員的壓力很大。因爲敏捷開發是迭代式的，，而且迭代週期較短，所以很容易相應新需求或是對舊需求的修改。瀑布式開發有不少文檔，但敏捷開發不是沒有文檔，而是輕文檔。在敏捷開發過程當中，適量的文檔仍是頗有幫助，有助於整理思路，加快溝通和討論，好比概念設計文檔、架構圖、SWOT分析文檔等等，這些文檔在每一個產品版本開始以前會有產生，在每一個迭代的過程當中根據業務人員和市場的反饋也會有一些變動。經過實踐證實，這對產品的思路、溝通討論都很是有幫助。並且這些文檔，大可能是幾頁PPT，書寫和維護工做都很小。

    相比迭代式的增量開發，相同的是二者都強調在較短的開發週期提交軟件。基於Scrum的迭代增量開發通常會在一個比較長的一個迭代週期頻率下不斷交付，同時迭代中不容許有變化的需求，這樣就有一些場景讓這種迭代很困難，例如緊急的技術支持、臨時增長的很是高的優先級的需求等等，另外項目的估算很是難，致使不容易承諾。相比較，敏捷方法的週期可能更短，而且更增強調隊伍中的高度協做。敏捷開發的原則之一是擁抱變化需求時刻在變，人們對於需求的理解也時刻在變，項目環境也在不停的變化，所以你的開發方法必需要可以反映這種現實，敏捷開發方法就是屬於適應性的開發方法，而非預設性。另外，敏捷開發更適用於小型團隊，在一個辦公室工做，屬於那種通訊基本靠吼的狀態，固然團隊成員之間的交互會更方便。另外敏捷開發強調用戶（或用戶表明）要與開發團隊在一塊兒工做，便於及時溝通交流。重視交互也應該能夠算是最明顯的區別之一。這樣還有一個好處，就是有利於團隊中知識的迅速傳播。即便有人離開團隊，另外的人也能完成相應的工做。所以，「人與交互」被列爲敏捷開發價值觀之一，並排在第一位。

 

參考文獻：

[1] 普雷斯曼. 軟件工程：實踐者的研究方法[M]. 北京：機械工業出版社，2011.

[2] 竇萬峯. 系統分析與設計方法及實踐[M]. 北京：機械工業出版社，2013.

[3] 梁永幸. 淺談敏捷開發與其餘傳統開發方式的區別[J]. 電子世界，2012.12.