敏捷開發以使用者的需求進化為核心，採用迭代、循序漸進的方法進行軟體開發。

在敏捷開發中，軟體專案在構建初期被切分成多個子專案，各個子專案的成果都經過測試，具備可視、可整合和可執行使用的特徵。

換言之，就是把一個大專案分為多個相互聯絡，但也可獨立執行的小專案，並分別完成，在此過程中軟體一直處於可使用狀態。

傳統開發有個專有名詞叫“瀑布式開發”，分為5個階段：需求分析---設計---編碼---測試---維護。這種傳統的開發模式是一種老舊的，正在過時的計算機軟體開發方法。最開始的軟體行業普遍採用這種方法，但是這種方法套用自傳統工業生產，不適應計算機軟體開發的具體情況。

瀑布式的主要的問題是它的嚴格分級導致的自由度降低，專案早期即作出承諾導致對後期需求的變化難以調整，代價高昂。瀑布式方法在需求不明並且在專案進行過程中可能變化的情況下基本是不可行的。

在專案剛開始的時候，需求是很難確定的，需求總是隨著時間變化不斷調整，並且在專案初期是無法保證制定的計劃的正確性的。

敏捷開發正是為了解決這個問題。敏捷開發，相比迭代式開發兩者都強調在較短的開發週期提交軟體，但是，敏捷開發的週期可能更短，並且更加強調隊伍中的高度協作，獲取快速的反饋，以便儘早做出調整，從而減少浪費，交付更大的價值。

敏捷開發---重簡單，促使團隊達成高效協作，儘可能減少工作量的藝術至關重要。敏捷開發已成為軟體開發的標準。但真正的業務敏捷性需要的不僅僅是擁有一堆Scrum團隊。還需實現組織管理上的敏捷。

提供簡單有效的團隊協作工具，提取阿里核心管理方法融入到你的組織管理中，包含任務協作、即時溝通、資料管理、目標管理等功能於一體，在融入許多成熟專案管理理念的同時，還不斷創新形成了一套全員參與、全員監督的模式。有效幫助管理人員節省不必要的時間、資源等成本，專案管理看板甘特圖對整個流程多維度控制，更是一種全新的體驗。

多年前，一致是敏捷開發的信徒， 今天自己創業的時候，才發現敏捷其實有很大的硬傷，敏捷裡面有一個很難成立的前提假設，就是搭建專案之初， 團隊理解的架構是正確的。 然而，這幾乎很難。特別是沒有業務積累的情況下，架構也可能是錯誤的。 就像最初希望搭建平房，到專案做到一半的時候， 希望做成摩天大樓。 這個時候，無論怎麼調整無法收拾殘局。敏捷天生傾向:變化很快，日後再說， 而不是深思熟慮的考慮當前的決策，導致一開始就產生架構汙染。

敏捷開發是相對傳統的瀑布式開發而言的。是一種新的開發模式，核心是快速迭代，提交交付速度，加快價值的流動。

要說明白敏捷，先得了解瀑布開發的弊端。

傳統專案的管理有三要素：需求範圍（功能，特性）、成本（資源，預算），進度（時間）。正常的開發流程應該如下圖所示

實際上就是管計劃，我們期待能夠透過嚴格的計劃來按時交付高質量的產品和專案，但是實際情況往往是甲方期待我們造一艘豪華遊輪，實際交付的是一艘小破船。之所以這樣，是因為傳統的瀑布式開發存在兩個假設：

1.專案需求是清晰和明確的；

2.計劃是合理的

然而，這兩個假設在實際專案開發中都是不滿足的。在專案剛開始的時候，需求是很難確定的，需求總是隨著時間變化不斷調整，並且在專案初期是無法保證制定的計劃的正確性的。敏捷開發正是為了解決這個問題。

敏捷就是透過高效的協作，獲取快速的反饋，以便儘早做出調整，從而減少浪費，交付更大的價值。敏捷有很多實施方式，題主說的scrum是其中一種方式，具體方式如下：

我們現在常用的是scrum。scrum的具體實施方式和瀑布開發有很大不同，透過下圖可以清晰看出來：

敏捷是實現價值驅動的管理方法，強調的是透過不斷的迭代去逼近最終的目標，根據實際情況每個迭代可以動態的調整專案目標，始終以交付價值為最終目標。敏捷開發概括起來就是：在特定約束條件下，控制產品遺留隱患對產品交付的產品的使用和維護的影響，關注人員能力的提升，儘可能將產品的價值最大化。敏捷比較符合網際網路公司“小步快跑”的方式，能夠快速的響應市場變化，先解決從0到1的問題，再解決從1到無窮大的問題。因此這些年越來越熱。很多公司都在做敏捷轉型。