敏捷宣言
- 個體和互動 高於流程和工具
- 工作的軟件 高於詳盡的文檔
- 客戶合作 高於合同談判
- 響應變化 高於遵循計划
十二條敏捷原則
1 我們最重要的目標，是通過持續不斷地及早交付有價值的軟件使客戶滿意。
2 歡迎需求變化，即使在開發后期也一樣。善於掌控變化，幫助客戶獲得競爭優勢。
3 經常地交付可工作的軟件，相隔幾星期或幾個月，傾向於采取較短的周期。
4 業務人員和開發人員必須每天在一起工作。
5 激發個體的斗志，以他們為核心搭建項目。提供他們所需的環境和支持，相信他們能夠達成目標。
6在團隊內部，傳遞信息效果最高效的方式是面對面的交談。
7可工作的軟件是進度的首要度量標准。
8 敏捷過程倡導可持續開發。責任人、開發人員和用戶要能夠共同維持其步調穩定延續。
9 對技術精益求精，對設計不斷完善，將提高敏捷能力。
10 以簡潔為本，極力減少不必要工作量。
11 最好的架構、需求和設計出自於自組織的團隊。
12 團隊定期地反省如何能提高成效，並由此調整團隊的行為。
相互依賴聲明(Declaration of Interdependence)
● 我們通過創造我們關注的持續價值流來提高投資回報率。
● 我們通過與客戶頻繁的交互和分享所有權來交付可靠的結果。
● 我們承認不確定性，並通過迭代、規划和適應來管理它。
● 我們通過承認個人是價值的最終來源、創造使他們有所作為的環境來激發創造力和創新力。
● 我們通過團隊結果問責制和團隊職責分享制來提升績效。
● 我們通過因地制宜地應用具體的策略、過程和實踐來改進效率和可靠性。
敏捷術語和概念
敏捷最適合具有復雜要求和技術的項目
敏捷項目范圍不固定，而時間和成本是固定的
敏捷使用自上而下的估計
敏捷文檔通常勉強夠用
敏捷有利於適應，而傳統的管理方法有利於預期
敏捷掙值管理（EVM）用於價值跟蹤報告，最好應用於迭代級別
積極傾聽(Active Listening) - 通過以下步驟進行聽力技能進步：
- 內部傾聽(InternalListening)（這將如何影響我）
- 集中傾聽(Focused Listening)（他們真正想說的是什么）
- 整體傾聽(Global Listening)（注意除了所說的之外的其他標志）
適應性領導(Adaptive Leadership ) - 領導者必須適應形勢，以最有效地領導
敏捷游戲（協作和創新游戲）
記住未來：用於視覺設定和需求啟發的游戲
修剪產品樹：用於以幫助收集和塑造需求的游戲
快艇/帆船：用於識別產品的威脅和機會（力量）的游戲
購買功能：確定優先級的游戲
Bank-for-the-Buck：審視價值與成本的游戲
產品盒（Vision Box）：設計產品的虛擬盒子（確定最重要的前3項工作）以確定優先級
架構刺探(Architectural Spike) -源於極限編程模式中的技術探險，寫足夠的代碼來探知某個新興技術（或不熟悉的技術）的使用所可能帶來的技術風險， 對於復雜的調研任務，架構Owner可能需要部分團隊成員的配合，在Sprint中安排Spike類型的任務。
探針(Spike)- Spike是一種技術嘗試，用於通過快速失敗來降低風險。
燃燒率 - 每次迭代的人工（最大部分）和其他成本，用於准備預算或EVM
洞穴和公共區域（Caves and Commons）
公共區域(Commons)：為最大化滲透溝通而組織的共同工作空間
洞穴(Caves)：半私人空間，可以做電子郵件，打電話等，不被別人打擾
沖突級別(Conflict Levels)
1.Problem to Solve
2.Disagreement
3.Contest
4.Crusade
5.World War
構造成本模型（COCOMO） - 對已完成的軟件項目的輸入進行逆向工程，這些項目已知具體成本，以便對新項目進行估算。是普及程度比較高的一種自頂向下項目成本估算模型，是比較精確，易於使用的成本估算方法。
累積流圖(CFD) -一個實踐工具，可以幫助我們看到WIP的狀態、項目的步調、並且快速識別出交付時間存在的風險以及瓶頸。
周期時間(Cycle Time) - 將需求轉化為生產所需的時間
決策譜（由Jim Highsmith提供） - 一種參與式決策制定工具，允許人們表明對決策的支持/保留。
Decision Spectrum (by Jim Highsmith) – a participatory decision making tool to allow people to indicate support/reservation for decision
DRY (don’t repeat yourself) –一種編程哲學，要求程序員不要重復相同的代碼
經驗過程控制(Empirical Process Control) –關於項目的決策是基於項目執行期間的持續觀察和實驗而不是預先計划
史詩故事(Epic Story) – 史詩般的故事是大型用戶故事，可以分解為較小的用戶故事，可以在產品backlog的底部找到
逃逸缺陷(Escaped Defect) – 客戶發現的問題或錯誤，即逃過驗證，驗證和驗收測試.
失敗模式Failure Modes [by Alistair Cockburn]
- 犯錯誤Making mistakes
- 喜歡保守地失敗Preferring to fail conservatively
- 發明而不是研究Inventing rather than researching
- 成為習慣的生物Being creatures of habit
- 不一致Being inconsistent.
功能緩沖區(Feature Buffer) – 用於管理風險，以確保可以提供必須具備的功能.
通才(Generalized Specialist) – 通才最適合敏捷團隊，因為敏捷團隊成員必須具有跨職能
基本規則(Ground Rules) –由ScrumMaster / Coach定義的規則，與團隊達成共識，每個人都必須遵守
強化迭代(Hardening Iteration) (Iteration H) –為產品准備產品的最后一次迭代，通常涉及最終測試，管理，文檔
所見即所得(IKIWISI , I know it when I see it) –這是普通客戶的典型，他們需要直觀感受產品以挖掘自身的需求。
信息發射源(Information Radiator )–顯示項目進度和狀態的高度可見的圖表和數字，例如 看板，燃盡圖。
Iteration Zero（迭代0） - 迭代1之前的迭代，用於創建Charter，征求要求或調研技術，做一些前期的規划和設計，包括一系列初始化工作 為后續迭代做好啟動准備。
Kano分析：這是一種對用戶需求分類和優先排序的有用工具，它將客戶偏好分為4類。
- 興奮（魅力）型需求—Exciters / Delighters - 帶來最大價值
- 滿意者 - 帶來價值
- 不滿意 - 如果不存在則引起不適
- 無差異型需求——Indifferent
精益投資組合管理(Lean Portfolio Management ) - 選擇項目以最大化投資回報的方法
- 投資組合應包括最低市場特征（MMF），以便快速交付
- 盡量減少在制品
最小化可交付的特性（MMF）-為最終用戶提供價值的最小功能集. 一個MMF是最小粒度且有商業價值的特性。MMF被放在一個隊列中維護，（很像Scrum中的產品Backlog），但對隊列的大小有嚴格的限制（James認為應該是兩到三個，最多七個）。
滲透式溝通- 通過無意間聽到其他人之間的對話而無意中獲取有用的信息，當一個人提問時，房間內的其他人可以選擇聽或者不聽——參與討論或者繼續工作。
帕累托原則 - 也稱為80-20規則指出，對於敏捷項目，80％的最有用的功能可以在20％的努力中完成，強烈建議關注“20％”
參與式設計 - 通過積極讓利益相關者參與設計過程來確保結果符合預期的設計方法。
項目章程對於敏捷項目和傳統項目都很重要，必須在敏捷項目開始時創建。
項目數據表（PDS） - 是所有關鍵業務和質量目標，產品功能和項目管理信息（包括里程碑，風險等）的單頁摘要。
產品路線圖(Product Roadmap) - 提供功能發布里程碑的高級概述。
重構 - 在不改變行為或效率的情況下提高代碼質量
莫斯科原則MoSCoW
- 必須有的（基本功能）
- 應該有的（重要但短期內有替代解決方案的功能）
- 可以有的（沒時間就不考慮的）
- 這次不會有（客戶期望擁有但同時承認需要在后續發布中實現的功能）
發布計划輸出是：（進入首個 Sprint 階段之前，需要舉行一個發布計划會議）
- 發布計划
- 發布backlog
- 行動/行動項目
- 風險
- 假設
- 依賴
風險燃盡圖 - 顯示風險嚴重程度(severities)隨時間的變化，風險通常隨項目進展而下降
風險嚴重性(severities)=風險概率*風險影響
故事地圖(Story Maps) - 顯示每個版本中用戶故事/史詩的分類方式：
主線(backbone)：基本功能
行走的骨骼(walking skeleton) Walking Skeleton：最小的功能集
附加功能：其他功能
隱性知識(Tacit Knowledge) - 是項目中無書面表達的信息和知識，不能/很難通過寫下或用語言表達來轉移給他人。隱性知識是高度個性化而且難於格式化的知識，主觀的理解、直覺和預感都屬於這一類。
團隊形成階段
- 組建期(Forming)[領導風格：指揮或告知Directing] – 項目小組啟蒙階段。
- 激盪期(Storming)[領導風格：教練Coaching] – 形成各種觀念，激烈競爭、碰撞的局面。
- 規范期(Norming)[領導風格：支持Supporting]- 規則、價值、行為、方法、工具均以建立。
- 執行期(Performing)[領導風格：委任式Delegating] – 人際結構成為執行任務活動的工具。
- 休整期(Adjourning) – 任務完成，團隊解散。
技術債(Technical Debt)
技術債務 - 包含代碼，技術文檔，開發環境，第三方工具和開發實踐方面的缺陷，這使得團隊難以更改代碼
通過簡化或優化設計來降低技術債務可以提高生產率，從而提高速度
從理論上講，XP項目不會產生技術債務，因為重構是一只進行的。
敏捷沖突的三步干預方法：
您是否與_________分享了您對此的疑慮和感受？
_______應該知道你的擔憂。 如果我和你一起去，會有幫助嗎？
我可以告訴_________你有這些顧慮嗎？
三角測量(Triangulation) - 用戶故事可以通過定義幾個故事（各種大小）作為基線來估算. 三角測試是幫助團隊驗證他們沒有逐漸改變一個故事點含義的有效方法。比較故事的故事點；列出所有故事的故事點，按故事點排列比較
角色(Persona) - 表示產品的一組典型用戶
極端角色(Extreme Persona) – 極端角色，以識別用戶故事，否則將被遺漏
用戶故事 -意思是來描述用戶渴望得到的功能。一個好的用戶故事包括三個要素：
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(可測試的)
速率(Velocity) - 衡量團隊速度的指標（一輪迭代完成的故事點數），用於在迭代計划中創建項目進度表。
寬帶德爾菲法（Wide band Delphi）- 一種生成估計的方法，涉及參與者之間比傳統Delphi方法更多的交互和溝通。團隊成員聚在一起演示用戶故事，討論面臨的挑戰，然后私下進行估算的一種估計技術。每個故事的估算結果都會被匿名標注在圖表上，然后團隊就故事點范圍進行討論，並嘗試達成普遍共識。
寬帶德爾菲估計法建立在傳統德爾菲技術基礎上。具體方法是，在會議中，只討論估計時可能會遇到的問題，估計本身和所花費的成本不做討論。會議討論后讓每個人分開，獨自准備他們的估計，一定要注意，讓每個人做估計時遠離群體。 接下來召回團隊成員，匯集所有的估計，並在圖表中畫出來，展示價值的分布，但每個估計都不寫估計者的名字。然后團隊再討論存在估算差異的情況，並設法達成共識。
在制品（WIP） - 過多的WIP會降低效率，因為可能需要更多的返工。
小定律：循環時間與WIP的數量成正比
精益生產七大浪費(The seven forms of waste)：
- Transport
- Inventory
- Motion
- Waiting
- Overproducting
- Over processing
- Defects
故事點估算：
- 計划撲克：需要整個開發團隊參與，包括業務分析人員、開發人員以及測試分析人員，此外還包括Scrum主管以及產品負責人。開始討論時，首先對產品積壓工作上每個用戶故事作一些詳細的介紹，然后要求每個人用故事點數來給故事的大小投票。在一個單獨的sprint內，當要估算的用戶故事數目不多時，可以使用計划撲克。
- 親和估算：當用戶故事數量比較多或者時間太短時的時候，是一種快速估算故事相對大小的方法。團隊無需逐個討論每個故事，只需要從產品積壓工作中提取兩個優先級最高的故事並對比它們的工作量大小，然后將小故事的卡片放在桌子的左側，大故事的卡片放在桌子的右側。
產品待辦事項(product backlog)的DEEP原則:
- 詳略得當（D etailed Appropriately）
- 做過估算的（E stimated）
- 涌現的（E mergent）
- 排列優先級的（P rioritized）
敏捷項目團隊規模：團隊人數5-9人（不含PO和SM）