淺談敏捷式軟體開發 (Agile Software Development)與傳統軟體工程的對比與敏捷開發產生的原因

標籤：改進   代碼   修改   行高   結構   簡單   分配   好處   完全   

引言

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

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

　　隨著軟體工程的發展以及生產環境的多變，軟體工程逐漸演化出各種各樣的門派以及方法論。這些方法論不關乎對錯，只是在不同的情況下有不同的適用情況，以及不同的Team Dev對不同的方法論有著不同的喜好。而這些適用情況的不同和喜好的不同正是因為這些方法有著不同的特性。

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

敏捷式軟體開發 (Agile Software Development)與傳統軟體工程的對比 傳統軟體工程 產生背景

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

分類及技術特點

• 瀑布模型

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

• 增量過程模型

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

• 演化過程模型

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

• 螺旋模型

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

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

小結

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

敏捷式軟體開發 (Agile Software Development)

　　敏捷式軟體開發 (Agile Software Development)從1990年代開始逐漸引起廣泛關注。2001年，敏捷方法的推崇者在美國猶他州雪鳥滑雪聖地進行了一次聚會，形成了「敏捷聯盟」並發表了《敏捷宣言》，在這個宣言中，最重要的部分即以下幾條：

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

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

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

　　敏捷開發方法最典型的特點即擁抱變化。當使用者的需求模糊、善變時，敏捷開發方法由於其極短的迭代流程和極快的迭代速度，可以很方便地相應使用者的變化。而敏捷開發方法快速迭代的特性，使得其具有更加關注人與人，包括開發人員之間和開發人員－使用者之間的時時交流、反饋。試想以下情境：使用者委託你進行一些改進，而你需要進行完備的討論、設計、編寫文檔、實現與測試，而你的使用者需要等待很久的話，你和使用者之間的交流是不連續的；而在敏捷開發方法中，由於迭代非常迅速，使得你和使用者、你和同事之間的交流是連續的，因此需要更加關注人的參與以及使用者的不斷反饋。在敏捷開發方法中，使用者似乎成為了Team Dev的一份子，也在為軟體的完善而出力。因此，敏捷開發方法非常注重客戶的合作。

　　從上述特性來看，敏捷開發方法並非那麼容易實現。如果敏捷開發方法實現得不好，很容易退化為「隨想隨寫」模式，因此需要很高的人員素質。因此，敏捷開發方法非常注重「人的因素」。敏捷過程中要發掘出開發人員的潛力，開發人員要一直工作在一起，具有非常全面的能力，包括程式的編寫和合作、決策能力。因此，敏捷開發過程也是一種人員的組織方法，要求人員充分信任、組織文化好、開發人員決定能得到充分支援（包括來自客戶的支援）以及精乾的隊伍（因此敏捷開發方法一般適用於小型團隊）。

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

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

對比與使用條件

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

　　而軟體畢竟是軟體，其「軟」的特點使其有別於硬體。軟體易於更改，易於發布，因此也就易於迭代。敏捷開發方法比迭代式開發方法的迭代周期更短，也不許要螺旋式開發方法對風險的完整評估——只需要不斷地迎接變化。通過前文的分析，敏捷開發方法更適用於那些人少但精鍊、高素質的Team Dev，並且適用於那些市場更新快速、需要快速做出反應的軟體領域。

　　敏捷開發方法不只是工作流程，更是一套完整的管理體系。一個成熟的敏捷團隊可以擁有非常高的工作效率，但這需要很高的管理水平和技術水平（敏捷開發原則注重開發人員的不斷學習）。因此，當今許多團隊僅僅是吸收敏捷開發方法的一些原理、精華並捨棄一些不適用於自身的原則，形成一套自己的方法來自我管理。

對敏捷式軟體開發 (Agile Software Development)的產生原因的個人理解

　　敏捷開發方法出現時間比傳統方法的時間要晚，其背後必然有一定的曆史原因。個人認為，這是因為軟體開發環境的不斷進步、軟體市場的競爭不斷激烈何互連網的發展等因素所造成的

1. 軟體開發環境不斷進步。曾經，人們編寫軟體需要學習許多的程式設計知識和技能才能進行良好的程式設計，而程式設計的難度導致其在複雜度增大後容易產生大量的錯誤，而這導致了傳統軟體工程的產生。在軟體開發環境不斷進步，例如出現了大量的新語言、新開發環境、新軟體開發輔助軟體（例如版本控制軟體）後，軟體開發過程似乎比以前變得更可控，對開發人員更可見，各式各樣的介面規範代替了一定的文檔的功能。因此，開發人員有了更多的精力、能力去面對變化，每個人也有了應對不同情況的方法。當然，這需要開發人員的不斷自我進步。
2. 軟體市場競爭不斷激烈。由於我們逐漸進入數字時代，使用軟體似乎已經成了許多人生活中的一部分，這導致了對軟體的需求不斷增加，軟體從業人員增加、軟體市場的競爭越來越激烈。同時，人們的需求也在不斷地變化，這使得在一些情境下，傳統開發方法過於緩慢，很容易被敏捷開發方法在市場上擊敗，因此這也造成了敏捷開發方法的流行。軟體市場競爭的激烈產生了許多小的軟體Team Dev，其中許多團隊是精英團隊，以迅速佔領軟體市場。他們的人員組成也使得他們非常適合使用敏捷開發，我認為這也是敏捷開發流行的一個原因。
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

淺談敏捷式軟體開發 (Agile Software Development)與傳統軟體工程的對比與敏捷開發產生的原因