一. 定義
敏捷開發以使用者的需求進化為核心，採用迭代、循序漸進的方法進行軟體開發。在敏捷開發中，軟體專案在構建初期被切分成多個子專案，各個子專案的成果都經過測試，具備可視、可整合和可執行使用的特徵。換言之，就是把一個大專案分為多個相互聯絡，但也可獨立執行的小專案，並分別完成，在此過程中軟體一直處於可使用狀態
二. 原則
敏捷建模(AM)定義了一系列的核心原則和輔助原則，它們為軟體開發專案中的建模實踐奠定了基石。其中一些原則是從XP中借鑑而來，在Extreme Programming Explained中有它們的詳細描述。而XP中的一些原則又是源於眾所周知的軟體工程學。複用的思想隨處可見!基本上，本文中對這些原則的闡述主要側重於它們是如何影響著建模工作;這樣，對於這些借鑑於XP的原則，我們可以從另一個角度來看待。
三. 特點
（1）個體與互動勝過過程與工具

（2）可以工作的軟體勝過面面俱到的文擋

（3）客戶協作勝過合同談判

（4）響應變化勝過遵循計劃
四.適用場景
敏捷開發（scrum）適用於競爭激烈，快速變化的市場。 敏捷的客戶協作觀念，快速迭代能幫助團隊以最小成本，最快速度滿足客戶真正的需求。對比傳統開發模式：

傳統開發模式以文件為驅動，而敏捷開發提倡少寫文件

傳統開發模式下開發人員按照產品文件進行研發，過程中客戶不參與到產品的驗收和體驗中，這樣就會導致最後開發出來的成品並不是客戶想要的。 而敏捷開發模式從開始就強調客戶協作，分步提供產品模組客戶體驗。

敏捷模式採取迭代式開發，傳統模式採用瀑布式開發

敏捷開發採取迭代式開發的形式，即每個階段有每個階段需要完成、並且能使用的產品，這一階段只要開發某幾個功能，且這些功能的產品必須是可以使用的，這一階段產品完成之後與客戶進行對接交付，再進行下一階段的開發。

敏捷開發更適應變化

傳統開發模式下軟體開發過程是執行研發計劃，而實際工作中，需求往往在開發過程中會產生巨大變化。敏捷開發更能適應不確定性強的產品和市場。
五.Scrum開發流程中的三大角色

（1）產品負責人（Product Owner）

主要負責確定產品的功能和達到要求的標準，指定軟體的釋出日期和交付的內容，同時有權力接受或拒絕開發團隊的工作成果。

（2）流程管理員（Scrum Master）

主要負責整個Scrum流程在專案中的順利實施和進行，以及清除擋在客戶和開發工作之間的溝通障礙，使得客戶可以直接驅動開發。

（3）開發團隊（Scrum Team）

主要負責軟體產品在Scrum規定流程下進行開發工作，人數控制在5~10人左右，每個成員可能負責不同的技術方面，但要求每成員必須要有很強的自我管理能力，同時具有一定的表達能力；成員可以採用任何工作方式，只要能達到Sprint的目標。
六 .何進行Scrum開發？

1、我們首先需要確定一個Product Backlog（按優先順序排列的一個產品需求列表），這個是由Product Owner 負責的；

2、Scrum Team根據Product Backlog列表，做工作量的預估和安排；

3、有了Product Backlog列表，我們需要通過 Sprint Planning Meeting（Sprint計劃會議） 來從中挑選出一個Story作為本次迭代完成的目標，這個目標的時間週期是1~4個星期，然後把這個Story進行細化，形成一個Sprint Backlog；

4、Sprint Backlog是由Scrum Team去完成的，每個成員根據Sprint Backlog再細化成更小的任務（細到每個任務的工作量在2天內能完成）；

5、在Scrum Team完成計劃會議上選出的Sprint Backlog過程中，需要進行 Daily Scrum Meeting（每日站立會議），每次會議控制在15分鐘左右，每個人都必須發言，並且要向所有成員當面彙報你昨天完成了什麼，並且向所有成員承諾你今天要完成什麼，同時遇到不能解決的問題也可以提出，每個人回答完成後，要走到黑板前更新自己的 Sprint burn down（Sprint燃盡圖）；

6、做到每日整合，也就是每天都要有一個可以成功編譯、並且可以演示的版本；很多人可能還沒有用過自動化的每日整合，其實TFS就有這個功能，它可以支援每次有成員進行簽入操作的時候，在伺服器上自動獲取最新版本，然後在伺服器中編譯，如果通過則馬上再執行單元測試程式碼，如果也全部通過，則將該版本釋出，這時一次正式的簽入操作才儲存到TFS中，中間有任何失敗，都會用郵件通知專案管理人員；

7、當一個Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，這時，我們要進行 Srpint Review Meeting（演示會議），也稱為評審會議，產品負責人和客戶都要參加（最好本公司老闆也參加），每一個Scrum Team的成員都要向他們演示自己完成的軟體產品（這個會議非常重要，一定不能取消）；

8、最後就是 Sprint Retrospective Meeting（回顧會議），也稱為總結會議，以輪流發言方式進行，每個人都要發言，總結並討論改進的地方，放入下一輪Sprint的產品需求中；