最近在學(xué)習(xí)敏捷ACP共郭，將個人學(xué)習(xí)的一些總結(jié)記錄在這里可帽，網(wǎng)上ACP資料不多擦盾，總結(jié)中的有些觀點和翻譯也只代表我自己的理解窒舟，轉(zhuǎn)載請注明出處系忙。

l 敏捷宣言

• 個體和互動 高于流程和工具(Individuals and interactions over processes and tools)

• 工作的軟件 高于詳盡的文檔(Working software over comprehensive documentation)

• 客戶合作 高于合同談判(Customer collaboration over contract negotiation)

• 響應(yīng)變化 高于遵循計劃(Responding to change over following a plan)

l 12條敏捷原則

1 我們最重要的目標(biāo)，是通過持續(xù)不斷地及早交付有價值的軟件使客戶滿意惠豺。

2 歡迎需求變化银还，即使在開發(fā)后期也一樣。善于掌控變化洁墙，幫助客戶獲得競爭優(yōu)勢蛹疯。

3 經(jīng)常地交付可工作的軟件，相隔幾星期或幾個月热监，傾向于采取較短的周期捺弦。

4 業(yè)務(wù)人員和開發(fā)人員必須每天在一起工作。

5 激發(fā)個體的斗志孝扛，以他們?yōu)楹诵拇罱椖苛泻稹Ｌ峁┧麄兯璧?strong>環(huán)境和支持，相信他們能夠達(dá)成目標(biāo)苦始。

6在團(tuán)隊內(nèi)部寞钥，傳遞信息效果最高效的方式是面對面的交談。

7可工作的軟件是進(jìn)度的首要度量標(biāo)準(zhǔn)陌选。

8 敏捷過程倡導(dǎo)可持續(xù)開發(fā)理郑。責(zé)任人、開發(fā)人員和用戶要能夠共同維持其步調(diào)穩(wěn)定延續(xù)柠贤。

9 對技術(shù)精益求精香浩，對設(shè)計不斷完善，將提高敏捷能力臼勉。

10 以簡潔為本邻吭，極力減少不必要工作量。

11 最好的架構(gòu)宴霸、需求和設(shè)計出自于自組織的團(tuán)隊囱晴。

12 團(tuán)隊定期地反省如何能提高成效膏蚓，并由此調(diào)整團(tuán)隊的行為。

l 相互依賴聲明(Declaration of Interdependence)

● 我們通過創(chuàng)造我們關(guān)注的持續(xù)價值流來提高投資回報率畸写。

● 我們通過與客戶頻繁的交互和分享所有權(quán)來交付可靠的結(jié)果驮瞧。

● 我們承認(rèn)不確定性，并通過迭代枯芬、規(guī)劃和適應(yīng)來管理它论笔。

● 我們通過承認(rèn)個人是價值的最終來源、創(chuàng)造使他們有所作為的環(huán)境來激發(fā)創(chuàng)造力和創(chuàng)新力千所。

● 我們通過團(tuán)隊結(jié)果問責(zé)制和團(tuán)隊職責(zé)分享制來提升績效狂魔。

● 我們通過因地制宜地應(yīng)用具體的策略、過程和實踐來改進(jìn)效率和可靠性淫痰。

l 敏捷術(shù)語和概念

敏捷最適合具有復(fù)雜要求和技術(shù)的項目

敏捷項目范圍不固定最楷，而時間和成本是固定的

敏捷使用自上而下的估計

敏捷文檔通常勉強夠用

敏捷有利于適應(yīng)，而傳統(tǒng)的管理方法有利于預(yù)期

敏捷掙值管理（EVM）用于價值跟蹤報告待错，最好應(yīng)用于迭代級別

l 積極傾聽(Active Listening) - 通過以下步驟進(jìn)行聽力技能進(jìn)步：

• 內(nèi)部傾聽(InternalListening)（這將如何影響我）

• 集中傾聽(Focused Listening)（他們真正想說的是什么）

• 整體傾聽(Global Listening)（注意除了所說的之外的其他標(biāo)志）

l 適應(yīng)性領(lǐng)導(dǎo)(Adaptive Leadership ) - 領(lǐng)導(dǎo)者必須適應(yīng)形勢籽孙，以最有效地領(lǐng)導(dǎo)

l 敏捷游戲（協(xié)作和創(chuàng)新游戲）

記住未來：用于視覺設(shè)定和需求啟發(fā)的游戲

修剪產(chǎn)品樹：用于以幫助收集和塑造需求的游戲

快艇/帆船：用于識別產(chǎn)品的威脅和機會（力量）的游戲

購買功能：確定優(yōu)先級的游戲

Bank-for-the-Buck：審視價值與成本的游戲

產(chǎn)品盒（Vision Box）：設(shè)計產(chǎn)品的虛擬盒子（確定最重要的前3項工作）以確定優(yōu)先級

l 架構(gòu)刺探(Architectural Spike) -源于極限編程模式中的技術(shù)探險，寫足夠的代碼來探知某個新興技術(shù)（或不熟悉的技術(shù)）的使用所可能帶來的技術(shù)風(fēng)險火俄， 對于復(fù)雜的調(diào)研任務(wù)犯建，架構(gòu)Owner可能需要部分團(tuán)隊成員的配合，在Sprint中安排Spike類型的任務(wù)烛占。

l 探針(Spike)- Spike是一種技術(shù)嘗試胎挎，用于通過快速失敗來降低風(fēng)險沟启。

l 燃燒率 - 每次迭代的人工（最大部分）和其他成本忆家，用于準(zhǔn)備預(yù)算或EVM

l 洞穴和公共區(qū)域（Caves and Commons）

公共區(qū)域(Commons)：為最大化滲透溝通而組織的共同工作空間

洞穴(Caves)：半私人空間，可以做電子郵件德迹，打電話等芽卿，不被別人打擾

l 沖突級別(Conflict Levels)

1.Problem to Solve

2.Disagreement

3.Contest

4.Crusade

5.World War

l 構(gòu)造成本模型（COCOMO） - 對已完成的軟件項目的輸入進(jìn)行逆向工程，這些項目已知具體成本胳搞，以便對新項目進(jìn)行估算卸例。是普及程度比較高的一種自頂向下項目成本估算模型，是比較精確肌毅，易于使用的成本估算方法筷转。

l 累積流圖(CFD) -一個實踐工具，可以幫助我們看到WIP的狀態(tài)悬而、項目的步調(diào)呜舒、并且快速識別出交付時間存在的風(fēng)險以及瓶頸。

l 周期時間(Cycle Time) - 將需求轉(zhuǎn)化為生產(chǎn)所需的時間

l 決策譜（由Jim Highsmith提供） - 一種參與式?jīng)Q策制定工具笨奠，允許人們表明對決策的支持/保留袭蝗。
Decision Spectrum (by Jim Highsmith) – a participatory decision making tool to allow people to indicate support/reservation for decision

l DRY (don’t repeat yourself) –一種編程哲學(xué)唤殴，要求程序員不要重復(fù)相同的代碼

l 經(jīng)驗過程控制(Empirical Process Control) –關(guān)于項目的決策是基于項目執(zhí)行期間的持續(xù)觀察和實驗而不是預(yù)先計劃

l 史詩故事(Epic Story) – 史詩般的故事是大型用戶故事，可以分解為較小的用戶故事到腥，可以在產(chǎn)品backlog的底部找到

l 逃逸缺陷(Escaped Defect) – 客戶發(fā)現(xiàn)的問題或錯誤朵逝，即逃過驗證，驗證和驗收測試.

l 失敗模式Failure Modes [by Alistair Cockburn]

• 犯錯誤Making mistakes

• 喜歡保守地失敗Preferring to fail conservatively

• 發(fā)明而不是研究Inventing rather than researching

• 成為習(xí)慣的生物Being creatures of habit

• 不一致Being inconsistent.

l 功能緩沖區(qū)(Feature Buffer) – 用于管理風(fēng)險乡范，以確迸涿可以提供必須具備的功能.

l 通才(Generalized Specialist) – 通才最適合敏捷團(tuán)隊，因為敏捷團(tuán)隊成員必須具有跨職能

l 基本規(guī)則(Ground Rules) –由ScrumMaster / Coach定義的規(guī)則晋辆，與團(tuán)隊達(dá)成共識抵知，每個人都必須遵守

l 強化迭代(Hardening Iteration) (Iteration H) –為產(chǎn)品準(zhǔn)備產(chǎn)品的最后一次迭代，通常涉及最終測試两踏，管理授段，文檔

l 所見即所得(IKIWISI , I know it when I see it) –這是普通客戶的典型，他們需要直觀感受產(chǎn)品以挖掘自身的需求涩哟。

l 信息發(fā)射源(Information Radiator )–顯示項目進(jìn)度和狀態(tài)的高度可見的圖表和數(shù)字索赏，例如 看板，燃盡圖贴彼。

l Iteration Zero（迭代0） - 迭代1之前的迭代潜腻，用于創(chuàng)建Charter，征求要求或調(diào)研技術(shù)器仗，做一些前期的規(guī)劃和設(shè)計融涣，包括一系列初始化工作 為后續(xù)迭代做好啟動準(zhǔn)備。

l Kano分析：這是一種對用戶需求分類和優(yōu)先排序的有用工具精钮，它將客戶偏好分為4類威鹿。

• 興奮（魅力）型需求—Exciters / Delighters - 帶來最大價值

• 滿意者 - 帶來價值

• 不滿意 - 如果不存在則引起不適

• 無差異型需求——Indifferent

l 精益投資組合管理(Lean Portfolio Management ) - 選擇項目以最大化投資回報的方法

• 投資組合應(yīng)包括最低市場特征（MMF），以便快速交付

• 盡量減少在制品

l 最小化可交付的特性（MMF）-為最終用戶提供價值的最小功能集. 一個MMF是最小粒度且有商業(yè)價值的特性轨香。MMF被放在一個隊列中維護(hù)忽你，（很像Scrum中的產(chǎn)品Backlog），但對隊列的大小有嚴(yán)格的限制（James認(rèn)為應(yīng)該是兩到三個臂容，最多七個）科雳。

l 滲透式溝通- 通過無意間聽到其他人之間的對話而無意中獲取有用的信息，當(dāng)一個人提問時脓杉，房間內(nèi)的其他人可以選擇聽或者不聽——參與討論或者繼續(xù)工作糟秘。

l 帕累托原則 - 也稱為80-20規(guī)則指出，對于敏捷項目球散，80％的最有用的功能可以在20％的努力中完成尿赚，強烈建議關(guān)注“20％”

l 參與式設(shè)計 - 通過積極讓利益相關(guān)者參與設(shè)計過程來確保結(jié)果符合預(yù)期的設(shè)計方法。

l 項目章程對于敏捷項目和傳統(tǒng)項目都很重要，必須在敏捷項目開始時創(chuàng)建吼畏。

l 項目數(shù)據(jù)表（PDS） - 是所有關(guān)鍵業(yè)務(wù)和質(zhì)量目標(biāo)督赤，產(chǎn)品功能和項目管理信息（包括里程碑，風(fēng)險等）的單頁摘要泻蚊。

l 產(chǎn)品路線圖(Product Roadmap) - 提供功能發(fā)布里程碑的高級概述躲舌。

l 重構(gòu) - 在不改變行為或效率的情況下提高代碼質(zhì)量

l 莫斯科原則MoSCoW

• 必須有的（基本功能）

• 應(yīng)該有的（重要但短期內(nèi)有替代解決方案的功能）

• 可以有的（沒時間就不考慮的）

• 這次不會有（客戶期望擁有但同時承認(rèn)需要在后續(xù)發(fā)布中實現(xiàn)的功能）

l 發(fā)布計劃輸出是：（進(jìn)入首個 Sprint 階段之前，需要舉行一個發(fā)布計劃會議）

• 發(fā)布計劃
• 發(fā)布backlog
• 行動/行動項目
• 風(fēng)險
• 假設(shè)
• 依賴

l 風(fēng)險燃盡圖 - 顯示風(fēng)險嚴(yán)重程度(severities)隨時間的變化性雄，風(fēng)險通常隨項目進(jìn)展而下降

風(fēng)險嚴(yán)重性(severities)=風(fēng)險概率*風(fēng)險影響

l 故事地圖(Story Maps) - 顯示每個版本中用戶故事/史詩的分類方式：

主線(backbone)：基本功能

行走的骨骼(walking skeleton) Walking Skeleton：最小的功能集

附加功能：其他功能

l 隱性知識(Tacit Knowledge) - 是項目中無書面表達(dá)的信息和知識没卸，不能/很難通過寫下或用語言表達(dá)來轉(zhuǎn)移給他人。隱性知識是高度個性化而且難于格式化的知識秒旋，主觀的理解约计、直覺和預(yù)感都屬于這一類。

l 團(tuán)隊形成階段

• 組建期(Forming)[領(lǐng)導(dǎo)風(fēng)格：指揮或告知Directing] – 項目小組啟蒙階段迁筛。

• 激蕩期(Storming)[領(lǐng)導(dǎo)風(fēng)格：教練Coaching] – 形成各種觀念煤蚌，激烈競爭、碰撞的局面细卧。

• 規(guī)范期(Norming)[領(lǐng)導(dǎo)風(fēng)格：支持Supporting]- 規(guī)則尉桩、價值、行為贪庙、方法蜘犁、工具均以建立。

• 執(zhí)行期(Performing)[領(lǐng)導(dǎo)風(fēng)格：委任式Delegating] – 人際結(jié)構(gòu)成為執(zhí)行任務(wù)活動的工具止邮。

• 休整期(Adjourning) – 任務(wù)完成这橙，團(tuán)隊解散。

l 技術(shù)債(Technical Debt)

技術(shù)債務(wù) - 包含代碼导披，技術(shù)文檔屈扎，開發(fā)環(huán)境，第三方工具和開發(fā)實踐方面的缺陷盛卡，這使得團(tuán)隊難以更改代碼

通過簡化或優(yōu)化設(shè)計來降低技術(shù)債務(wù)可以提高生產(chǎn)率助隧，從而提高速度

從理論上講筑凫，XP項目不會產(chǎn)生技術(shù)債務(wù)滑沧，因為重構(gòu)是一只進(jìn)行的。

l 敏捷沖突的三步干預(yù)方法：

您是否與_________分享了您對此的疑慮和感受巍实？
_______應(yīng)該知道你的擔(dān)憂滓技。 如果我和你一起去，會有幫助嗎棚潦？
我可以告訴_________你有這些顧慮嗎令漂？

l 三角測量(Triangulation) - 用戶故事可以通過定義幾個故事（各種大小）作為基線來估算. 三角測試是幫助團(tuán)隊驗證他們沒有逐漸改變一個故事點含義的有效方法。比較故事的故事點叠必；列出所有故事的故事點荚孵，按故事點排列比較

l 角色(Persona) - 表示產(chǎn)品的一組典型用戶

極端角色(Extreme Persona) – 極端角色，以識別用戶故事纬朝，否則將被遺漏

l 用戶故事 -意思是來描述用戶渴望得到的功能收叶。一個好的用戶故事包括三個要素：
1. 角色：誰要使用這個功能。
2. 活動：需要完成什么樣的功能或目標(biāo)共苛。
3.商業(yè)價值：為什么需要這個功能判没，這個功能帶來什么樣的價值。
用戶故事通常按照如下的格式來表達(dá)：

• 英文：As a <Role>, I want to <Activity>, so that <Business Value>.
• 中文：作為一個<角色>, 我想要<活動>, 以便于<[商業(yè)價值]>

l 3C：卡片(Card)隅茎、對話(Conversation)和確認(rèn)(Confirmation)澄峰。

• 卡片（Card）：用戶故事一般在小卡片上寫著故事的簡短描述，工作量估算等辟犀。

• 交談（Conversation）：用戶故事背后的細(xì)節(jié)來源于和客戶或者產(chǎn)品負(fù)責(zé)人的交流溝通俏竞。

• 確認(rèn)（Confirmation）：通過驗收測試確認(rèn)用戶故事被正確完成。

l 用戶故事的六個特性- INVEST：

- I dependent(獨立的)

- N egotiable(便于溝通的)

- V aluable(有價值的)

- E stimable(可估計的)

- S mall(短小)

- T estable(可測試的)

l 速率(Velocity) - 衡量團(tuán)隊速度的指標(biāo)（一輪迭代完成的故事點數(shù)）堂竟，用于在迭代計劃中創(chuàng)建項目進(jìn)度表胞此。

l 寬帶德爾菲法（Wide band Delphi）- 一種生成估計的方法，涉及參與者之間比傳統(tǒng)Delphi方法更多的交互和溝通跃捣。團(tuán)隊成員聚在一起演示用戶故事漱牵，討論面臨的挑戰(zhàn)，然后私下進(jìn)行估算的一種估計技術(shù)疚漆。每個故事的估算結(jié)果都會被匿名標(biāo)注在圖表上酣胀，然后團(tuán)隊就故事點范圍進(jìn)行討論，并嘗試達(dá)成普遍共識娶聘。

寬帶德爾菲估計法建立在傳統(tǒng)德爾菲技術(shù)基礎(chǔ)上闻镶。具體方法是，在會議中丸升，只討論估計時可能會遇到的問題铆农，估計本身和所花費的成本不做討論。會議討論后讓每個人分開狡耻，獨自準(zhǔn)備他們的估計墩剖，一定要注意，讓每個人做估計時遠(yuǎn)離群體夷狰。 接下來召回團(tuán)隊成員岭皂，匯集所有的估計，并在圖表中畫出來沼头，展示價值的分布爷绘，但每個估計都不寫估計者的名字书劝。然后團(tuán)隊再討論存在估算差異的情況，并設(shè)法達(dá)成共識土至。

l 在制品（WIP） - 過多的WIP會降低效率购对，因為可能需要更多的返工。

小定律：循環(huán)時間與WIP的數(shù)量成正比

l 精益生產(chǎn)七大浪費(The seven forms of waste)：

• Transport
• Inventory
• Motion
• Waiting
• Overproducting
• Over processing
• Defects

l 故事點估算：

• 計劃撲克：需要整個開發(fā)團(tuán)隊參與陶因，包括業(yè)務(wù)分析人員洞斯、開發(fā)人員以及測試分析人員，此外還包括Scrum主管以及產(chǎn)品負(fù)責(zé)人坑赡。開始討論時烙如，首先對產(chǎn)品積壓工作上每個用戶故事作一些詳細(xì)的介紹，然后要求每個人用故事點數(shù)來給故事的大小投票毅否。在一個單獨的sprint內(nèi)亚铁，當(dāng)要估算的用戶故事數(shù)目不多時，可以使用計劃撲克螟加。

• 親和估算：當(dāng)用戶故事數(shù)量比較多或者時間太短時的時候徘溢，是一種快速估算故事相對大小的方法。團(tuán)隊無需逐個討論每個故事捆探，只需要從產(chǎn)品積壓工作中提取兩個優(yōu)先級最高的故事并對比它們的工作量大小然爆，然后將小故事的卡片放在桌子的左側(cè)，大故事的卡片放在桌子的右側(cè)黍图。

l 產(chǎn)品待辦事項(product backlog)的DEEP原則:

• 詳略得當(dāng)（D etailed Appropriately）

• 做過估算的（E stimated）

• 涌現(xiàn)的（E mergent）

• 排列優(yōu)先級的（P rioritized）

l 敏捷項目團(tuán)隊規(guī)模：團(tuán)隊人數(shù)5-9人（不含PO和SM）

（晚晴風(fēng)個人總結(jié)曾雕，轉(zhuǎn)載請注明出處）