1. 预测型：各种基准、详细计划、WBS、关键路径、缓冲、储备、进度压缩、资源优化、与干系人定期的状态沟通；

2. 敏捷型：迭代、冲刺、增量、回顾、待办项、DOD、用户故事；

3. 用敏捷还是预测，由项目经理决定，与发起人无关；每个项目都是按项目特点定制的；

4. 敏捷团队强调“团队合作”，某一团队成员无法完成任务，可以在每日站会上提出，而其他成员可以主动帮助、认领其任务；

5. 价值  --题目出现“价值”，优选选择“干系人的期望得到满足”。价值可以是利润，也可以是其他的；

6. 应对不满足时间：敏捷无关键路径，无进度压缩，可以采用

1. 调整范围(产品待办事项)，放弃某些可交付成果以按时交付项目；

2. 调整进度，确保交付所有可交付成果但延长冲刺时间；

3. 调整成本，投入资源；

7. 看板管理的基本原则是“维持较小的在制品（WIP）限制”，即尽量不要同时开展太多工作，能够加快卡片移动，促进持续交付。

8. 敏捷工具：迭代燃尽图，展示剩余工作与剩余任务的关系。

9. 敏捷规划层级：Roadmap（路线图）→发布计划→迭代计划。

10. 敏捷的流程：

1. 更新产品代办列表（用户故事）

2. ① 迭代计划会：迭代目标、迭代计划(2周)、迭代待办列表(Task)

3. ② 每日站会：15min （最好用看板等）

4. ③ 评审会：功能增量

5. ④ 回顾会：每次迭代结束

6. 回顾总结会：每次发布结束

11. 由预测转敏捷的第一个项目，一般采用混合；

12. 推广敏捷方法:首先考虑组织文化问题，其次才是培训；用小的、简单项目尝试；用混合型方法过渡；找第三方机构辅导；

13. 干系人、团队不了解、不熟悉敏捷方法  --培训、指导;

14. 干系人对敏捷有误解、错误看法、错误指令 --说服、指导;

15. 团队不熟悉具体的敏捷工具--一起研究、探讨，进行培训;

16. 提前、尽早、快速完成时，选择顺序是：最小可行性产品(MVP) -- 敏捷增量交付 -- 敏捷方法 -- 进度压缩--动用应急管理储备。

17. MVP是选择重要的进行开发，而不是选择不重要的去掉；

18. 重排待办项优先级(紧迫情况)：①交付时间(进度)需要提前；②预算被削减；③开发团队人员减少；④新需求、变更；

19. 重排待办项优先级的依据：①待办项的商业价值；②开发成本；③待办项的开发技术难度。

20. 产品待办项(PBI)：由产品负责人(PO)负责排序；待办项多默认为产品待办项；

21. 产品的价值决策权再PO手里；

22. 用户故事：用户想要什么？解决什么问题？ 由PO负责，组成产品待办列表；

23. 用户故事点：=复杂度+工作量+风险，用户衡量开发量的单位；具体的故事点数由开发团队估算；

24. 冲刺待办项(用户故事)：每次迭代或冲刺的任务(用户故事)由开发团队选择;

25. 范围变更，或验收不过问下一步:
    1.(由产品负责人)更新产品待办项列表，并进行优先级排序;
    2.与敏捷团队(包括产品负责人)一起了解新需求，分析影响;
    3.找干系人了解新需求、变更;
    4.可以在梳理会议、(下一次)迭代规划会议中讨论、管理该新需求;
    5.纳入下一次发布计划(不是必须，要根据优先级确定)，可以选；纳入下一次迭代，不要选；
    6.产品负责人，项目负责人；敏捷有"变更"，无"变更请求"；

26. 障碍问题包括：a、技术困难,b、外部干扰(干系人问题),c、团队成员之间冲突、团队成员能力不够 (需要培训)等;

27. 仆人式项目经理应帮助清除障碍--管理干系人、解决冲突、指导、辅导、培训等;

28. 很多障碍需要解决时，可以先排优先级；障碍一般不列入待办项列表（偶尔也可以列入）。

29. 最小可行性产品MVP(首次发布) 适用：
    1.交付时间大幅提前;
    2.不确定市场是否接受;
    3.仅知道很少的需求;
    4.急于获得干系人反馈。

30. DOR(就绪的定义)包括: 1.需求足够细化; 2.任务被比较准确地进行了估算; 3.需求具有可衡量的验收标准(DOD)。

31. DOD(完成的定义)概念：1.DOD包括每一个待办项或功能的(质量)验收标准，以及具体的测试案例(测试方法); 2.DOD在冲刺评审过程中进行验证(测试)。

32. 每日站会的原则:
    1.产品负责人不需要参加;
    2.外部相关方可以旁听但不能发言;
    3.会议上可以提出问题、风险，但不在会议上分析、解决问题、风险;
    4.每个团队成员都可以主持会议;
    5.团队成员很多时，可以分几个团队召开。

33. 敏捷自组织团队: ①赋予团队自组织能力，②一视同仁，在清晰、适当的责任水平上保持一致；
    --技术、方法、工具的选择，由团队协商;
    --技术、方法方面的分歧、争议，由团队自行决策;
    在技术、执行、决策方面，项目经理鼓励、支持、推动即可，不要代为决策;
    另:自组织团队不需要领导、不需要过于强势的团队成员。不存在职责和角色分配，由团队自己决定/自己选；
    强调项目经理主导项目时，则团队非自组织团队；

34. 敏捷团队的风险管理：

1. 团队负责识别、管理，写在看板上；

2. 全过程、全生命周期管理风险，团队当家做主；

35. 敏捷项目的进展情况的了解(展示)方式:
    1.信息发射源;  看板信息由团队更新，而非项目经理；
    2.燃尽图;
    3.燃起图;
    4.冲刺评审会。

36. 预算问题：敏捷项目范围不定，没有准确预算；使用增量式预算，与时俱进；使用工料合同；

37. 题目强调"混合型"项目，大都按敏捷项目来理解、找考点;

38. 迭代、冲刺周期一般不能延长，产品待办项一般只添加不删除、不移除;

39. 敏捷团队估算用户故事时遇到困难:可寻求产品负责人(PO)的介入、支持;--用户故事太大，或用户故事大小不---要细分;

40. 当敏捷题目强调功能、需求、商业价值、新功能时:正确答案一般是:产品待办项列表及其优先 级排序。

41. 障碍(问题):--如果很多，可以排优先级;--偶尔也可以列入待办项处理。

42. 看板，卡片，在制品(WIP)：维持较小的在制品(WIP)限制，有利于团队集中力量办大事，推动进展，加快交付;

43. 累积流量图:可以显示正在开发的工作，已经完成的工作，计划开展的工作;可以用来评估项目 状态。(可以当成燃起图)

44. 原型法:干系人可以体验最终产品的模型，而不仅限于讨论抽象的需求描述;主要用于收集需求; 原型法和最小可行性产品(MVP)有一定的共同之处，但目的不同;

45. 按需的进度计划及其扩展：先执行确定的工作，不确定的工作可以先放在代办项列表中;(政策、 技术、范围等存在不确定时)。

46. 情商5要素：①自我认知，②自我管理，③自我激励，④社交意识，⑤关系管理

其他:

一、尽量选择最熟悉的选项:

1.我们最熟悉的选项，大多是PMBOK里出现过的专业术语，正确的可能性最高;
2.陌生词汇，不专业、随意的说法，大多是打酱油的选项，不要选。约有三分之一的选项，是通过 陌生词汇原则排除的;
3.题目会变来变去，但考点就那么多，正确选项，大都是我们在做模拟题时经常选的;
4.使用本套路的前提是做够1000道题目，熟悉PMBOK术语。

二、不要选，可以直接排除的选项:

1.人力资源经理、质量经理、发起人(上报除外);
2.直接更新、修改项目管理计划和三大基准;
3.拒绝变更(内部变更除外)、忽略变更、直接实施变更;
4.(项目经理)暂停、取消、终止项目，以及(项目经理)创建新项目;
5.修改章程、更新章程、修改商业论证;
6.加班;
7.惩罚供应商;
8.下一次、下一阶段再...，一般也不选;
9.公开处理团队冲突不要选--应先私下、非公开处理;
10.敏捷项目中的书面沟通(状态报告、冲刺报告、敏捷报告等)选项不要选;虚拟团队也不 提倡书面报告;
11.让干系人参加每日站会(例会)来了解敏捷项目进展不要选;
12.外部培训、寻求额外资源，一般不选;
13.项目管理、敏捷管理都不提倡(多)层级管理、层级沟通;
14.替换、指责、警告、惩罚团队成员的选项不要选;
15.敏捷项目，(项目经理)不分配任务;
16.障碍、冲突、培训等一般不列入待办项列表;
17.沟通管理计划、干系人参与计划，不展示给外部干系人;
18.干系人问题，沟通问题，质量问题，团队管理问题，都是本不应该出现的问题，因此，质 量、资源、沟通、干系人方面出问题，一般不当风险记录;
19.团队成员的能力、冲突、绩效、遇到障碍、需要培训等问题，是项目经理的责任，不要选 PO、HR、LM;
20.规划、变更、收尾，以及团队、质量、沟通、风险、干系人管理都是项目经理的责任，不 能甩锅给他人，也不上报发起人;
21.沟通问题、冲突问题，一般直接解决，无须记录在问题日志;
22.上报对象应是发起人、管理层、指导委员会，不是职能经理、PMO、产品负责人、技术专 家等。

三、题目中出现可行性问题:

1.即遇到巨大障碍(技术、风险、资源等方面)，答案中找"替代方案"或"解决方案";
2.与团队开会找解决方案，或制定替代性方案来解决问题，在PMP考试中一般很难排除。

四、识别、发现了新技术、更好的方法、工具，更好的方案:

要积极推荐、尝试、研究，要鼓励使用。

五、会议问题:

1.提高会议效率，防止混乱--规则，主持人;
2.开工会议不接受缺席，可以分别召开，可以使用虚拟会议;
3.收集需求的会议尽量让干系人一起参加，如有人没时间，会前收集其需求;
4.团队规模大，可以先开小会再开大会;
5.会议结束后，分发会议纪要。

六、组织变革、推广新系统、推广敏捷方法:

1.应首先考虑组织文化的影响;
2.获得干系人支持;
3.对干系人、团队进行培训、洗脑。

七、凡是题目问"如何避免?"，或"本应怎么做?"，一定是项目经理或项目方犯错了。

如果是干系人没有管理好--未让干系人尽早参与;
如果是沟通问题--没有了解干系人的沟通需求，没有定制化沟通;
如果是变更效果不好--没有严格执行变更流程;
如果是风险发生--没有尽早识别风险;或没有监督应对措施的实施;
范围、质量验收不通过--让干系人尽早参与收集需求、定义范围、创建验收标准。