什麼是敏捷開發？
敏捷開發(Agile Development)是一種以人爲核心、迭代、循序漸進的開發方法。在敏捷開發中，軟件項目在構建初期被切分成多個子項目，各個子項目的成果都經過測試，具備可視、可集成和可運行使用的特徵。（把一個大項目分爲多個相互聯繫，但也可獨立運行的小項目，並分別完成，在此過程中軟件一直處於可使用狀態。）
主要目的：降低需求變化的成本
開發流程：編寫用戶案例，架構規範，實施規劃，迭代計劃，代碼開發，單元測試，驗收測試等等。
原則和方法：迭代式開發。增量交付。開發團隊和用戶反饋推動產品開發。持續集成。團隊自我管理。
核心做法：小規模，頻繁的版本發佈，短迭代週期。測試驅動開發、結對編程、持續集成、每日站立會議、共同擁有代碼、系統隱喻。
精髓：2/8法則（20%交付功能代表80%最終商業價值）；
爲什麼說是以人爲核心？
我們大部分人都學過瀑布開發模型，它是以文檔爲驅動的。在瀑布的整個開發過程中，要寫大量的文檔，把需求文檔寫出來後，開發人員都是根據文檔進行開發的，一切以文檔爲依據；
而敏捷開發它只寫有必要的文檔，或儘量少寫文檔，敏捷開發注重的是人與人之間，面對面的交流，所以它強調以人爲核心。
什麼是迭代？
迭代是指把一個複雜且開發週期很長的開發任務，分解爲很多小週期可完成的任務，這樣的一個週期就是一次迭代的過程；同時每一次迭代都可以生產或開發出一個可以交付的軟件產品。
關於Scrum和XP
敏捷是一種指導思想或開發方式，而Scrum和XP就是敏捷開發的具體方式了，你可以採用Scrum方式也可以採用XP方式
什麼是Scrum？
Scrum是一個敏捷開發框架；由一個開發過程，幾種角色以及一套規範的實施方法組成。
【Scrum開發流程中的四大角色】
產品負責人（Product Owner）
該角色負責產品的遠景規劃，平衡利益相關者的利益。確定不同的產品需求積壓的優先級等。
在開發中，主要負責確定產品的功能和達到要求的標準，指定軟件的發佈日期和交付的內容，同時有權力接受或拒絕開發團隊的工作成果。
他是開發團隊和客戶或最終用戶之間的聯絡點。
利益相關者（Stakeholder）
該角色與產品之間有直接或間接的利益關係，通常是客戶或最終用戶代表。他們負責收集編寫產品需求，審查項目成果等。
流程管理員（Scrum Master）
主要負責整個Scrum流程在項目中的順利實施和進行，以及清除擋在客戶和開發工作之間的溝通障礙，使得客戶可以直接驅動開發。
他也是開發團隊與產品擁有者之間交流的聯絡點。
開發團隊（Scrum Team）
主要負責軟件產品在Scrum規定流程下進行開發工作，每個成員可能負責不同的技術方面，但要求每成員必須要有很強的自我管理能力，同時具有一定的表達能力；成員可以採用任何工作方式，只要能達到Sprint的目標。
Scrum名詞解釋：
backlog：可以預知的所有任務,包括功能性的和非功能性的所有任務。建立Product Backlog 的過程就是將用戶需求轉化爲一個個User Story 並確定其優先級的過程。
story：用講故事的方式來表達需求，這樣便於讓原始客戶比較清晰的對需求進行表達，開發和測試也會逐漸以客戶的需求思維來思考自己的工作。
sprint：一次迭代開發的時間週期，一般最多以30天爲一個週期。在這段時間內，開發團隊需要完成一個制定的backlog，並且最終成果是一個增量的，可交付的產品。
sprint backlog：一個sprint週期內所需要完成的任務
scrum Master：監督整個Scrum進程，修訂計劃
time-box：一個用於開會時間段。每個daily scrum meeting的time-box爲15分鐘。
sprint planning meeting：啓動每個sprint前召開。一般爲8小時。產品Owner和團隊成員將backlog分解成小的功能模塊，決定在即將進行的sprint裏需要完成多少小功能模塊，確定Product Backlog的任務優先級。還需詳細討論如何按需求完成小功能模塊。
Daily Scrum meeting：開發團隊召開，開發人員向ScrumMaster彙報：今天完成了什麼？遇到了什麼障礙？明天做什麼？團隊成員相互瞭解項目進度
Sprint review meeting：每個Sprint結束後，Team將Sprint成果演示給Product Owner和其他人員。並總結結束的Sprint。
Scrum流程圖
如何進行Scrum開發？
1、確定Product Backlog（按優先順序排列的一個產品需求列表），由Product Owner 負責的；
2、Scrum Team做工作量的預估和安排；
3、Product Backlog列表中挑選出一個Story作爲迭代目標，然後Story進行細化。
團隊在Backlog列表中挑選出當前sprint內完成的工作。團隊決定如何將選定的產品Backlog轉化爲潛在可交付產品的功能增量。
形成一個Sprint Backlog（Sprint Backlog是由Scrum Team去完成的）
4、召開sprint planning meeting，確定迭代任務，優先級，並分配給每個成員
5、在Scrum Team完成計劃會議上選出的Sprint Backlog過程中，需要進行 Daily Scrum Meeting，每個人彙報昨天完成了什麼，承諾今天要完成什麼，遇到不能解決的問題。回答完成後，更新 Sprint burn down（Sprint燃盡圖）；
6、做到每日集成，也就是每天都要有一個可以成功編譯、並且可以演示的版本；
7、當一個Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，這時，我們要進行 SrpintReviewMeeting（演示會議），也稱爲評審會議，產品負責人和客戶都要參加（最好本公司老闆也參加），每一個Scrum Team的成員都要向他們演示自己完成的軟件產品（這個會議非常重要，一定不能取消）；
8、最後就是Sprint Retrospective Meeting（回顧會議），也稱爲總結會議，以輪流發言方式進行，每個人都要發言，總結並討論改進的地方，放入下一輪Sprint的產品需求中；
其他資料
利益相關者：敏捷開發保證了項目中所有利益相關者的利益，不論是客戶、項目管理、開發團隊或測試小組。每個人對項目都有清晰的可見性，這是成功的關鍵點所在。敏捷開發原則上鼓勵用戶積極地參與，不論是產品開發，或是團體協同的方方面面。這對關鍵利益相關者提供了非常好的可見性，包括項目的進度或是產品本身，最終這有利於保證產品預期的效果。
質量：不像傳統的瀑布模型，等到開發完成纔開始測試，可是在敏捷開發中，我們隨着需求的準備便開始進行測試。因此，測試集成貫穿整個開發週期，使得工作產品像開發一樣去定期檢查。這允許工作所有者有必要時做出適當調整，以及及早的給產品團隊檢查出任何質量問題。
核心原則
◆主張簡單：簡單模型入手，慢慢迭代
◆擁抱變化：需求時刻在變，Project stakeholder（項目利益相關者）也可能會變化。項目環境不斷變化
◆可持續性：實現項目投資者的需求，其中就包括你的系統應該要有足夠的魯棒性（robust ），能夠適應日後的擴展。可持續性可能指的是系統的下一個主要發佈版，或是你正在構建的系統的運轉和支持
◆遞增的變化：
和建模相關的一個重要概念是你不用在一開始就準備好一切。你不用在模型中包容所有的細節，你只要足夠的細節就夠了，開發一個小的模型，或是概要模型，打下一個基礎，然後慢慢的改進模型。
◆令投資最大化
你的項目投資者爲了開發出滿足自己需要的軟件，需要投入時間、金錢、設備等各種資源。投資者應該可以選取最好的方式投資，也可以要求你的團隊不浪費資源。並且，他們還有最後的發言權，決定要投入多少的資源。
◆快速反饋
從開始採取行動，到獲得行動的反饋，二者之間的時間至關緊要。和其他人一共開發模型，你的想法可以立刻獲得反饋，特別是你的工作採用了共享建模技術的時候。和你的客戶緊密工作，去了解他們的的需求，去分析這些需求，或是去開發滿足他們需求的用戶界面，這樣，你就提供了快速反饋的機會。
◆輕裝前進
你建立一個工件，然後決定要保留它，隨着時間的流逝，這些工件都需要維護。如果你決定保留7個模型，不論何時，一旦有變化發生（新需求的提出，原需求的更新，團隊接受了一種新方法，採納了一項新技術...），你就需要考慮變化對這7個模型產生的影響並採取相應的措施。而如果你想要保留的僅是3個模型，很明顯，你實現同樣的改變要花費的功夫就少多了，你的靈活性就增強了，因爲你是在輕裝前進。每次你要決定保留一個模型時，你就要權衡模型載有的信息對團隊有多大的好處（所以才需要加強團隊之間，團隊和項目投資者之間的溝通）。