前提
考完PMP之後，想對項目管理有更好的瞭解，就用備考PMI-ACP，一次通過，以下是備考心得：
心得
學習技巧
-
時間盒子彙總：
![]()
Product Backlog 產品待辦事項。由 PO 負責維護，包括增、刪及優先級排序。
Sprint Backlog 衝刺待辦事項。本次衝刺內規劃要完成的內容，源於 Product Backlog, 由 團隊一起選擇，並定義 “完成” 的標準。
Incremental 可交付產品增量。衝刺結束後可對外發布的可工作的產品功能/軟件，需在 Sprint Review Meeting 上進行演示。Scrum 團隊 3 個核心角色:Product Owner、Dev Team、Scrum Master.
Dev Team: 自組織的、跨功能、無頭銜、通才而非專才、責任歸屬團隊。
PO: 只有一個人扮演 PO 角色。負責產品待開發項優先級排序、澄清需求。確保開發團隊的 價值，對最終產品負責、對風險負責，與干係人溝通。
Scrum Master: 確保 Scrum 理論、規則和實務，推動 Scrum 相關知識、負責移除團隊障礙、 僕人式領導、教導/引導團隊提高產品價值、與其它 Scrum team 合作 (Scrum of Scrums).Scrum 5 種事件:
Sprint 衝刺: 時間盒固定，長度 2~4 周 。
Sprint Planning Meeting 衝刺計劃。確定 Sprint 目標，在每次迭代衝刺前舉行。最長 8 小時。
Daily Scrum Meeting 每日站會。昨天做了什麼，今天計劃做什麼，遇到什麼阻礙。15 分鐘。
Sprint Review Meeting 衝刺評審。團隊全體參與、邀請相關干係人蔘與。展示迭代產品，以獲得客戶反饋, 2~4 小時。PO 可以拒絕接收成果。
Sprint Retrospective Meeting 衝刺回顧。每個衝刺結束時舉行，團隊一起復盤本衝刺過程，總結經驗與教訓，形成切實可行的改進清單。只有開發團隊內部參加，PO/SM/干係人無需參加，若參加，則不能參與討論，可最後發言。2~4 小時。XP 核心實踐:1) 完整的團隊 2) 規劃遊戲(三個階段:探測→計劃→調整) 3) 小型發佈 4) 客戶測試 5) 共享代碼 6) 編碼標準 7) 可持續的進度 8) 隱喻 9) 持續集成 10) 測試先行/測試 驅動開發 11) 重構 12) 簡單設計 13) 結對編程
FDD 特性驅動開發：爲產品開發一個整體的模型，先構建產品特性列表和工作計劃,開發團隊再構建和開發。
DSDM 動態系統開發：也稱業務中心框架開發方法。倡導以業務爲核心，快速而有效地進行系統開發。
基本觀點:80%/20%法則。MoSCoW 基於客戶價值的優先級分析。Lean 精益開發：7 大價值觀:1) 消除浪費 2) 構建質量 (常用技術:重構、持續集成和單元測試) 3) 創建知識 4) 推遲決策 5) 快速交付 6) 尊重 7) 整體優化。
Kanban 看板開發：是一個拉式系統，專門用於知識型工作。1) 可視化價值流 2) 限制 WIP 3) 度量和管理流動 4) 協同改進 5) 顯示化流程規則。
看板沒有時間盒的限定，沒有迭代的概念，強調持續交付。當一個工作完成時，就會啓動拉 式機制。敏捷宣言：
個體和互動 高於 流程和工具
工作的軟件 高於 詳盡的文檔
客戶合作 高於 合同談判
響應變化 高於 遵循計劃十二條敏捷原則：
我們最重要的目標，是通過持續不斷地及早交付有價值的軟件使客戶滿意。
歡迎需求變化，即使在開發後期也一樣。善於掌控變化，幫助客戶獲得競爭優勢。
經常地交付可工作的軟件，相隔幾星期或幾個月，傾向於採取較短的週期。
業務人員和開發人員必須每天在一起協作工作。
激發個體的鬥志，以他們爲核心搭建項目。提供他們所需的環境和支持，相信他們能夠達成目標。
在團隊內部，傳遞信息效果最高效的方式是面對面的交談。
可工作的軟件是進度的首要度量標準。
敏捷過程倡導可持續開發。責任人、開發人員和用戶要能夠共同維持其步調穩定延續。
對技術精益求精，對設計不斷完善，將提高敏捷能力。
以簡潔爲本，極力減少不必要工作量。
最好的架構、需求和設計出自於自組織的團隊。
團隊定期地反省如何能提高成效，並由此調整團隊的行爲。TDD 測試驅動開發：
測試驅動開發(Test-Driven Development, TDD), TDD 的四個步聚過程
1.在開發某個功能代碼之前先編寫測試
2.覈對和確認測試，運行所有測試，並且全部通過
3.編寫產品代碼，接着測試
4.重構產品代碼，以消除重複設計，優化設計結構ATDD 驗收驅動開發
ATDD 驗收測試驅動開發使測試的焦點從代碼本身轉向業務需求，包含 4 個步聚:
1.討論 Discussion, 討論需求。
2.提取 Distill, 提取(提練)測試
3.開發 Development，開發代碼並連接測試
4.示範 Demo，示範(演示)軟件敏捷溝通：當然敏捷的第六項原則是“開發團隊內部和之間最有效和最有力的傳達信息的方式是面對面對話。”從這層意思上說，敏捷傾向於和鼓勵所有干係人和團隊成員的協作，因爲溝通的最好方式是面對面對話，並且反過來，促進知識分享。基本上成千的決策都是在項目的過程中決定的，其中的許多決策是爲了應對團隊無可避免面臨的問題的。因此適當地熟悉問題解決的策略，工具和技能對敏捷團隊來說是至關重要的。
史詩故事：是一個大型故事，可能橫跨幾個迭代週期。它也被稱爲一種能力。
用戶故事：意思是來描述用戶渴望得到的功能。一個好的用戶故事包括三個要素:
1.角色:誰要使用這個功能。
2.活動:需要完成什麼樣的功能或目標。
3.商業價值:爲什麼需要這個功能，這個功能帶來什麼樣的價值。產品待辦事項：是一列所有需要在迭代中開發的產品特性綜合性清單，它是不斷變化的，以適應客戶需求。隨着項目發展，因爲客戶逐漸理解產品需要更完備，所以待辦事項中的項目特性更明確。
理想時間(Ideal Time) ：代表時間量，即不受會議、個人生活，非工作日或其他拖延，障礙和分心的干擾的情況下，對待辦事項中用戶故事的估算。
時間盒：是管理某個時間被限定的項目的一種方法。只有在規定時間內通過驗收的功能包含在時間盒內。時間盒法約束了 團隊，儘管不是以一種特別消極的方式。它只是規定時間上不能靈活變化，但是範圍可以變化。這種情況下迭代和版本 在進度上都不會靈活。
速率/速度(Velocity)：是指對每一迭代團隊完成的用戶故事點或故事數量的衡量。衡量團隊速度的指標(一輪迭代完成 的故事點數)，用於在迭代計劃中創建項目進度表。一個敏捷團隊可根據稍前的速度記錄來估算下一個迭代可完成的用 戶故事點數量。
故事點：表示開發一個用戶故事的相對工作量。每一個故事點表示一個固定的開發工作量值。當估算敏捷團隊時，必須考 慮複雜度，工作量，風險和依存關係。** 故事點是開發工作的固定單元，用在相對測量用戶故事中，以達到估算參與開 發的工作量的目的。故事點並不以時間爲基礎，而以意義爲基礎。故事點代表成本，價值點代表利益。
信息發射器/信息發射源(Information Radiator ) ：顯示項目進度和狀態的高度可見的圖表和數字項。敏捷項目中，典型的信息發射器包括:看板，項目燃盡圖，任務板，燃起圖、缺陷圖表。信息發射源的對立面是信息冷凍機。信息冷凍機是一種圖表或組件，你必須開發或探索才能理解裏邊的內容。它意味着不透明。** 敏捷團隊和外部干係人溝通的主要方式是信息發射源。
燃盡圖(Burn down chart)：也譯成燃燒圖，是一個常用的來展示迭代進度的信息發射源。它記錄兩項序列:剩餘的實際工作和剩餘的理想/預估的工作。豎軸是工作單元(常是故事點或時間)，橫軸是迭代持續時長(常是日期數 字)。理想/預估的工作序列是條向下傾斜的直線，由需完成工作價值(例如 20 故事點)的豎軸出發，延長至橫軸上 迭代的最後一天(即 0 故事點)。實際工作序列每日更新，取決於敏捷團隊的生產率和任務的複雜性。實際工作序列 常常是易變的，並非直線，它隨着項目團隊干涉開發流程而消長(往往是非線性的，反映開發的起伏)。燃盡圖的作用 是:管理範圍和進程。
考試技巧
- 站在出題者角度判斷其想考什麼?換位思考，獨特的知識點
- US/需求變化 聽 PO 的、進入產品待辦事宜列表排優先級
- 題幹:一年、長期、高管要看 答案:release、產品路線圖、粗略。
- 反敏捷的觀點(敏捷無用、加快迭代速率)，這是思想認識問題。 選項:思想教育、
培訓 - 頻繁的與客戶交流 大概率正確答案
- 題幹:機密、敏感、隱私 選項:安全、合規
- 題幹:人忙不開、技術孤島、人員離職等 選項:跨技術、通才
- 題幹:無活力，原因很可能沒有目標感。 選項:給目標、遠景、使命，不能給錢、
團隊建設。高級人員很消極:挑戰性任務 - 題幹:遇到困難、問題、投訴、BUG、沮喪 選項:先調查、開會、研究原因，然後再
給solution。 錯誤選項:直接給solution，“要求” - 站立會:暴露問題，不討論和解決問題;SM 少說話
- 新產品、新技術、陌生 選項:刺探、探索性測試
- 要求加資源加人、多給錢、縮小範圍、延長工期、加班、請病人幫忙，都是錯的
- 分佈式團隊 選項:VOIP、共享白板、電子看板、VC
- 浪費 選項:精益/價值流
- 變化 選項:分析影響
- 人員交流不便 選項:主張人員集中，團隊駐紮，主張面對面直接交流
- 頻繁交流、交付—頻繁客戶反饋—早發現缺陷—高質量交付
- 不作跨團隊速率比較
- 僅 錯誤選項
- 滿意度 選項:卡諾分析
- 斐波拉切數列 選項:敏捷撲克
- SM 與團隊合作 好於 要求、建議;“與團隊合作”大概率正確
- 說服業務支持敏捷 選項:做一個樣板工程，用成功案例來說話
- 找(讓)行政領導、管理層出面解決問題，得到管理層批准，領導替團隊做了許多決策，
錯誤概率大;但提到與經理合作，正確概率大。自組織商量、腦風暴解決正確概率大 - WBS/甘特圖: 錯誤概率大
- 題幹出現:錢、貴、價值、ROI，選項:選 PO;出現排需求優先級，選 PO;出現“排優
先級”，該選項正確概率較大 - 題幹提到了供應商的問題，答案要出現與供應商相關的解決方案，正確概率大
- 一對一 錯誤概率大
結語
祝大家7A通過考試！
