敏捷較傳統模式更符合軟件開發規律
個體和互動勝過過程和工具
可以工作的軟體勝過面面俱到的檔案
客戶合作勝過合同談判
響應變化勝過遵循計劃
客戶滿意，擁抱變化，短迭代交付，業務參與，以人爲本，面對面溝通
結果導向，保持節奏，追求卓越，簡單務實，團隊自組織，持續改進
敏捷=理念+優秀實踐+具體應用
理念（敏捷核心思想）
優秀實踐（敏捷的經驗積累）
具體應用（能夠結合自身靈活應用纔是真正的敏捷）
聚焦客戶價值
標識和消除軟件開發中的浪費（浪費：部分完成的工作 未應用特性 過度作業 傳遞 工作切換 等待 缺陷）
交付剛剛好的系統
隨時構建品質，不容忍缺陷（缺陷遺留會帶來高額成本）
及時消除技術債務，持續保持快速響應（技術債務：日趨不穩定的架構，圈複雜度搞的程式碼，低的測試自動化率，不及時清楚地靜態檢查告警等）
（精益七大浪費：缺陷，過度生產，運輸，等待，庫存，移動，過度作業）
深入理解「激發團隊」
認清團隊的基本事實
敏捷方式下管理者的轉變（控制--->激發）
敏捷方式下團隊成員的轉變
深入理解「適應變化」
認清「客戶是逐步發現真正需求」
小批次是快速交付的關鍵（縮短交付週期，提高品質，促進創新，降低管理成本，更高的效率等等，答覆提高商業價值）
通過迭代計劃不斷調整以適應需求變化
應保持良好的軟體架構（良好軟體架構是適應變化的基石，軟體架構需要儘早驗證和持續維護）
利用多層次反饋不斷調整以逼近目標
（對客戶需求的反饋，對團隊運作的反饋，對系統功能的反饋，對單元功能的反饋，對程式碼品質的反饋）
（利用多層次反饋手段，在變化的環境中讓團隊準確的瞭解與目標的差距，不斷調整自身行爲，並逐步逼近靶心）
團隊：
敏捷團隊角色： Product Owner（PO） Scrum Master Team
完整團隊實踐
工作件：
產品Backlog（需求清單）
迭代Backlog
完成標準
管理實踐
迭代計劃會議
每日站立回憶
視覺化管理
迭代驗收
迭代回顧會議
技術實踐
使用者故事
結對程式設計
TDD（測試驅動開發）
持續整合
Anatomy系統解剖
敏捷軟件開發是以短週期迭代爲核心，包含團隊，工作件，管理和技術優秀實踐的集合
角色定義：確保Team做正確的事
角色職責：
代表利益相關人（如使用者，Marketing，用服，管理者等），對產品投資回報負責
確定產品發佈計劃
定義產品需求並確定優先順序
驗收迭代結果，並根據驗收結果和需求變化重新整理需求清單和優先順序
角色定義：確保Team正確地做事
角色職責：
輔導團隊正確應用敏捷實踐
引導團隊簡歷並遵守規則
保護團隊不受打擾
推動解決團隊遇到的障礙
激勵團隊
角色定義：負責產品需求實現
角色職責：
負責估計工作量並根據自身能力找出最佳方案去完成任務且保證交付品質
向PO和利益相關人演示工作成果（可執行的軟體）
團隊自我管理，持續改進
敏捷開發中，以Story爲單位的持續交付要求系統組，開發和測試等跨功能團隊進行密切協同，相互獨立的功能軟對難以應對。
完整團隊是跨功能領域（是需求分析師，設計師，開發人員，測試人員，資料人員等）的人員組成一個團隊，做在一起工作，團隊成員遵循同一份計劃，服從同一個專案經理
成員來自多功能領域：團隊擁有完成目標所需的各職能人員
坐在一起辦公：團隊成員無障礙地溝通
團隊保持相對穩定：臨時組建的團隊生產效率較低，團隊穩定非常關鍵
有助於團隊成員形成共同目標和全域性意識，促進個功能領域的拉通和融合
通過面對面溝通提升溝通效率
實現團隊成員的高度協同，支撐高密度地，持續地，短週期的交付
聚焦客戶需求交付，提高共同作業效率
將整個軟體生命週期分成多個小的迭代，每一次迭代都由需求分析，設計，實現和測試在內的多個活動組成，每一次迭代都可以生成一個穩定和被驗證過的軟體版本
每一次迭代都建立在穩定的品質基礎上，並作爲下一輪迭代的基線，整個系統的功能隨着迭代穩定地增長和不斷完善
每次迭代要邀請使用者代表（外部或內部）驗收，提供需求是否滿足的反饋
迭代推薦採用固定的週期（2~4周），迭代內工作不能完成，應當縮減交付範圍而不是延長週期
通過將高技術風險的需求在早期迭代裏實現，有助於儘早暴露問題和及時消除風險
通過提供功能漸增的產品，持續從客戶獲得反饋，根據反饋及時調整，使最終產品更加符合客戶的需要
通過小批次減少排隊，提供更靈活，快速的交付能力
平滑人力資源的使用，避免出現瓶頸
迭代開發是有節奏的小步快跑，但建立在堅實的品質基礎上
經過優先順序排序的動態重新整理的產品需求清單，用來指定發佈計劃和迭代計劃
清楚表述列表中每個需求任務對使用者帶來的價值，作爲優先順序排序的重要參考
動態的需求管理，而非「凍結」方式
迭代的需求分析過程，而非一次性分析清楚所有需求（只對近期迭代要做到需求進行詳細分析，其他需求停留在粗粒度）
通過需求的動態管理應對變化，避免浪費
易於有限交付對使用者價值高的需求
迭代backlog是團隊在一輪迭代中的「任務」（Task）清單，是團隊的詳細迭代開發計劃
當團隊接收從產品Backlog挑選出要在本輪迭代實現的需求時，召開團隊迭代計劃會議，將需求轉化爲具體的「任務」
每項任務資訊包括當前剩餘工作量和責任人
「任務」由團隊成員自己分解和定義，而不是上級指派，支撐需求完成的所有工作都可以列爲任務
任務要落實到具體的責任人
任務力度要小，工作量大於兩天的任務要進一步分解
用小時作爲任務剩餘工作量的估計單位，並每日重新估計和重新整理
講需求分解成更細小的任務，利於對迭代內進度進行精確控制
剩餘工作量可用來跟蹤實踐團隊當前進展
基於「隨時可以向使用者發佈」的目標制定衡量團隊工作是否已完成的標準，由團隊和PO形成共識
團隊自協商：團隊根據專案實際情況來定義完成標準，並嚴格遵守
有層次：一般分爲三個層次：Story級別，迭代級和發佈級，每個級別都有各自的完成標準
共同協商的完成標準是團隊的自我承諾，團隊會更認真
用於評估團隊工作進展
清晰和明確的完成標準保證了每次迭代是高品質的
每輪迭代啓動前，團隊共同討論本輪迭代詳細開發計劃的過程，輸入是產品Backlog，輸出是團隊迭代Backlog
多團隊迭代計劃會議要分層召開
版本迭代計劃會議：將產品Backlog（需求）分配給團隊
團隊迭代計劃會議：將選取的產品Backlog（需求）轉換成迭代Backlog（任務），分配給團隊成員
澄清需求，對「完成標準」達成一致
工作量估計，根據團隊能力確定本輪迭代交付內容
細化，分配迭代任務和初始工作計劃
通過充分討論，使團隊成員對任務和完成標準理解一致
團隊共同參與，促進團隊成員更認真對待自己的承諾
充分參與：Scrum Master要確保PO和Team充分參與討論，達成李姐一直
相互承諾：Team承諾完成迭代Backlog中的需求並達到「完成標準」，PO承諾在短迭代週期不增加需求（2-4周）
確定內部任務：Team和PO協商把一些內部任務放入迭代中（例如重構，持續整合環境搭建等），由PO考慮並與其他外部需求一起排序
迭代計劃會議是由團隊共同確定迭代交付內容和完成標準
每日工作前，團隊成員的例行溝通機制 機製，由Scrum Master組織，Team成員全員站立參加
我昨天爲本專案做了什麼？
我計劃今天爲本專案做什麼？
我需要什麼幫助以更高效的工作？
準時開始
高效會議（限時15分鐘，保持站立，依次發言，不討論無關的事情）
問題跟蹤（Scrum Master應該記錄下所有的問題並跟蹤解決）
增加團隊凝聚力
及時暴露風險和問題
促進團隊內成員的溝通和協調
將專案狀態（進度，品質等）通過物理試題（如白板，大螢幕）實時展示，讓團隊所有成員直觀地獲取當前專案進展資訊
物理實體（白板/大螢幕，在公開場所能看到）（電腦檔案不是視覺化的）
內容精簡 易懂
實時重新整理
簡單，一目瞭然，降低管理成本
實時狀態顯示，及時暴露問題
資訊同源使得團隊理解一致，提升團隊凝聚力
激勵先進，鞭策後進，增強團隊凝聚力
每次迭代開發結束時舉行，通過演示可工作的軟體，檢查需求是否滿足客戶要求
由Scrum Master組織，PO和使用者代表（外部或內部利益相關人）負責驗收，Team負責演示可工作軟體
展示「真實」的產品：Team應在真實環境中展示可執行的軟體，判斷是否達到「完成」標準
蒐集 搜集反饋：PO根據驗收情況及客戶反饋意見，及時調整產品Backlog
通過演示可工作的軟體來確認專案的進度，具有真實性
能儘早的獲得使用者對產品的反饋，使產品更加貼近客戶需求
儘早演示可工作的軟體，收集反饋意見
在每輪迭代結束後舉行的會議，目的是分享好的經驗和發現改進點，促進團隊不斷進步
本次迭代有哪些做得好
每次迭代在哪些方面還能做的更好
下次迭代準備在哪些方面改進
會議氣氛：Team全員參加，氣氛狂送自由，暢所欲言，頭腦風暴，共同分析
關注重點：Team共同討論優先順序，將精力放在最需要的地方
會議結論要跟蹤閉環：可以放在迭代backlog中
激勵團隊成員
幫助團隊挖掘優秀經驗並繼承
避免團隊犯重複的錯誤
贏在團隊自主改進的氛圍
迭代回顧會議是促進團隊持續改進的最有效手段
使用者故事是站在使用者角度描述需求的一種方式
每個使用者故事须有對應的驗收測試用例
使用者故事是分層分級的，在使用過程中逐步分解細化
典型的描述句式爲：作爲一個XXX客戶角色，我需要XXX功能，帶來XXX好處
I --可獨立交付給使用者
N -- 便於與客戶交流
V -- 對客戶有價值
E -- 能估計出工作量
S -- 分解到最底層的使用者故事力度儘量小，至少在一個迭代中能完成
T -- 可測試
使用者故事是站在使用者視角便於與客戶交流，準確描述客戶需求
使用者故事可獨立交付單元，規模小，適於迭代開發以獲得使用者快速反饋
使用者故事強調編寫驗收測試用例作爲驗收標準，能促使需求分析人員準確把握需求，牽引開發人員避免過度設計
兩個程式設計師在一臺電腦前工作，一個負責敲程式碼，一個實時檢視每一行敲入的程式碼。
「駕駛員」「領航員」
領航員檢視的同時還要負責考慮下一步的工作方向
角色經常互換
開始一個新的Story開發的時候可以變換搭檔
培養團隊成員積極，主動，開放，寫作的心態能夠增進結對程式設計效果
實施初期需要精心輔導
有助於提升程式碼設計品質
總體效率更高（程式設計慢了，但是缺陷少了）
結對程式設計能夠大幅促進團隊能力提升和知識傳播
結對程式設計提高程式碼品質和工作效率
以測試作爲程式設計的中心，他要求在編寫任何程式碼之前，首先編寫定義程式碼功能的測試用例，編寫的程式碼要通過用例，並不斷進行重構優化
測試程式碼和原始碼一樣都需要簡潔，可讀性好
測試用例的設計要保證完備，覆蓋被測試單元的所有功能
每個測試用例儘量保持獨立，減少依賴，提高用例的可維護性
當功能單元較大時，爲降低難度，可分解爲多個更小的功能單元，並逐一用TDD實現
和程式碼同步增長的自動化測試用例，能爲程式碼構築安全網，保證程式碼重構的品質，有助於開發人員優化程式碼設計，提高程式碼的可測試性
測試驅動開發保證程式碼整潔可用
一項軟體的開發時間，團隊的成員經常整合他們的工作，通常每人每天至少整合一次，每次整合通過自動化構建完成
大幅縮短反饋週期，試試反應產品真實品質狀態
缺陷在引入的當天就被發現了並解決，降低缺陷修改成本
將整合工作分散在平時，通過每天生成可部署的軟體避免產品最終整合時爆發大量問題
持續整合強調「快速」和「反饋」，要求完成一次系統整合的時間儘量短，並提供完備且有效的反饋資訊
自動化測試用例的完備性和有效性是持續整合品質保障
修復失敗的構建是團隊最高優先順序的任務
開發人員必須現在本地構建成功，纔可提交程式碼到設定庫
持續整合的狀態必須實施視覺化顯示給所有人
大系統持續整合需分級分層，建立各層次統一的測試策略
持續整合提供產品品質的快速反饋，保證隨時擁有可工作的軟體
從使用者視角全面展示覆雜產品系統的功能依賴關係，讓整個系統的功能自底向上逐步有序的開發和整合
Anatomy不是系統架構檢視，圖中的Block是表示系統給使用者使用的一個功能，是站在純使用者視角的，不包含設計資訊
Anatomy中的依賴關係是使用者使用系統功能的依賴關係，而不是設計或架構上的依賴關係
Anatomy是系統全檢視，由最瞭解系統的工程師繪製出基線，在增量開發時需要不斷重新整理
Anatomy是迭代計劃制定的重要依據，保證系統按照類似生物自然生長的順序自底向上有序的開發和整合
可作爲視覺化工具，通過表示圖中每一個功能的狀態，使系統整體進展一目瞭然，極大增強團隊的信心
有助於團隊從增量交付向交付全系統的四位轉變
是很好的培訓教材，幫助工程師瞭解全系統
Anatomy幫助團隊理解系統全域性，只能合理的迭代計劃