如同前文所述，可以把敏捷看做一種問題解決方式。下面我們就從敏捷問題解決方式的角度解讀敏捷軟體開發。
軟體開發是問題本身和問題解決能力不確定的一種典型情況。軟體專案起源於人的構想，隨著時間不斷變化。專案團隊對專案的認識隨時間不斷加深，成員能力不斷提公升，工作方式和過程改變導致團隊開發能力不斷變化。
敏捷軟體開發分為3個層次。
產品層1.
問題與問題參與者
問題是產品構想。問題提出者是客戶（業務負責人），問題解決者是特性團隊。
2.
問題分解與檢驗
a)
問題分解
將問題從產品構想分解到業務特性。業務特性是問題提出者客戶可檢驗的單位問題。
b)
問題檢驗
在可工作的軟體中檢驗完成的業務特性。可工作的軟體是客戶檢驗問題完整性的基礎。
3.
迭代迭代的大小從1周到4周不等，這是乙個客戶可接受的頻率（節奏）。
業務特性層
1.
問題與問題參與者
問題是業務特性。問題提出者是特性團隊，問題解決者是特性團隊或負責業務特性的相關人員。
2.
問題分解與檢驗
a)
問題分解
將問題從業務特性分解到單元。單元是特性團隊可檢驗的單位問題。
b)
問題檢驗
在可工作的業務特性中檢驗單元的完成情況。
3.
迭代迭代的大小從小時到天，這是乙個特性團隊可接受的頻率（節奏）。
單元層1.
問題與問題參與者
問題是單元。問題提出者是開發人員，問題解決者是開發人員自身或另乙個開發人員（結對程式設計）。
2.
問題分解與檢驗
a)
問題分解
將問題從單元分解到單元職責。
b)
問題檢驗
在預期的單元測試中檢驗單元職責的完成情況。
3.
迭代迭代的大小從分到小時，這是乙個開發人員可接受的頻率（節奏）。
scrum
scrum和敏捷軟體卡發有很多共同點。而對比敏捷軟體開發，可以看到scrum的敏捷實踐側重於高層，而缺乏低層的敏捷實踐。
極限程式設計xp
xp與敏捷軟體開發的吻合度更高。它是由一系列簡單卻互相依賴的實踐組成，這些實踐結合在一起形成了乙個勝於部分結合的整體。
敏捷軟體開發 敏捷開發原則
編寫單元測試是一種驗證行為，更是一種設計行為。測試時乙個無價的文件。如果你想知道如何呼叫乙個函式或者建立乙個物件，會有乙個測試展示給你看。什麼是設計？不應該認為設計就是一組和 分離的uml圖。一組uml圖也許描繪了設計的一些部分，但是它不是設計。還是要 化 僵化性是指難以對軟體進行改動，即使是簡單的...
敏捷軟體開發
敏捷軟體開發 英語 agile software development 又稱敏捷開發，是一種從1990年代開始逐漸引起廣泛關注的一些新型軟體開發方法，是一種應對快速變化的需求的一種軟體開發能力。它們的具體名稱 理念 過程 術語都不盡相同，相對於 非敏捷 更強調程式設計師團隊與業務專家之間的緊密協作...
敏捷軟體開發
我們知道，傳統的開發模式已經不能不適用於現在情況，原因有很多 需求經常發生變化，軟硬體更新速度很快等，這些原因都使得傳統不管是 瀑布模型 還是 增量 不管是 快速原型 還是 螺旋 模型，這些軟體開發的模型，不在實用了。所以，在2001年，敏捷宣言提出，標誌著敏捷開發模型初步形成。那麼敏捷開發和傳統開...