參加了2019.12.7的acp考試，順利通過啦~
平時工作忙，忙裏抽空學習，參加考試，索性一次性過了。記錄下考試的知識要點。
考題分佈
| 領域 | 考題比例 |
|---|---|
| 領域1：敏捷準則和理念 | 16% |
| 領域2：價值驅動的交付 | 20% |
| 領域3：干係人蔘與 | 17% |
| 領域4：團隊績效 | 16% |
| 領域5：適應性計劃 | 12% |
| 領域6：問題發現和解決 | 10% |
| 領域7：持續改進（產品、過程、人員） | 9% |
1、瀑布和敏捷的區別
2、敏捷宣言（四大宣言，記住）
- 個體與交互 重於 流程和工具
- 可用的軟件 重於 完備的文檔
- 客戶協作 重於 合同談判
- 響應變化 重於 遵循計劃
敏捷開發核心思想： 以人文本，適應變化。
3、敏捷原則（12原則，記住）
- 我們的最高目標是，通過儘早持續交付有價值的軟件來滿足客戶的需求。
- 歡迎對需求提出變更，即使在項目開發後期也不例外。敏捷過程要善於利用需求變更，幫助客戶獲得競爭優勢。
- 要經常交付可用的軟件，週期從幾周到幾個月不等，且越短越好。
- 項目實施過程中，業務人員與開發人員必須始終通力協作。
- 要善於激勵項目人員，給予他們所需的環境和支持，並相信他們能夠完成任務。
- 無論是對開發團隊開始團隊內部，信息傳達最有效的方法都是面對面的交談。
- 可用的軟件是衡量進度的首要衡量標準。
- 敏捷過程提倡可持續的開發。項目發起人、開發人員和用戶應該都能夠始終保持步調穩定。
- 對技術的精益求精以及對設計的不斷完善將提高敏捷性。
- 簡潔，即盡最大可能減少不必要的工作，這是一門藝術。
- 最佳的架構、需求和設計將出自於自組織團隊。
- 團隊要定期反省怎樣做才能更有效，並相應地調整團隊的行爲。
4、敏捷項目管理框架
敏捷項目管理框架分爲5個階段：envision展望（構想）階段、speculate推測階段、explore探索階段、adapt適應階段、close結束階段。
（一）envision展望（構想）階段
（1）目的：
描述項目願望，指明方向。
（2）定義產品願景的方法：
產品盒子、電梯演講。
（3）商業論證：
- 投資回報率ROI，越大越好；
- 回收期，越短越好；
- 淨現值NPV（考慮通貨膨脹等，把未來的錢算成現在的錢）越大越好；
- 內部報酬率IRR，越大越好。
（4）敏捷章程的內容：
目標說明、用戶和客戶的收益、要點、技術上的考慮、問題和風險、干係人、主要里程碑、團隊成員。（與傳統差不多，沒有對項目經理的授權）
（5） 敏捷中的主要角色（組建的團隊中）：
- SM：需要服務整個團隊；需要引導團隊消除遇到的障礙；如果有人影響了團隊，需要去消除影響；如果有人影響了敏捷流程，需要去引導走敏捷；
- PO：負責產品願意，需要確認有哪些用戶故事，確認用戶故事優先級（大家都可以討論，拍板的是PO）；
- 開發團隊：自組織、T型人才。
考試重點：在案例中，事先或當前，誰應該做什麼？
（6）團隊工作協議：
- 團隊社會契約
- 團隊價值觀，例如可持續的開發速度和核心工作時間；
- 工作協議，例如“就緒”如何定義，這是團隊可以接受工作的前提；“完成”如何定義；
- 基本規則，例如有關一個人在會議上發言的規定；
- 團隊規範，例如團隊如何對待會議時間；
（二）speculate推測階段
（1）敏捷規劃有4個不同的層次
- 產品線路圖
1）確認需求（這些會成爲產品待辦事項的一部分）;
2）將需求分類或分定主題;
3）評估相對工作量（例如，計劃撲克或者親和估算）和優先化（價值）;
4）評估粗略時間框架（評估高速和衝刺持續時間，以及粗略發佈時間）。
- 發佈（release） ，對應的是“用戶故事”
- 迭代（sprint），對應的是“任務”（用戶故事拆分的具體任務）
- 每日
（2）產品待開發列表 PB
PB裏都是用戶故事，可以是需求，可以是BUG，可以是技術重構； 用戶故事粒度上細下粗、漸進明細；用戶故事優先級上高下低；PB是動態的，可以調整的；
（3）用戶故事
- 標準格式：作爲XXX《客戶》，我想XXX《目標》，以便XXX《商業目標或利益》；卡片背面：驗收標準。
考試點：以這樣的標準格式描述，然後問其中的目標是什麼，或者問商業目標是什麼。
-
3C原則：
①卡片card ②對話conversation ③驗證confirmation - INVEST原則：
①Independent獨立的 ②Negotiable便於溝通的 ③Valuable 有價值的 ④Estimable可估計的 ⑤Small 短小 ⑥Testable 可測試的
（4）用戶故事優先級排序
- MoSCoW
Must必須做 Should應該做 Could可以做 Would not不要做
- 虛擬貨幣（Monopoly Money）
用錢去買用戶故事
- 100點方法
100點分給需求，哪個需求分的點數多，就說明需求優先級高。
- Kano分析
順序：基本需求、期望需求、讓人興奮的需求
- 需求優先級模型
價值、風險 把需求分爲4個象限
順序：價值高風險高（風險不一定是負面也可能是機遇）、價值高風險低、價值小風險小、價值小風險高。
