1. 何爲敏捷
敏捷是基於一種不確定性較高，未來環境難以預測的背景下產生的一種管理理念，這種理念並不意味着應該丟棄傳統的管理方法中的一些方法而是應該以快速傳遞價值給客戶爲目標進行管理，只要某個方法能加速我的價值傳遞就應該使用。
敏捷宣言
- 個體和互動高於流程和工具；
- 工作的軟件高於詳細的文檔；
- 客戶合作高於合同談判；
- 響應變化高於遵循計劃。
以上價值觀並不是右邊不重要，而是認爲左邊更重要。
十二原則
客戶爲主：我們的最高目標是，通過儘早和持續地交付有價值的軟件來滿足客戶。
擁抱變化：歡迎對需求提出變更——即使是在項目開發後期。要善於利用需求變更，幫助客戶獲得競爭優勢。
短迭代交付：要不斷交付可用的軟件，週期從幾周到幾個月不等，且越短越好
業務參與：項目過程中，業務人員與開發人員必須在一起工作。
以爲人本：要善於激勵項目人員，給他們以所需要的環境和支持，並相信他們能夠完成任務。
面對面溝通：無論是團隊內還是團隊間，最有效的溝通方法是面對面的交談。
成功導向：可用的軟件是衡量進度的主要指標。
保持節奏：敏捷過程提倡可持續的開發。項目方、開發人員和用戶應該能夠保持恆久穩定的進展速度。
追求卓越：對技術的精益求精以及對設計的不斷完善將提升敏捷性。
簡單務實：要做到簡潔，即盡最大可能減少不必要的工作。這是一門藝術。
團隊自組織：最佳的架構、需求和設計出自於自組織的團隊。
持續改進：團隊要定期反省如何能夠做到更有效，並相應地調整團隊的行爲
2. 敏捷生命週期
預測型——類似傳統的瀑布型
迭代型與增量型
敏捷型
四種生命週期的區別
3. 敏捷團隊
自組織
大量個體基於簡單規則的互相作用，無需中央調控，能夠涌現出整體上的新秩序
組建高績效團隊
主要特點
主要特徵
敏捷教練——僕人式（服務式）領導
特點
職責
敏捷團隊激勵
馬斯洛需求理論
金字塔五層：生理需求、安全需求、愛與歸屬 的需求、自尊需求、自我實現需求。只有低層次滿足了纔會產生高一層級的需要
赫茲伯格雙因素理論
激勵因素：來自工作條件本身，能帶來滿意、成就，例如：重視、成就、個人成長
保健因素：是必須的但是不能給予激勵，缺少它會導致不滿意，例如：地位、工作安全、薪水等
敏捷項目團隊需要保健因素去建立最低水平的團隊績效。同樣，激勵因素決定團隊是否能實現高績效
大衛動機理論
| 主要激勵因素 | 對應類型人的特徵 |
| 成就 | |
| 社交 | |
| 權力 |
4. 敏捷實踐
精益軟件開發（LSD）
精益 7 原則
極限編程（XP）
一種基於頻繁交付週期的軟件開發方法，一種開發哲學，基於以下五大價值觀
Scrum
Scrum流行的原因
三大角色
產品負責人——告訴團隊要做什麼，做功能的先後順序是怎樣的，需求有變動時該如何處理
Scrum Master——引導團隊建立團隊規則，維護團隊和指導團隊外部成員遵守團隊規則，移除團隊障礙
開發團隊——執行衝刺，包括：每日檢視和調整、梳理產品列表、衝刺規劃、檢視和調整產品與過程
三大工件
產品待辦列表：一份涵蓋產品中已知所需每項內容的有序列表，它是產品需求變動的唯一來源
衝刺待辦列表：一組爲當前Sprint選出的產品待辦列表項，同時加上交付產品增量和實現Sprint目標的計劃
產品增量：一個Sprint完成的所有產品待辦列表的總和，以及之前所有Sprint所產生的增量的價值總和
五大會議
產品待辦事項梳理——爲即將到來的衝刺做準備，並對事項進行分解和估算
每日站立會議——檢查衝刺目標的進度，並檢視完成衝刺待辦列表的工作進度趨勢
衝刺評審會議——產品負責人說明待辦項列表的完成和未完成；開發團隊討論衝刺期間做得好的、碰到的問題及解決方法
衝刺回顧會議——Scrum團隊檢視自身並創建下一個Sprint改進計劃的機會
Scrum實施流程
5. 敏捷工具
用戶畫像
PERSONA七要素
P代表基本性(Primary)：指該用戶角色是否基於對真實用戶的情景訪談；
E代表同理性(Empathy)：指用戶角色中包含姓名、照片和產品相關的描述，該用戶角色是否引同理心；
R代表真實性(Realistic)：指對那些每天與顧客打交道的人來說，用戶角色是否看起來像真實人物；
S代表獨特性(Singular)：每個用戶是否是獨特的，彼此很少有相似性；
O代表目標性(Objectives)：該用戶角色是否包含與產品相關的高層次目標，是否包含關鍵詞來描述該目標；
N代表數量性(Number)：用戶角色的數量是否足夠少，以便設計團隊能記住每個用戶角色的姓名，以及其中的一個主要用戶角色；
A代表應用性(Applicable)：設計團隊是否能使用用戶角色作爲一種實用工具進行設計決策
可以用來克服項目成員在產品開發過程中的若干難題
需求分析階段：確定產品功能以及用戶行爲的優先級，輔助場景設計，讓產品更爲聚焦。
產品設計階段：協助與項目成員以及利益相關者進行溝通交流，就設計意見達成共識和承諾。提高設計效率。
用戶調研階段：許多其他的用戶研究環節對於用戶的招募以及研究內容確定都需要依據persona。
產品策略階段：明確市場推廣方向、預估市場規模，更準確地爲產品做決策以及定位市場
用戶故事
三要素
3C原則
交談（Convertsation）：用戶故事背後的細節來源於和客戶或產品負責人的交流溝通
確認（Confirmation）：通過驗收測試用戶的故事被正確完成
六個特性-INVEST
獨立性（Independent）— 要儘可能的讓一個用戶故事獨立於其他的用戶故事。
有價值（Valuable）— 每個故事必須對客戶具有價值（無論是用戶還是購買方）。
可以估算性（Estimable）—開發團隊需要去估計一個用戶故事以便確定優先級，工作量，安排計劃。
短小（Small）— 一個好的故事在工作量上要儘量短小，最好不要超過10個理想人/天的工作量,至少要確保的是在一個迭代或Sprint中能夠完成。
可測試性（Testable）—一個用戶故事要是可以測試的，以便於確認它是可以完成的
確定用戶故事優先級
相對優先級=價值/工作量 估算每個故事的價值和工作量，計算相對優先級。
應該有（Should have）：很重要但是短期內有替代方案的功能，如果沒有時間約束，此類功能是強制性的
可以有（Could have）：沒有時間就可以在發佈中不予考慮的功能
卡諾Kano模型：有時候基礎型需求部分實現就可以了，儘可能多的完成期望型需求，確定少量興奮型需求。
估算——對交付計劃產品所需要的成本、進度、投入或者技能進行的預測
敏捷估算基礎
估算讓團隊可以瞭解項目規格，計算ROI和IRR，形成項目執行許可的基礎。
敏捷團隊基於產品負責人的投入來估算需求，Scrum Master進行保守估算。
敏捷估算在整個項目期間進行。在項目逐步完善中更多信息出現，團隊定期評估新需求。
準確性和精確性
敏捷估算致力於準確性而非精確性，因爲實現精確性讓估算過程拉長並且昂貴
故事點：描述一個用戶故事及其相關努力總體規模的測量單元
- 任務規模-故事規則取決於以下因素：複雜性、投入量、風險大小
- 相對價值-故事點是規模的相對測量，絕對值不是很重要。
- 估算-估算運用基準來完成，相對值被運用。
- 選取最小故事估算價值爲一個故事點。
- 選取中等規模故事分配5個故事點。
故事點估算的步驟
- 用戶故事拆分爲更小的功能，並確保每個故事具有投資屬性。理想情況下，每個故事應該由1個人佔用不超過2天的時間完成。
- 確定團隊達成共識的故事作爲基線，創建它的故事點價值。
- 將所有其他故事卡片同基線故事對比。
- 每次迭代末期，將故事點同故事卡片上記錄的校準。
- 故事點之類比估算故事點估算可以通過對比來有效完成
估算規模敏捷評估旨在合理預測估算，不追求精確
寬帶德爾菲
- 團隊選擇：選擇負責估算的專家團
- 啓動會議：計劃啓動會議去說程序和落地規則
- 個人準備：允許團隊成員針對每個任務個人收集初始估算
- 估算會議：實施一系列迭代步驟組成的估算會議
- 配置任務：收集個人估算，編譯最終清單
- 任務評審：評審估算程序、最終任務清單和假設的結果
- 每個團隊成員收到有編號的卡片，如果需要數字可以延伸；
- 產品負責人朗讀每個故事卡片並回答團隊問題；
- 每個團隊成員評估故事所需投入以及運用相對尺碼給故事分配點；
- 當Scrum Master要求時，每個人必須同時舉起寫有他們估算的數字卡；
- 如果這裏有差異，團隊成員要解釋估算偏高或偏低的原因；
- 討論後，團隊成員重新估算直到達成一致
