增量模型的提出，需要有一整套相應的專案管理理念與之匹配，人們通過多年的努力，從理論上和實踐上作了艱苦的探索，提出了比較完整的敏捷專案管理方法。需要說明的是，敏捷開發並不是回歸到當初混亂無計畫開發狀態，更不是贊成隨意性。敏捷方法是在長期的實踐中，對瀑布式模型存在問題的分析結果，也是從發現問題、分析問題到解決方案的過程。對管理水平上的要求是更高而不是更低。
一、敏捷開發的價值觀
實際上敏捷開發運動在數年前就開始了，但它正式開始的標誌是 2001 年 2 月的「敏捷宣言」（agile manifesto），這項宣言是由 17 位當時稱之為「輕量級方法學家」所編寫簽署的，他們的價值觀是：
個人與互動重於開發過程與工具的原因：
乙個由優秀的人員組成但使用普通的工具，要比使用優秀的工具但由普通人組成、紊亂的小組做得更好。多年來人們花了很多時間試圖建立一種過程，以便把人當作機器上的乙個可以替代
的齒輪，但結果卻並不成功。敏捷過程是承認每個人都有特定的能力（以及缺點），並對之加以利用，而不是把所有的人當成一樣來看待。更重要的是，在這樣的理念下，幾個專案做下來，每個人的能力都從中得以提高。
2. 可用的軟體重於複雜的文件的原因：
可用的軟體可以幫助開發人員在每次迭代結束的時候，獲得乙個穩定的、逐漸增強的版本。從而允許專案盡早開始，並且更為頻繁的收集對產品和開發過程的反饋。隨著每次迭代完成軟體
的增長，以保證開發小組始終是處理最有價值的功能，而且這些功能可以滿足使用者的期待。
3. 尋求客戶的合作重於對合同的談判的原因：
敏捷開發小組希望與專案有關的所有團體都在朝共同方向努力，合同談判有時會在一開始就使小組和客戶出於爭執中。敏捷開發追求的是要麼大家一起贏，要麼大家一起輸。換句話說，就
是希望開發小組和客戶在面對專案的時候，以一種合作的態度共同向目標前進。當然，合同是必需的，但是如何起草條款，往往影響到不同的團體是進行合作式的還是對抗式的努力。
4. 對變化的響應重於始終遵循固定的計畫的原因：
敏捷開發認為對變化進行響應的價值重於始終遵循固定的計畫。他們最終的焦點是向使用者交付盡可能多的價值。除了最簡單的專案以外，使用者不可能知道他們所需要的所有功能的每個細節。不可避免地在過程中會產生新的想法，也許今天看起來是必需的功能，明天就會覺得不那麼重要了。隨著小組獲得更多的知識和經驗，他們的進展速度會比開始的時候期望值慢或者快。對敏捷開發來說，乙個計畫是從某個角度對未來的看法，而具有多個不同的角度看問題是有可能的。
二、專案的敏捷開發方法
敏捷方法很多，包括 scrum、極限程式設計、功能驅動開發以及統一過程等多種法，這些方法本質實際上是一樣的，敏捷開發小組主要的工作方式可以歸納為：
1. 敏捷小組的角色
儘管強調乙個整體，小組中應該有一定的角色分配，各種敏捷開發方法角色的起名方案可能不同，但願則基本上是一樣的。
第乙個角色是產品所有者，他的主要職責包括：
確認小組成員都在追求乙個共同的目標前景；
確定功能的優先等級，以便總是處理最有價值的功能；
作出可以使專案的投入產生良好回報的決定。
產品所有者通常是公司的市場部門或者產品管理部門的人員，在開發內部使用的軟體的時候，產品所有者可能是使用者、使用者的上級、分析師，也可能是為專案提供資金的人。
第二個角色是客戶：
客戶是做出決定為專案提供資金或者購買軟體的人，在乙個開發內部使用的軟體專案中，客戶通常是來自另乙個團組或者部門的代表，在這樣的專案中，產品所有者和客戶的角色往往是重合的。對乙個商業軟體來說，客戶就是購買這個軟體的人。客戶可能是也可能不是軟體的使用者（user），使用者當然也是乙個主要角色。
乙個值得注意的角色是開發人員（developer）：
所有開發軟體的人，包括程式設計師、測試人員、資料庫工程師、可用性專家、技術文件編寫者、架構師、設計師、分析師，等等。
最後乙個角色是專案經理：
在所有的敏捷開發專案中，專案經理的角色發生了變化，他更注重的是教導、引導而不是管理和控制。在 scrum 中，為了強調責任的變化，改稱之為 scrummaster。在某些敏捷開發專案中，專案經理也承擔其它的角色，通常是開發人員，少數的時候也會擔任產品所有者。
2. 敏捷小組按短迭代週期工作
在敏捷專案中，總體上並沒有什麼上游階段、下游階段，你可以根據需要定義開發過程。在初始階段可以有乙個簡短的分析、建模、設計，但只要專案真正開始，每次迭代都會做同樣的工
作（分析、設計、編碼、測試。等等）。
迭代是受時間框限制的，也就是說即使放棄一些功能，也必須結束迭代。時間框一般很短，大部分是 2～4 周，在 scrum 中採用的是 30 個日曆天，也就是 4 周。
迭代的時間長度一般是固定的，但也有報告說，有的小組在迭代開始的時候選擇合適的時間長度。
3. 敏捷小組每次迭代交付一些成果
比選擇特定迭代長度更重要的，是開發小組在一次迭代中要把乙個以上的不太精確的需求宣告，經過分析、設計、編碼、測試，變成可交付的軟體（稱之為功能增量）。當然並不需要把每次迭代的結果交付給使用者，但目標是可以交付，這就意味著每次迭代都會增加一些小功能，但增加的每個功能都要達到發布質量。每次迭代結束的時候讓產品達到可交付狀態十分重要，但這並不意味著要完成發布的全部工作，因為迭代的結果並不是真正發布產品。
假定乙個小組需要在發布產品之前對軟硬體進行為期兩個月的「平均無故障時間」（mtbf）測試，他們不可能縮短這兩個月的時間，但這個小組仍然是按照 4 周迭代，除了 mtbf 測試，其它都達到了發布狀態。
4. 敏捷小組關注業務優先順序
敏捷開發小組從兩個方面顯示出他們對業務優先順序的關注。
首先，他們按照產品所有者制定的順序交付功能，而產品所有者一般會按照組織在專案上的投資回報最大化的方式來確定優先順序，並且把它組織到產品發布中去。要達到這個目的，需要綜合考慮開發小組的能力，以及所需功能的優先順序來建立發布計畫。在編寫功能的時候，需要使工能的依賴性最小化。如果開發乙個功能必須依賴其它 3 個功能，那產品所有者這就很難確定功能
優先順序。功能完全沒有依賴是不太可能的，但把功能依賴性控制在最低程度還是相當可行的。
5. 敏捷小組檢查與調整
任何專案開始的時候所建立的計畫，僅僅是乙個當前的猜測。有很多事情可以讓這樣的計畫失效：專案成員的增減，某種技術比預期的更好或更差，使用者改變了想法，競爭者迫使我們做出不同的反應，等等。對此，敏捷小組不是害怕這種變化，而是把這種變化看成使最終軟體更好地反映實際需要的乙個機會。
每次新迭代開始，敏捷小組都會結合上一次迭代中獲得新知識做出相應調整。如果認為一些因素可能會影響計畫的準確性，也可能更改計畫。比如發現某項工作比預計的更耗費時間，可能就會調整進展速度。也許，使用者看到交付的產品後改變了想法，這就產生反饋，比如他發現他更希望有另一項功能，或者某個功能並不像先前看得那麼重。通過先期發布增加更多的使用者希望的功能，或者減少某些低價值功能，就可以增加產品的價值。
迭代開發是在變與不變中尋求平衡，在迭代開始的時候尋求變，而在迭代開發期間不能改變，以期集中精力完成已經確定的工作。由於一次迭代的時間並不長，所以就使穩定性和易變性得到很好的平衡。在兩次迭代期間改變優先順序甚至功能本身，對於專案投資最大化是有益處的。
軟體開發過程
1.程式設計師寫出自認為沒有bug的 2.軟體測試，發現了20個bug。3.程式設計師修改了10個bug，並告訴測試組另外10個不是bug。4.測試組發現其中5個改動根本無法工作，同時又發現了15個新bug。5.重複3次步驟3和步驟4。6.鑑於市場方面的壓力，為了配合當初制定的過分樂觀的發布時間表，...
軟體開發過程
1.程式設計師寫出自認為沒有bug的 2.軟體測試，發現了20個bug。3.程式設計師修改了10個bug，並告訴測試組另外10個不是bug。4.測試組發現其中5個改動根本無法工作，同時又發現了15個新bug。5.重複3次步驟3和步驟4。6.鑑於市場方面的壓力，為了配合當初制定的過分樂觀的發布時間表，...
軟體開發過程
軟體生命週期 1 問題定義 使用者需要解決什麼問題?2 可行性分析 使用者需要解決的問題是否可行 技術可行性 市場可行性 3 需求分析 將使用者提出的問題進行細化 4 系統設計 確定細化問題的實現方法 5 編碼 依據需求和設計穩定進行開發，解決問題 6 測試 驗證是否已經解決使用者提出的問題 單元測...