pmi-ACP考試知識點梳理（部分）

敏捷宣言

• 個體和互動 高於流程和工具
• 工做的軟件 高於詳盡的文檔
• 客戶合做 高於合同談判
• 響應變化 高於遵循計劃

十二條敏捷原則

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）