敏捷宣言
● 個體和互動 高於流程和工具(Individuals and interactions over processes and tools)
● 工作的軟件 高於詳盡的文檔(Working software over comprehensive documentation)
● 客戶合作 高於合同談判(Customer collaboration over contract negotiation)
● 響應變化 高於遵循計劃(Responding to change over following a plan)
12條敏捷原則
1、我們最重要的目標，是通過持續不斷地及早交付有價值的軟件使客戶滿意。
2、歡迎需求變化，即使在開發後期也一樣。善於掌控變化，幫助客戶獲得競爭優勢。
3、經常地交付可工作的軟件，相隔幾星期或幾個月，傾向於採取較短的週期。
4、業務人員和開發人員必須每天在一起工作。
5、激發個體的鬥志，以他們爲核心搭建項目。提供他們所需的環境和支持，相信他們能夠達成目標。
6、在團隊內部，傳遞信息效果最高效的方式是面對面的交談。
7、可工作的軟件是進度的首要度量標準。
8、敏捷過程倡導可持續開發。責任人、開發人員和用戶要能夠共同維持其步調穩定延續。
9、對技術精益求精，對設計不斷完善，將提高敏捷能力。
10、以簡潔爲本，極力減少不必要工作量。
11、最好的架構、需求和設計出自於自組織的團隊。
12、團隊定期地反省如何能提高成效，並由此調整團隊的行爲。
SCRUM
兩個角色
Scrum Master（不是項目經理，沒有分配任務的權力，沒有考覈的權力，沒有下命令的權力）
●幫助團隊剷除一切阻礙，讓團隊可以順利完成衝刺目標
●幫助團隊最大化生產力
●使用技術手段幫助團隊變得更加高效，比如：引入自動化腳本，單元測試，持續集成等敏捷實踐
●協助團隊和PO更好的進行協作
●保證Scrum實踐的正確推行
Product owner（PO）產品的負責人，需求負責人，
●需求決策：哪個需求重要，哪個需求不重要，需求的優先級如何排列，在某次發佈中要發佈哪些需求是他來拍板的
三個文件
●Product backlog產品待辦列表： 排序的列表，包含所有產品需求，PO決定產品待辦列表的內容、可用性和優先級。
●Sprint Backlog待辦事項列表，（相當於WBS），來源於產品待辦列表，更具體
●燃盡圖是反映進度狀態，也可以預測未來趨勢
四個會議
計劃會議（明確目標、細化任務）
●決定完成哪些任務
●如何完成
每日立會（定時、定點、人齊、會短、高效）
●一個簡短的團隊會議，由團隊的所有成員在每天固定的時間和地點進行
●查看項目進展，在會議中作計劃，協調每日活動，還可以報告和討論遇到的障礙
●任務板能夠幫助團隊聚焦於每日活動之上，要在這個時候更新任務板和燃盡圖。
●會議上每個成員需要回答3個問題：
1、你昨天做了什麼？
2、今天計劃做什麼？
3、 是否遇到了障礙，需要其他人的幫助？
評審會（展示驗收）
●小組向產品負責人展示和驗收迭代工作結果。
●產品負責人給出評價和反饋。
●評審會上發現的問題或改進將被累積到產品待開發項，也不會馬上或在下一個迭代中開發，而是由優先級排序決定何時開發。（無需提變更請求）
回顧會議（經驗總結，識別改進）
●回顧團隊在流程、人際關係以及工具方面做得如何。
●團隊識別出哪些做得好，哪些做得不好，並找出潛在的改進事項爲改進制定計劃。
敏捷術語和概念
●敏捷項目範圍不固定，而時間和成本是固定的
●敏捷使用自上而下的估計
●敏捷文檔通常勉強夠用
●敏捷有利於適應，而傳統的管理方法有利於預期
產品路線圖(Product Roadmap) - 提供功能發佈里程碑的高級概述。
項目章程對於敏捷項目和傳統項目都很重要，必須在敏捷項目開始時創建。
帕累託原則：也稱爲80-20規則指出，對於敏捷項目，80％的最有用的功能可以在20％的努力中完成，強烈建議關注“20％”
參與式設計：通過積極讓利益相關者參與設計過程來確保結果符合預期的設計方法。
用戶故事
描述用戶渴望得到的功能。
一個好的用戶故事包括三個要素：
1、角色：誰要使用這個功能。
2、活動：需要完成什麼樣的功能或目標。
3、商業價值：爲什麼需要這個功能，這個功能帶來什麼樣的價值。
通常按照如下的格式來表達：
英文：As a <Role>, I want to <Activity>, so that <Business Value>.
中文：作爲一個<角色>, 我想要<活動>, 以便於<商業價值>
3C：卡片(Card)、對話(Conversation)和確認(Confirmation)。
● 卡片（Card）：用戶故事一般在小卡片上寫着故事的簡短描述，工作量估算等。
● 交談（Conversation）：用戶故事背後的細節來源於和客戶或者產品負責人的交流溝通。
● 確認（Confirmation）：通過驗收測試確認用戶故事被正確完成。
用戶故事的六個特性- INVEST：
- I dependent(獨立的)
- N egotiable(便於溝通的)
- V aluable(有價值的)
- E stimable(可估計的)
- S mall(短小)
- T estable(可測試的)