敏捷開發與傳統軟件工程

 

在網上查了許多資料，也看了國內許多人對敏捷開發的見解，大體寫一下本身的理解。

傳統軟件工程是在OS/360的失敗後逐漸發展造成的。最開始的軟件開發更像是藝術創做，十分依賴程序員我的的技術，軟件的質量也基本靠程序員的責任心保證。但隨着軟件規模愈來愈大，愈來愈複雜，開發週期與成本也愈來愈不受控制，同時軟件的可靠性也很難保證。

爲了解決這些問題，軟件開發行業開始學習工程中的管理方法，爲軟件開發制定了一套規範，管理軟件生存週期的各個階段。好比普遍使用的瀑布模型，核心思想是按工序將問題化簡，將功能的實現與設計分開，便於分工協做，採用結構化的分析與設計方法將邏輯實現與物理實現分開。將軟件生命週期劃分爲制定計劃、需求分析、軟件設計、程序編寫、軟件測試和運行維護等六個基本活動，規定了相互的銜接次序，如同瀑布流水，逐級下落。傳統的軟件工程能夠保證軟件開發過程的可靠與可控，而且可以依靠文檔有效的整合不少人的工做，像操做系統，搜索引擎這些有不少人蔘與的項目，都是在軟件工程的幫助下順利開發的。

然而，傳統的瀑布模型也有她的弊端。多數狀況下客戶並不知道本身真正想要什麼，只是有大體的想法。並且如今的軟件行業，發展太快，無論先前的需求分析作的多麼細，交到客戶手中，總會有各類各樣的問題，極可能最後獲得的產品和客戶的指望相差甚遠，而這時候修改已經十分困難。

因此就有了迭代開發這樣的方法。在迭代式開發方法中，整個開發工做被組織爲一系列的小項目，被稱爲一系列的迭代。每一次迭代都包括了定義、需求分析、設計、實現與測試。採用這種方法，開發工做能夠在需求被完整地肯定以前啓動，並在一次迭代中完成系統的一部分功能或業務邏輯的開發工做。再經過客戶的反饋來細化需求，並開始新一輪的迭代。這樣能夠更早的獲得用戶反饋，修改開發中的誤差，下降風險。

敏捷像是進行了改進的迭代開發方法。同之前的軟件管理方法相比，更加註重人這個因素在軟件開發中的做用。敏捷開發強調面對面的溝通，不論是開發團隊仍是客戶。經過頻繁交付新的軟件版本，以及自組織的團隊，來適應需求的變化並完成項目。

    人和交互 重於過程和工具。

    能夠工做的軟件 重於求全而完備的文檔。

    客戶協做重於 合同談判。

    隨時應對變化 重於循規蹈矩。

敏捷開發相對於傳統軟件工程，下降了文檔的做用，而增強了人在開發過程當中的地位。強調團隊的高度協做，優先完成重要的任務，充分發揮人的主觀能動性。從而相對於傳統的軟件工程，敏捷開發對變化有着更好的適應性，更適合於創新型軟件的開發。但相對的更加依賴於人，團隊若是出了問題，相應的開發進度也會受到影響。

 

實際的工做中，每種開發方法都有其適用的地方。當競爭特別激烈的時候，每每需求變化也很迅速，敏捷開發能夠快速適應環境搶佔市場。但敏捷開發也會遺留一些問題，好比團隊的人員變更，以及凝聚力都會影響軟件的後續生存，傳統軟件工程更擅長於軟件的長期管理，以及質量的控制。傳統軟件開發方法與敏捷開發各有側重，因此，更好的辦法是根據具體的狀況在多種開發方式中進行選擇。

（機器和人的區別大概也是這種狀況，機器一絲不苟定下計劃就幾乎不會出錯，可是對於預料以外的狀況幾乎沒法作出反應，而人腦靈活而富有創造力，但經常會犯錯，也有偷懶的時候。也許這中間能夠找到一個平衡靈活性與正確性的點，軟件工程從此的探索道路，應該也是在靈活性與穩定性之間找到平衡）

 

 

參考：

百度百科《瀑布模型》

百度百科《迭代式開發》

百度百科《敏捷軟件開發》

以及知乎上關於敏捷開發的討論