敏捷開發的4箇中心思想 如下：

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

翻譯成中文如下：

1. 個體與互動比過程與工具更加有效

2. 能夠滿足使用者的軟體比綜合的文件更加有效

3. 客戶協作比守住合同條款更加重要

4. 響應變化比遵守計劃更加有用

其中按照不同的協作模式又分為:

1. XP(Extreme programming) 極限程式設計

2. Scrum (Cohn, 2009; Schwaber, 2004; Schwaber and Beedle, 2001),

3. Crystal(Cockburn, 2001; Cockburn, 2004),

5. Adaptive Software Development (Highsmith,2000),

6. DSDM (Stapleton, 1997; Stapleton, 2003)

7. Feature Driven Development (Palmer and Felsing, 2002)

其中的中心思想是注重最終的可用交付，注重人的溝通協作，注重滿意度而非文件、工具與過程，但坦率地講，在國內的專案型開發中，需要積極地探索如何堅持這個敏捷的思路與需求變更的慾望控制相結合，實現一個最佳的融合，依照筆者個人近20年的從業經驗來看，還是存在相當的難度。

相比較於經典的RUP與Waterfall模型而言，由於沒有了經典的步驟與過程切割，沒有了需求的採集與分析定稿、設計的定稿以及必要的原型開發與驗證，其實對於團隊的每個成員的要求比起上述的2個經典模型要高出不少，其實要求大部分成員都能夠準確、快速分析需求，並且能夠轉化為具體的程式碼，還要考慮必要的系統完整度與擴充套件性，因此對於成員的單兵能力要求非常高，很多國內的公司對於Agile的理解非常片面，筆者曾經碰到很多公司與小組，其中的普遍誤區是Agile是不需要寫文件的、不需要做計劃的，而忽略了對於團隊的單兵技能要求與溝通方面的要求，很多初級技術人員很多的團隊都使用了Agile的方式來生產軟體，最終的結果想必大家也是知道的。

總結一下Agile的應用場景：需求變化可能性非常大，團隊的單兵實力很強、團隊磨合了一定的時間了，能夠緊密配合工作；

總結一下RUP與Waterfall的應用場景：需求變化可能性比較小，團隊的單兵實力不太強，團隊的磨合時間很短，尚不能緊密配合工作；

那麼大家就有個疑問，如果團隊單兵能力差距比較大，磨合不太好，而需求變化又很大的時候怎麼辦呢？ 這個時候在整體交付上的需求實現上使用交替使用遞迴式分階段列舉實施，而每個階段內的管理還是建議採用經典的Waterfall模型來實現，如此來控制整體的交付質量與使用者的交付滿意度。

附錄：Agile的關鍵工程實踐

翻譯為中文，大體如下：

1.持續遞增的工程計劃
2.基於短小有用的功能集所做的釋出
3.基於目前功能集的簡單設計
4.測試優先驅動開發
5.基於需求驅動的持續重構
6.結對程式設計
7.集體負責體系
8.持續的整合
9.與客戶的持續溝通交付
10.專職的客戶代表參與開發

Scrum的實施步驟：

1. Sprints are fixed length, normally 2–4 weeks. They correspond to the development of a release of the system in XP.
2. The starting point for planning is the product backlog, which is the list of work to be done on the project. During the assessment phase of the sprint, this is reviewed, and priorities and risks are assigned. The customer is closely involved in this process and can introduce new requirements or tasks at the beginning of each sprint.
3. The selection phase involves all of the project team who work with the customer to select the features and functionality to be developed during the sprint.
4. Once these are agreed, the team organizes themselves to develop the software. Short daily meetings involving all team members are held to review progress and if necessary, reprioritize work. During this stage the team is isolated from the customer and the organization, with all communications channelled through the so-called ‘Scrum master’. The role of the Scrum master is to protect the development team from external distractions. The way in which the work is done depends on the problem and the team. Unlike XP, Scrum does not make specific suggestions on how to write requirements, test-first development, etc. However, these XP practices can be used if the team thinks they are appropriate.
5. At the end of the sprint, the work done is reviewed and presented to stakeholders. The next sprint cycle then begins.