以“瀑布模型”為代表的傳統軟體開發模型針對軟體生命週期的各個階段提供了一套規範, 以期使工程的進展達到預期的目的。核心強調在軟體開發活動中, 所有的活動計劃, 日程安排, 交付工作都要直接或間接的和需求保持一致, 同時強調軟體需求必須形成“ 文件” 。這種基於計劃的生命週期的軟體開發方法曾極大地促進了軟體行業的發展，但現如今卻愈感“有心無力”。
為了適應現代的商業環境與之對應的“敏捷程式設計”的開發方法提了出來。包括諸如“極限程式設計”、自適應軟體開發和功能驅動開發等。其他答案已從定義上給予了說明，我就結合敏捷軟體開發宣言從商業環境探究這一開發方法的本質與起源。個體和互動 勝過 過程和工具敏捷開發強調把關注點回歸到“人”上，其背後的哲學思想可追溯到康德的“人即目的”。同時，主張面對面交流和客戶參與開發, 彌補了缺少文件而產生資訊流通不暢問題, 認為開發人員之間、開發人員和客戶之間相互協作、相互信任、彼此尊重是保證溝通成功的必要條件。背後的商業環境現實就是——開發過程中的人力資本的高企。
一個典型的專案花在人力上的金錢是花在硬體上的時間的20 倍, 這意味著一個專案每年要花2 0 萬美元在程式設計師身上, 而僅僅花10 萬美元在電腦裝置上。很多聰明的程式設計師說: “ 我們如此聰明, 發現一種方法可以節省20%的硬體開銷” , 然後他們使得源程式大且難懂和難以維護, 他們會說: “ 但是我們節省了20%或者2 萬美元每年, 很大的節省” 。但財務事實告訴我們，如果程式簡單而且容易擴充套件, 我們將至少節省10%的人力開銷，這將是一筆更大的節省。同時，軟體開發的職業本身也決定了數量少但精幹的團隊的效率與產出大於臃腫、混亂的大團隊。
敏捷開發一般適用於20-40人、甚至更少。可以工作的軟體 勝過 面面俱到的文件區別於傳統的軟體開發模式，客戶只有在系統被開發完成以後才能真正去體會它。敏捷程式設計通過要求不斷交付可用的軟體, 週期越短越好，加強客戶的反饋來縮短開發的週期, 同時獲得足夠的時間來改變功能和獲得使用者的認同。背後的商業環境現實就是——“快魚吃慢魚”的競爭模式。區別於工業社會的利用流水線、規模化的生產模式，資訊時代更強調對使用者需求的快速響應。標準化生產所帶來的低成本、高可靠性的特點不能直接保證市場的高份額。相反，對使用者需求的細膩把握和快速響應卻是以使用者為導向的服務型公司的生命線！客戶合作 勝過 合同談判敏捷開發要求在專案過程中, 業務人員與開發人員必須在一起工作，參與開發，採用高效資訊的互動平臺以及能夠減少歧義溝通和交流的方式進行支援。
敏捷方法完成了從重視文字到重視對話,從重視書寫到重視理解的轉換。背後的商業環境現實就是——使用者無法對其自身需求進行有效描述最經典的例子莫過於蘋果的iPad、iPhone了。在喬布斯沒有推出iPhone之前，使用者是不知道他們需要智慧機，更準確地來說就是無法對智慧機的需求進行有效描述的。這也就是為什麼諸如諾基亞、摩托羅拉等公司失敗的原因之一。他們不是沒有市場部門，不是沒有進行市場調研、使用者需求分析，問題在於一般使用者在缺乏相關知識與指導的情況下是無法對自身需求（特別是潛在需求）進行有效描述。這一缺陷在市場競爭隨著節奏的加快顯得愈發致命！響應變化 勝過 遵循計劃敏捷開發的口號是擁抱變化，即歡迎對需求提出變更，甚至是在專案開發後期。要善於利用需求變更, 幫助客戶獲得競爭優勢。背後的商業環境現實就是——試錯成本低、執行力要求高現代社會最重要的特點就是多元化，用所謂的“網際網路思維”說就是“去中心化”，具體到個人應該就是 Open mind。這一社會現實反應在軟體開發上就是 試錯成本變得相當較低。但與此同時，快速變化的商業大環境也對執行力提出了高要求，而執行力的關鍵指標就是對變化的快速響應！

上面是摘抄來的，簡單的說，相對與傳統的瀑布式開發(Wanterfall)，敏捷開發（Scrum,Agile）更適合現在快節奏商業模式的需求，我們會把完整的一個商業專案切割成相互獨立的小塊，我們稱之為sprint即衝刺，每個sprint包含前期的需求分析，程式設計師的開發測試，和交付的Demo優化，和最後的UAT,過程如下圖

按照這種節奏來生產軟體，其實和前面的持續交付概念差不多，這樣不至於出現很長的開發期跟終端使用者都是隔離的，而最後交付的時候使用者說這完全不是我要的，然後開始惱人的再溝通和返工。