敏捷式軟體開發 (Agile Software Development)與傳統軟體工程

標籤：客戶   舉例   反饋   分解   偏差   src   實現   軟體開發   改變   

一、傳統軟體工程

　　“軟體工程”的概念在1968年召開的一個當年被稱作“軟體危機”的會議上首次提出。當時，由於軟體系統的規模越來越大，複雜程度越來越高，使用者需求的不明確，軟體開發出現項目延遲、成本難以控制、產品不可靠難以維護等現象，軟體危機開始爆發。為解決軟體危機，逐漸發展起軟體工程。軟體工程是借鑒工程化解決方案，來分析、設計和編製軟體， 並保證其能按要求運行。

　　最初的軟體開發過程模型起源於更一般的系統工程過程，其典型模型如瀑布模型。在開始工作之前，對所有過程活動制定計劃給出進度安排。其主要階段直接映射基本開發活動：需求分析和定義，系統和軟體設計，實現和單元測試，整合和系統測試，運行和維護。其每個階段的結果是一個或多個文檔，直至上一個階段結束下一個階段才能開始。如果當前階段發現問題，則需返回上一階段進行修改。

　　瀑布模型：

 

 

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

　　隨著 21 世紀的到來，軟體產品需求的普遍性日益增加。使用者需求的多樣性、個人化和不斷變化是這一時期軟體產品的特點。在這種情況下，傳統的軟體工程管理理論越來越不適用，人們開始對軟體開發過程的定位重新進行思考，試圖探索一種新的管理方法。2001年2月在美國猶他州的雪鳥城召開了軟體開發大會，會議的結論就是“敏捷宣言”。這份宣言是敏捷管理方法誕生的標誌。

　　敏捷開發的四個核心觀點為：（1）人與人的互動：優先於過程和工具。在傳統軟體工程當中人在軟體開發過程中的作用相當於可隨時替代的資源，而敏捷開發更強調人本身的作用，沒有任何過程方法能代替Team Dev中成員本身。在此之上，成員之間的交流直接通過面對面的直接互動則強於通過文檔二次交流可能發生的理解偏差。（2）可以工作的軟體：優先於求全責備的文檔。此觀點強調則通過已經完成可以工作的軟體可以更好的給客戶看到已經完成了什麼，文檔再完備也無法完全展示出項目的實際效果。直接面對一個可以工作的軟體客戶可能才知道其真正需要的是什麼，才能及時進行需求的描述更改。其最終交付的產品是軟體，而不是文檔。在一系列階段活動中文檔所起到的作用應是輔助，不能作為真正的衡量標準。（3）客戶協作：優先於合約談判。在軟體開發中客戶和軟體開發人員應成一種互相協作的關係。合約的作用在於使雙方可受法律保護，是必須的基礎。但在此之上，比合約談判更重要的是雙方的相互合作，僅通過書面的文檔，客戶可能無法完備準確地描述其需求，開發人員也可能會對客戶的實際需求有所偏差，並且在開發過程當中客戶也可能會對軟體的需求隨時做出改變，所以敏捷開發強調業務人員和開發人員能在整個項目過程中能始終在一起工作，以快速應變需求的變化及時得到客戶回函。（4）隨時應對變化：優先於循規蹈矩。傳統軟體工程在軟體開發之前進行需求分析，希望在開始時儘可能全面的確定需求，之後就只需根據計劃循規蹈矩完成。但實際上需求本質上是易變的，變化本質上才是常態，敏捷開發強調擁抱變化，可以隨時應對變化，通過頻繁反覆式開發法，不斷交付有部分功能的產品給客戶獲得反饋，不斷調整以響應客戶的需求變更。

　　敏捷管理方法有好多種，其中 XP 方法（極限編程）是其中應用最為廣泛的方法。它是一個輕量級的、靈巧的軟體開發方法；同時它也是一個非常嚴謹和周密的方法。它的基礎和價值觀是交流、樸素、反饋和勇氣。程式員之間緊密的相互交流,程式員也和客戶緊密的交流。設計上保持簡單明了。項目一開始,就強調通過對軟體的不斷測試來獲得反饋,程式員儘可能早的把軟體交給客戶,並實現客戶對軟體需求提出的變化,有了這些基礎,程式員就可以自信的面對需求和軟體技術的變化。XP是一種近螺旋式的開發方法，它將複雜的開發過程分解為一個個相對比較簡單的小周期；通過積極的交流、反饋以及其它一系列的方法，開發人員和客戶可以非常清楚開發進度、變化、待解決的問題和潛在的困難等，並根據實際情況及時地調整開發過程。

 

三、理解比較

　　通過查閱資料對這兩種開發方式進行比較，敏捷式軟體開發 (Agile Software Development)相較於傳統軟體工程的其中一個特點在於其所寫文檔的大量減少，從而減少了工作成本，傳統軟體工程需要進行大量的文檔撰寫，以瀑布模型舉例，每個階段都必須完成規定的文檔，沒有交出合格的文檔就是沒有完成該階段的任務，且前一階段的輸出文檔是後一階段的輸入文檔。只有前一階段的輸出文檔正確,後一階段才能獲得正確的結果。但在開發中一旦本階段出現問題就需要向上返工，文檔也需重新修改編寫交付，很多時候客戶會不斷對需求進行補充更改，甚至可能會到在最後交付時才發現並不是真正需要的，由此導致不僅是軟體本身，更多是文檔的重新編寫，此種情況下文檔編寫成為一種對工作資源的浪費，故敏捷開發強調軟體優於文檔。但敏捷開發也不意味著就不需要文檔，只是簡化掉其中不必要的部分，如果把必須的文檔僅以口頭的方式進行傳遞則會增加項目的風險。第二是敏捷開發更強調對需求的適應性，傳統軟體工程在開始階段就對一個軟體項目定下長期的詳細計劃，儘可能全面的定下軟體的所有需求，之後只需按照已定計划進行開發。然而在軟體的實際開發過程當中，很難做到在開發的初始階段就把所有的需求都定下來，且客戶的需求隨時會變，一旦發生這些情況，就要進行大量的返工工作，所以傳統軟體工程更適於一旦需求定下就不再做更改的項目。而敏捷開發，採用迭代式開發，每次向客戶提交一個可以工作的具有部分功能滿足部分使用者需求的軟體，在此過程中隨時保持與使用者的交流，擷取到使用者的反饋後，再對程式軟體進行調整達到要求後再進行下一功能需求的開發，以此可克服開發過程中的頻繁需求變更，減少設計的錯誤，達到更好的適應性。第三在于敏捷開發也更強調人本身的因素。更關注Team Dev中成員之間的直接面對面交流，開發人員與客戶間的協作。由於客戶的參與，開發人員對於需求的要求不是很嚴格，但通常需要較強的支援人員。而且由於成員之間需要進行頻繁的直接交流，故其項目成員較少，人員的流動會導致對項目的影響較大，大型的項目則不太適宜敏捷開發。但在傳統軟體過程中對於人在其中的作用則是可以被替代的資源，人員的流動則不會對軟體開發構成影響。

　　相較而言，傳統軟體開發更適合於客戶需求基本保持不變，具備固定需求的大型項目；而敏捷開發則適合於需求變化快人員流動小的小型項目。

 

參考資料：

[1]軟體工程 原版：lan sommerville 譯版：程成，陳霞譯，機械工業出版社

[2]敏捷方法與經典軟工的較量 莫映

[3]敏捷管理方法在軟體開發中的應用 李遠

[4]基于敏捷軟體開發的軟體工程教學研究 管林挺，顧沈明

[5]基于敏捷的軟體過程進化 胡君

敏捷式軟體開發 (Agile Software Development)與傳統軟體工程