淺談敏捷軟件開發與傳統軟件工程的對比與敏捷開發產生的緣由

引言

　　在「計算機程序的蠻荒時代」，人們對於程序的設計、編寫是隨想隨寫、靈活變化的。正如咱們初學各類編程語言時那樣，彷佛把程序寫對也不是什麼很難的事情。然而，這種程序設計模式或許適用於幾百行至幾千行的小程序，而當咱們面對更大的軟件規模、更多的代碼行數以及更復雜的人員架構時，這種隨想隨寫的程序開發模式彷佛再也不適用，因而令人們遇到了「軟件危機」，進而促使了軟件工程這樣一門學科的產生。

　　在我上一門程序設計的課程的時候，老師講過，當咱們學習各類語言、算法和數據結構時，咱們學習的是怎樣進行「程序的設計」，而不少人會產生一個誤區：程序=軟件。然而並不是如此，軟件是程序的更上一層結構，即軟件=程序+模板。暫且不考慮這個等式的右側是否僅僅是「程序」和「文檔」，我認爲前半句話十分正確，即軟件是比程序更廣的概念。程序僅僅是軟件的實現的一部分，雖然能夠說是很重要的一部分，但不是所有，軟件還包括了輔助編寫、理解程序的文檔等一些列輔助元素。而軟件工程，正是爲了從算法、數據結構和語言等之外的角度來探討如何編寫出正確、高效的軟件；如何對這些程序進行高效的編寫和組織。

　　隨着軟件工程的發展以及生產環境的多變，軟件工程逐漸演化出各類各樣的門派以及方法論。這些方法論不關乎對錯，只是在不一樣的狀況下有不一樣的適用狀況，以及不一樣的開發團隊對不一樣的方法論有着不一樣的喜愛。而這些適用狀況的不一樣和喜愛的不一樣正是由於這些方法有着不一樣的特性。

　　大致上來講，當下軟件工程能夠分爲兩種明顯區分開的流派，即傳統軟件工程方法和敏捷開發方法。其中傳統軟件工程開發方法產生較早，較爲成熟；而敏捷開發方法比較年輕，但最近更加受到青睞。本文接下來就對兩種軟件開發方法進行對比，並試圖解釋敏捷開發方法——這一近期發展出來的熱門方法論的產生的背後的因素。

敏捷軟件開發與傳統軟件工程的對比

傳統軟件工程

產生背景

　　1968年，北約在學術會議中創造了「軟件危機」一詞，而且首次提出了「軟件工程」的概念，以應對「軟件危機」。因爲程序變得愈來愈複雜，可用的工具愈來愈多，需求愈來愈難以實現，以及參與編寫軟件的人員愈來愈多，計算機軟件再也不像是之前那樣用磚瓦搭一個小房子那樣簡單——雖然這也是個技術活——而變成了搭建一座摩天大樓，這須要很精密的計劃、規範標準以及堅實的技術支持。 

分類及技術特色

• 瀑布模型

　　瀑布模型的提出時間很早，更像是一個理想的軟件工程模型。瀑布模型以一個線性的工做流來組織軟件開發的過程，從溝通、策劃、建模、構建直到部署[2]。瀑布模型指出要在進行構建以前進行完整的探討、設計和分析，並造成大量的文檔。每一步均在完整的前一步的基礎上進行，而且造成大量的文檔。瀑布模型過於理想，以致於其不能適應變化。因爲後一個階段徹底在前一個階段的基礎上進行，若是前一個階段沒法順利完成或須要返工，例如需求的不明確、改變等，會致使瀑布模型的總體性返工，形成大量須要修改的文檔和浪費的文檔，以及系統的遺留問題，最終使得整個系統的崩潰。事實上也幾乎沒有人使用瀑布模型，瀑布模型沒法避免地須要進行返工[3]。

傳統的瀑布模型圖例

• 增量過程模型

　　增量過程是瀑布模型的改進與進化。增量過程將軟件開發過程定義爲若干個增量（一般以不一樣的功能、組件來劃分）。每一個增量各自以線性開發過程來進行。增量過程模型的好處在於它可以不斷地（至少是按部分地）產生可使用的程序原型。

• 演化過程模型

　　演化過程也是對瀑布模型的改進，也能夠稱爲是迭代開發過程。瀑布模型不能適應需求的不肯定和改變，而演化過程能夠先出產一個原型，並根據開發狀況和用戶需求的肯定、改變已經用戶的反饋進行迭代式開發，而且每次迭代依舊按照線性模型來進行。演化過程模型能夠較快地產生原型產品並進行試用。與增量過程模型不一樣的是，增量過程模型着眼於模塊化的劃分與迭代，而演化過程模型着眼於軟件的「深度」上的迭代。演化過程模型也能夠應對需求的變化，但爲了實現原型產品可能會生成許多歷史遺留問題，這每每會致使大量的時間和生產效率的消耗。

• 螺旋模型

　　螺旋模型是一種特殊的迭代開發模型，可是它的地位十分重要。螺旋模型通常用大型的、重要的軟件開發，而且從概念開發一直延伸到了軟件的整個生命週期。在每一層螺旋中，螺旋模型使用瀑布模型，而每一圈表明軟件的一個層次：最中間表明原型，外面表明軟件的完整實現、改進、維護直至進化。

　　螺旋模型還有一個特色，就是它必定要在每一輪循環迭代中進行風險評估以消除風險、說服客戶接受迭代式的產品演化，所以也被成爲風險驅動型開發方法[4]。

小結

　　上述傳統軟件開發方法，不管是瀑布模型這種線性模型，仍是增量、演化和螺旋模型，都離不開先進行完整的評估、設計階段，再進行實現、測試。而每一步的評估、設計都須要造成諸多的文檔以及不可改變（至少在當階段不可改變）的各類要求、約束。

敏捷軟件開發

　　敏捷軟件開發從1990年代開始逐漸引發普遍關注。2001年，敏捷方法的推崇者在美國猶他州雪鳥滑雪聖地進行了一次聚會，造成了「敏捷聯盟」並發表了《敏捷宣言》，在這個宣言中，最重要的部分即如下幾條：

• 個體和互動高於流程和工具。
• 工做的軟件高於詳盡的文檔。
• 客戶合做高於合同談判。
• 響應變化高於遵循計劃。

　　與之相對地，傳統軟件開發方法被稱爲是「非敏捷」的。與傳統方法相比，敏捷方法更注重人與人的直接交流，更注重軟件的快速迭代，更注重緊湊的自我人員組織，最重要的一點：更注重變化。

 

快速迭代——敏捷開發方法的核心

 

　　敏捷開發方法將文檔視爲一種軟件開發的記錄，而非軟件開發的指導，固然也就更加優先處理軟件的實現，即產生工做的軟件。敏捷方法的支持者認爲，完備的設計、規劃及其文檔是對後續進度的約束，而且不能適應變化。所以，敏捷開發方法因爲將更多的精力放在真正的軟件的實現上，可以更快地進行迭代。

　　敏捷開發方法最典型的特色即擁抱變化。當用戶的需求模糊、善變時，敏捷開發方法因爲其極短的迭代流程和極快的迭代速度，能夠很方便地相應用戶的變化。而敏捷開發方法快速迭代的特性，使得其具備更加關注人與人，包括開發人員之間和開發者－用戶之間的時時交流、反饋。試想如下場景：用戶委託你進行一些改進，而你須要進行完備的討論、設計、編寫文檔、實現與測試，而你的用戶須要等待好久的話，你和用戶之間的交流是不連續的；而在敏捷開發方法中，因爲迭代很是迅速，使得你和用戶、你和同事之間的交流是連續的，所以須要更加關注人的參與以及用戶的不斷反饋。在敏捷開發方法中，用戶彷佛成爲了開發團隊的一份子，也在爲軟件的完善而出力。所以，敏捷開發方法很是注重客戶的合做。

　　從上述特性來看，敏捷開發方法並不是那麼容易實現。若是敏捷開發方法實現得很差，很容易退化爲「隨想隨寫」模式，所以須要很高的人員素質。所以，敏捷開發方法很是注重「人的因素」。敏捷過程當中要發掘出開發人員的潛力，開發人員要一直工做在一塊兒，具備很是全面的能力，包括程序的編寫和合做、決策能力。所以，敏捷開發過程也是一種人員的組織方法，要求人員充分信任、組織文化好、開發人員決定能獲得充分支持（包括來自客戶的支持）以及精幹的隊伍（所以敏捷開發方法通常適用於小型團隊）。

　　敏捷開發方法之下也有許多的更加具體的方法論，例如極限編程XP、Scrum和測試驅動設計等。這些方法是對敏捷開發方法的更進一步定義與約束，而且提供了一些實用的「工具」來進行管理。

　　總的來講，敏捷開發方法不僅是流程如何分佈這麼簡單，其綜合了傳統開發方法的許多精華，去掉了不適合他們的部分，造成了本身的一套包含軟件開發流程、人員組織、管理、平常任務分配和如何管理人員的思想的一系列方法的體系。

對比與使用條件

　　傳統開發方法更加註重前瞻性、計劃性以及工程化，即在充分的預見、設計和準備下，開發人員的開發工做能夠變得簡單和有條理。傳統開發方法更加適用於不易更改的需求、超大型的軟件和難以迭代的軟件。傳統開發方法更像是傳統制造業，例如，硬件的開發過程當中沒法進行「敏捷開發」，由於硬件的難以迭代的特性使得其沒法適用敏捷開發方法——除非有一天科技的進步使其成爲可能。傳統開發方法的適用條件也是如此，例如火箭發射程序等，這類程序須要十足的前瞻和穩定性，傳統開發方法是其不二選擇。

　　而軟件畢竟是軟件，其「軟」的特色使其有別於硬件。軟件易於更改，易於發佈，所以也就易於迭代。敏捷開發方法比迭代式開發方法的迭代週期更短，也不準要螺旋式開發方法對風險的完整評估——只須要不斷地迎接變化。經過前文的分析，敏捷開發方法更適用於那些人少但精煉、高素質的開發團隊，而且適用於那些市場更新快速、須要快速作出反應的軟件領域。

　　敏捷開發方法不僅是工做流程，更是一套完整的管理體系。一個成熟的敏捷團隊能夠擁有很是高的工做效率，但這須要很高的管理水平和技術水平（敏捷開發原則注重開發人員的不斷學習）。所以，當今許多團隊僅僅是吸取敏捷開發方法的一些原理、精華並捨棄一些不適用於自身的原則，造成一套本身的方法來自我管理。

對敏捷軟件開發的產生緣由的我的理解

　　敏捷開發方法出現時間比傳統方法的時間要晚，其背後必然有必定的歷史緣由。我的認爲，這是由於軟件開發環境的不斷進步、軟件市場的競爭不斷激烈何互聯網的發展等因素所形成的

1. 軟件開發環境不斷進步。曾經，人們編寫軟件須要學習許多的程序設計知識和技能才能進行良好的程序設計，而程序設計的難度致使其在複雜度增大後容易產生大量的錯誤，而這致使了傳統軟件工程的產生。在軟件開發環境不斷進步，例如出現了大量的新語言、新開發環境、新軟件開發輔助軟件（例如版本控制軟件）後，軟件開發過程彷佛比之前變得更可控，對開發人員更可見，各式各樣的接口規範代替了必定的文檔的功能。所以，開發人員有了更多的精力、能力去面對變化，每一個人也有了應對不一樣狀況的方法。固然，這須要開發人員的不斷自我進步。
2. 軟件市場競爭不斷激烈。因爲咱們逐漸進入數字時代，使用軟件彷佛已經成了許多人生活中的一部分，這致使了對軟件的需求不斷增長，軟件從業人員增長、軟件市場的競爭愈來愈激烈。同時，人們的需求也在不斷地變化，這使得在一些場景下，傳統開發方法過於緩慢，很容易被敏捷開發方法在市場上擊敗，所以這也形成了敏捷開發方法的流行。軟件市場競爭的激烈產生了許多小的軟件開發團隊，其中許多團隊是精英團隊，以迅速佔領軟件市場。他們的人員組成也使得他們很是適合使用敏捷開發，我認爲這也是敏捷開發流行的一個緣由。
3. 互聯網的發展。一方面，互聯網促進了市場的發展；另外一方面，互聯網也提供大量的軟件開發新環境。互聯網不只使得軟件更容易發佈、分散和流行，更多人能與開發人員交流，提出他們的訴求，也能讓開發人員可以快速地獲得他們想要的開發資源和開發方法，使得軟件更易迭代。所以，在互聯網浪潮下的今天，敏捷開發方法彷佛成了主流。

參考文獻

[1] Report about the NATO Software Engineering Conference dealing with the software crisis

[2] （美）普雷斯曼（Pressman, R. S.），《軟件工程：實踐者的研究方法》

[3] https://en.wikipedia.org/wiki/Waterfall_model

[4] https://en.wikipedia.org/wiki/Spiral_model

[5] https://en.wikipedia.org/wiki/Agile_software_development

[6] https://www.agilealliance.org