在90年代末期，傳統軟體開發的方式因為其繁雜的過程，以及對文件的過於嚴格的要求，造成了很大程度上的效率下降，也就是人們所說的「重型化危機」。因為這一原因，人們開始反思傳統方法的利弊，並對其弊端進行了改進，提出了敏捷方法。
2023年2月，由martin fowler，jim highsmith等17位軟體開發專家起草的敏捷宣言發表，敏捷聯盟成立。敏捷開發作為一種新的方法正式誕生。敏捷宣言中所表述的價值觀分為四個方面：
（1）個體和互動 高於 流程和工具
（2）工作的軟體 高於 詳盡的文件
（3）客戶合作 高於 合同談判
（4）響應變化 高於 遵循計畫
同時敏捷宣言還包括12條原則。這十二條原則是以上四條主要的價值觀在實際工作中的體現。
總體來說，敏捷開發作為一種新的軟體工程方法，與傳統方法相比更加注重人的因素。不再把開發者當作乙個物化的，投入多少時間可以完成相應數量**的**開發機器；而是注重開發者之間的互動以及開發者和使用者之間的互動，同時因為增加了交流和協作使得開發的專案更加靈活和易於修改。
什麼是敏捷開發？
敏捷開發是指以人為核心、迭代、迴圈漸進的開發方法。
敏捷開發不是一種技術，而是一種開發方法，也是一種專案流程，會讓我們按照一定的規定一步一步完成專案，但是在這個專案流程中主要驅動是人，採用迭代式開發。
如何理解？
敏捷開發以人為核心主要在於，瀑布開發模式是以文件為驅動的，在開發過程中書寫大量文件，開發人員根據需求文件進行開發，一切以文件為依據。
而敏捷開發只需要寫必要的文件，注重人與人之間的交流，以人的交流為核心。
關於瀑布式開發：
傳統的瀑布式開發，也就是從需求到設計，從設計到編碼，從編碼到測試，從測試到提交大概這樣的流程，要求每乙個開發階段都要做到最好。特別是前期階段，設計的越完美，提交後的成本損失就越少。
瀑布模型將軟體生命週期劃分為制定計畫、需求分析、軟體設計、程式編寫、軟體測試和執行維護等六個基本活動，並且規定了它們自上而下、相互銜接的固定次序，如同瀑布流水，逐級下落。
在瀑布模型中，軟體開發的各項活動嚴格按照線性方式進行，當前活動接受上一項活動的工作結果，實施完成所需的工作內容。當前活動的工作結果需要進行驗證，如驗證通過，則該結果作為下一項活動的輸入，繼續進行下一項活動，否則返回修改。
瀑布模型優點是嚴格遵循預先計畫的步驟順序進行，一切按部就班比較嚴謹。
關於迭代開發：
迭代式開發則是有很多個很多個瀑布式開發的過程組成，其成果是乙個可執行產品的乙個版本，是最總系統系統產品的乙個子集。通過多次迭代連續增加和精化系統，在每個迭代過程中逐步增加資訊，進行細化。每次迭代多選擇目前對風險影響最大的使用例項進行，以分解和降低風險。
迭代式開發也被稱作迭代增量式開發或迭代進化式開發，是一種與傳統的瀑布式開發相反的軟體開發過程，它彌補了傳統開發方式中的一些弱點，具有更高的成功率和生產率。
在迭代式開發方法中，整個開發工作被組織為一系列的短小的、固定長度（如3周）的小專案，被稱為一系列的迭代。每一次迭代都包括了需求分析、設計、實現與測試。採用這種方法，開發工作可以在需求被完整地確定之前啟動，並在一次迭代中完成系統的一部分功能或業務邏輯的開發工作。再通過客戶的反饋來細化需求，並開始新一輪的迭代。
關於scrum和xp
前面說了敏捷它是一種指導思想或開發方式，但是它沒有明確告訴我們到底採用什麼樣的流程進行開發，而scrum和xp就是敏捷開發的具體方式了，你可以採用scrum方式也可以採用xp方式。
scrum和xp的區別是，scrum偏重於過程，xp則偏重於實踐，但是實際中，兩者是結合一起應用的。
敏捷過程模型的乙個例項：極限程式設計
敏捷過程作為一種開發過程模型，產生了很多不同的可以應用到實際中的程式設計方法。這裡介紹一種應用的比較廣泛的開發方法，極限程式設計，來具體體現一些敏捷開發過程的特點。
極限程式設計過程分為策劃、設計、編碼和測試四個階段。
（1）策劃階段
首先在策劃階段，使用者和開發這進行交流，開發者總結出一系列「使用者故事」，描述軟體某一部分功能。之後客戶對這些功能進行優先順序排序，xp團隊評估每乙個故事的成本。之後客戶和xp團隊共同決定在開發的下乙個版本中將會新增哪些功能。而在版本不斷的迭代的過程中，會進行很多次這樣的策劃過程，每一次客戶都可以根據已有的功能來決定是否要新增一些功能，以及要新增哪些功能。
（2）設計階段
在設計階段，開發人員會根據使用者故事，提出這些使用者故事的實現方案。設計的過程中主要遵循簡潔的原則，也就是盡量使用簡介的表述而不是複雜的表述。而設計的另乙個方面則是重構，重構是一種通過不改變**的外部功能的情況下改變軟體模組的內部結構從而優化軟體系統的功能的過程。這是一種改進**的設計。
在設計的這兩個層面中，我們可以看到在xp開發過程中，設計和開發是同步進行的。我們在不斷實現開始設計的過程中，同時要對到嗎進行優化也就是重新設計。這樣，大大的增強了整個軟體開發的適應性，而不是始終刻板的實現最開始的第一版設計。
（3）編碼階段
xp開發的第一件任務不是直接對初步的設計和使用者故事進行編碼，而是針對這些設計全力開發單元測試。完成了單元測試也就確定了開發者要實現的所有功能。這樣開發者就只需要全力通過單元測試，而不必在實現什麼功能上再浪費不必要的時間和精力。這正體現了敏捷開發的以測試驅動的特點。
而在敏捷開發中，很重要的乙個提高效率的方式就是結對程式設計。在結對程式設計的過程中，兩個開發者共用一台電腦，並各有分工。其中乙個人進行實際的編碼實現，另乙個人在旁邊考慮**在巨集觀上該如何實現，比如針對什麼功能應該使用什麼樣的演算法。這樣，在編碼者工作遇到問題時，兩個人交換位置。這時在旁邊思考的人更有可能可以解決這一問題。事實上，結對程式設計的形式不必拘泥於什麼規矩。關鍵在於，兩個人共同開發的過程中，兩個人的交流可以使得大部分的問題可以在第一時間解決。並且，因為兩個人中只有乙個人在進行程式設計這一項比較疲憊的工作，另乙個人較為輕鬆，這樣可以保證開發效率一直保持在乙個比較高的狀態。
（4）測試階段
每乙個模組都通過自己的單元測試之後，開發者會將所有的模組整合到一起進行測試。這樣可以及時發現每一模組在最近一次改動之中出現的問題同時避免一些相容性問題。每一次改動一點小問題要比等到最後一次集中修改所有問題要容易得多。
敏捷開發與傳統開發方法的比較
優勢：
敏捷開發高適應性，以人為本的特性、輕量級的開發方式、及測試為驅動代替以文件為驅動，使得專案流程更加靈活、易於修改，並且更加充分的利用了每個開發者的優勢，調動了每個人的工作熱情。
劣勢：
與傳統開發相比，敏捷開發的最主要的劣勢在於敏捷開發歡迎新的需求，而在每次新的需求產生時都可能引起整個系統的大幅度的修改。因為開發者在開發上乙個版本的時候，完全沒有考慮以後的優化將要如何進行。這樣的開發方式實際的軟體開發過程中，並不一定總是有效的。
而另乙個方面，敏捷開發因為缺乏很多在敏捷開發中被認為「不重要」的文件，這樣在乙個大型專案比如乙個作業系統開發的時候，由於其專案週期很長，所以很難保證開發的人員不更換，而沒有文件就會造成在交接的過程中出現很大的困難。
敏捷開發之Scrum掃盲篇
現在敏捷開發是越來越火了，人人都在談敏捷，人人都在學習scrum和xp.為了不落後他人，於是我也開始學習scrum，今天主要是對我最近閱讀的相關資料，根據自己的理解，用自己的話來講述scrum中的各個環節，主要目的有兩個，乙個是進行知識的總結，另外乙個是覺得網上很多學習資料的講述方式讓初學者不太容易...
敏捷開發之Scrum掃盲篇
敏捷開發有如下特徵 1.工作在小的團隊中 2.團隊是跨功能的 包括測試人員，開發人員，文件開發人員等等 3.短迭代 利用短迭代方法來交付軟體 4.相較於文件，敏捷開發更注重面對面的交流 5.敏捷不是乙個過程，而是乙個軟體開發的形式或者方法 6.敏捷可以與軟體過程如cmmi等一起實施 現在敏捷開發是越...
敏捷開發之Scrum掃盲篇
敏捷開發之scrum掃盲篇 現在敏捷開發是越來越火了，人人都在談敏捷，人人都在學習scrum和xp.為了不落後他人，於是我也開始學習scrum，今天主要是對我最近閱讀的相關資料，根據自己的理解，用自己的話來講述scrum中的各個環節，主要目的有兩個，乙個是進行知識的總結，另外乙個是覺得網上很多學習資...