PMP刷题小结1_pmp技术债务

目录

预测型

第一章 引论

第二章 项目运行环境

第三章 项目经理的角色

第四章 项目整合管理

第五章 项目范围管理

第六章 项目进度管理

第七章 项目成本管理

第八章 项目质量管理

第九章 项目资源管理

第十章 项目沟通管理

第十一章 项目风险管理

第十二章 项目采购管理

第十三章 项目相关方管理

敏捷型

---

预测型

第一章 引论

1.  项目管理的五大过程组：

启动，规划，执行，监控，收尾

2. 项目集管理是通过“特别关注各项目所共享的资源”这个管理措施来关注项目间的依赖关系。

3. 对项目管理进行剪裁，主要是因为项目具有独特性。

4. 项目效益管理计划，包括：目标效益，战略一致性，效益责任人

5. 项目产生独特性结果，运营产生重复性结果。

6. 在前期准备阶段，应编制需求评估，商业论证和效益管理计划。

7. 全球项目管理业界定义的最重要的价值观是：责任，尊重，公正，诚实

8. 工作绩效报告的主要作用：便于制定决策，提出问题，采取行动或引起关注。

第二章 项目运行环境

1. 项目治理涉及4个领域：一致性，风险，绩效，沟通

每个领域都要履行4大职能：监督，控制，整合，决策

2. 组织过程资产，只来自项目执行组织的内部。

第三章 项目经理的角色

略

第四章 项目整合管理

0. 7个过程：

制定项目章程。

制定项目管理计划。

指导与管理项目工作。

管理项目知识。

监控项目工作。

实施整体变更控制。

结束项目或阶段。

1. 指导和管理项目工作过程的工具是，项目管理信息系统。

2. 知识管理的两种关键活动：知识分享，知识集成

知识管理的两个对象：显性知识，隐性知识

3. 实施整体变更控制过程，旨在审查所有变更请求。

对项目计划的变更，只是所有项目变更中的一部分。

4. 将范围，进度和成本基准合并为绩效测量基准。

5. 管理层提出的变更请求需要审批，而不能直接实施。

6. 工作绩效报告，是监控项目工作工程的输出

7. 项目章程记录了项目的退出标准。

8. 配置控制重点关注项目的技术规范。

9. 采购文档包括：招标文件，采购工作说明书，独立成本估算，供方选择标准，包含了用于管理采购过程的最全面的支持性文件。

10. 项目管理计划知道项目进行，监控和收尾，因此，所有执行，监控和收尾过程组中的过程，都要用到项目管理计划或其子计划作为输入。

11. 工作绩效数据，只是原始资料，过于繁杂，不适合直接用于对变更的评审。

12. 在正式启动项目之前，需要确定业务需要，项目总体策略和项目成功标准。

业务需要最先出现在商业论证中，而后写入项目章程中。

项目成功标准是项目章程的内容之一。

13. 合同和项目章程都需要准备。

签订合同确保在法律上合法。

制定项目章程则有利于建立组织内部的合作关系，以确保正确交付合同内容。

14. 需要根据商业论证来决定是否投资项目。

15. 协议是制定项目章程的输入。

有两种主要情况：

一是两个或多个发起组织之间签署合作协议，作为制定项目章程的依据。

二是买卖方的协议（合同），作为卖方制定项目章程的依据。

16. 项目经理可以参与启动过程，但不起领导作用。

项目经理在项目正式启动之后才正式领导项目。

17. 行政收尾包括了财务收尾和法律收尾。

18. 项目经理通常要在项目计划编制开始之前被任命。

第五章 项目范围管理

1. 6个过程组：

规划范围管理

收集需求

定义范围

创建工作分解结构

确认范围

控制范围

2. 系统交互图是对产品范围的图形描述，不是对项目范围的描述。

3. 项目范围说明书用于明确项目的边界，为评审新工作是否超出边界提供基准。

4. 焦点小组技术，可以用来收集同一领域相关方的要求，比如某个部门。

访谈是通过直接与相关方交谈获取需求的技术，通常采用一对一的方式。

问卷和调查是通过发送问卷的方式来了解需求，而不是召开座谈会。

先用焦点小组收集每个部门的需求，再召开引导式研讨会讨论和协调跨部门的需求。

5. 产品分析的目的，是弄清楚产品的范围。

系统工程，价值工程，价值分析，系统分析等，都是产品分析的技术。

6. 产品测量指标和使用这些指标的理由，属于需求管理计划的内容。

7. 范围管理计划的内容，包含：

制定详细项目范围说明书的方法。

正式验收已完成的项目可交付成果的方法。

确定如何审批和维护范围基准。

8. 偏差分析：用于将实际结果和基准进行比较，以确定偏差是否大到需要提出变更请求的程度。

趋势分析：审查项目绩效随时间的变化情况，以判断绩效是正在改善还是正在恶化。

回归分析：用于建立与项目结果有关的不同项目变量之间的统计量化关系。

挣值分析：用于评价偏离初始项目基准的程度。

9. 确认范围过程，是对可交付成果的正式验收，输出的工作绩效信息会写明哪些课交付成果已经被验收，哪些未通过验收以及原因。

10. 控制范围过程输出的工作绩效信息中记录的内容：

对将来范围绩效的预测。

识别的范围偏差和原因。

对照范围基准的有关项目和产品范围实施情况。

11. 解决方案需求：包括功能需求和非功能需求。包括可交付成果必须具备的特性功能等。

业务需求：是组织的高层次需要，表名组织为什么要做某个项目。

相关方需求：表明相关方为什么想要某种产品或服务。

项目需求：是项目需要满足的各类条件。

12. 工作分解结构，是以可交付成果为导向的。工作，指的是作为活动结果的工作产品或可交付成果。

13. 确认范围过程旨在即及时对已完成的可交付成果进行验收，以便确保后续工作都是基于合格的前期成果的。

14. 需求跟踪矩阵，是一份连接需求和需求源，需求和相应可交付成果的文件。

15. 发起人或客户主要通过什么方式完成对可交付成果的可接受性验收：检查和决策。

对照项目计划对可交付成果进行检查，并在必要时运用决策技术来决定可交付成果的可接受性。

核对单：是制定项目管理计划，管理质量和识别风险几个过程使用的工具和技术。

16. 在需求管理计划中确定关于哪些需求属性应该列入需求跟踪矩阵。

17. 需求是项目范围的基础。需求文件是定义范围过程的一个输入。

18. 确认范围过程要对可交付成果开展正式验收，验收产品时要查看质量报告。

19. 项目范围说明书包括：产品范围，验收标准，可交付成果，项目除外责任

补充：

项目进度里程碑：是项目章程的内容之一

项目组织图：是资源管理计划的内容

项目审批要求：是项目章程的内容之一

第六章 项目进度管理

1. 6个过程组：

规划进度管理

定义活动

排列活动顺序

估算活动持续时间

制定进度计划

控制进度

2. 进度管理计划通常包含：

如何制定和维护项目进度模型，如何更新项目进度计划。

估算的准确度，进度计量单位，进度控制临界值

进度绩效测量规划，进度绩效报告格式，进度计划的发布和迭代长度

制定进度计划过程的输出：

实际的详细的 里程碑进度计划，概括性进度计划，详细进度计划

3. 定义活动的结果，是确定实现项目目标必须实施的活动。

4. “在…开始…周前开始”，是开始开始关系。

提前量应该用减号。

5. 硬逻辑关系是绝对不能违反的，如果违反了，会使相关活动无法开展。

6. 在使用节点法编制网络图时，很少用到的逻辑关系：开始到完成 （SF）

这种逻辑关系往往是因为资源的制约造成的，而传统的网络图基本不考虑活动对资源的依赖关系。

7. 排列活动顺序，旨在将项目活动列表转化为项目进度网络图，为编制进度计划和制定进度基准做准备。

8. 参数估算：

三点估算：通过考虑估算中的不确定性和风险，提高持续时间估算的准确性。

专家判断：找专家寻求意见

类比估算：凭经验进行的主观估算，不用统计关系作为依据

9. 关键路径可以有多条。

关键路径越多，项目风险就越大，管理难度就越大。

项目至少有一条关键路径。

10.排列活动顺序过程的输入：活动清单，活动属性，范围基准

排列活动顺序的工具和技术：提前量和滞后量

11. 自由浮动时间：对任何后续活动没有任何影响的时差

总浮动时间：是指一项活动可以延误，但不影响项目完成日期的时间（可能影响后续的某个或多个活动）

项目浮动时间：是指一个项目可以延误而不影响外界要求的项目完工日期。

内部浮动时间：没有这个说法。

12. 资源平衡：资源被过度使用，出现了资源短缺，需要进行资源平衡。

资源平滑：当各个时间段内所需的资源数量起伏太大时，需要做资源平滑。

资源优化：包括资源平衡和资源平滑。

13. 制定进度计划过程，产生进度基准。

14. 敏捷项目中，使用拳五技术进行决策。所有人都伸出三根以上手指，就表示全体达成共识。

15. 敏捷发布规划，是适用于敏捷项目的一种进度计划编制方法。

16. 赶工和快速跟进

17. 定义活动过程，旨在把工作包分解成活动，需要依据WBS，并参考项目范围说明书和WBS词典中的相关信息。这算范围基准，不仅仅是项目范围说明书。

18. 活动属性需要随时间演进，越来越详细。

19. 项目日历：列出可用于开展项目活动的时间段以及不可用于开展项目活动的时间段。

资源日历：记录特定资源的可用时间，不特别针对项目活动。

20. 储备分析可以用于确定项目所需的应急储备和管理储备时间。

21. 活动属性随着项目的进展而不断更新，在项目初始阶段，活动属性包括：活动标识，活动名称，WBS标识。

22. 控制进度过程的输出，是进度预测。

工作绩效报告，是监控项目工作过程的输出，是在工作绩效数据与工作绩效信息的基础上编制，与计划进行比较以后所形成的各种绩效报告。

第七章 项目成本管理

1. 4个过程组：

规划质量管理

估算成本

制定预算

控制成本

2. 成本绩效指数：它表明单位成本所实现的项目价值

3. 质量成本（数据分析技术之一），是估算成本过程的工具与技术。不是输入。

4. 估算成本过程的输入：

工作分解结构（作为范围基准的一部分）

项目进度计划

资源需求

工作分解结构词典（作为范围基准的一部分）

风险登记册

5. 考虑花多少钱做质量管理，是估算成本过程需要使用的质量成本技术，在规划阶段制定成本管理计划时不需要考虑。

6. 在制定成本管理计划的过程中，需要做：

征求成本管理专家的意见

考察不同的项目融资方案

召开成本规划会议

7. 某个时点，成本发生数与资金支出数之差，就是应付未付款（债务）。

8. 项目成本控制的重点是考虑资金支出和所完成工作价值的对应关系。

9. 估算依据中的内容：

估算是如何编制的

对估算区间的说明

关于全部假设条件和已知制约因素的文件

补充：

绩效测量规则属于成本管理计划的内容。

10. 良好的成本管理，是使项目在批准的预算内完工。

成本管理计划中规定允许的成本控制临界值不一定是在正负10%内。

11. 量级估算：很快的，粗略的估算

12. 制定预算过程，需要使用融资技术为项目获取资金。

规划成本管理过程，不开展具体融资活动。

制定项目章程过程，会得到预先批准的财务资源，但不会实际使用融资工具为项目分阶段获取资金。

控制成本过程，是对整个成本管理过程的监控，跟具体使用融资工具无关。

13. 资金限制平衡，是在既定的资金限制下，确保项目各阶段，各部分和整个项目都有足够的资金。

14. 成本偏差，进度偏差（PV, EV, AC）

15. 项目总资金需求，就是项目预算，包含了成本基准+管理储备。

16. 用于挣值分析分3个关键指标：计划价值PV， 挣值EV，实际价值AC。

17. CV, SV 大于0为好。

CPI，SPI大于1为好。

考察：挣值计算

18. 成本预测，是控制成本过程的输出，其实就是项目完工估算EAV。

成本预算，或等于成本基准，或等于项目资金需求，是制定预算过程的输出。

成本基准，是制定预算而非控制成本的输出。

19. 成本管理计划的内容之一，是绩效测量规则，其中最重要的又是挣值管理规则，包括：控制账户，计算挣值的方法，跟踪绩效的方法等。

20. 挣值管理的规则，通常在成本管理计划和进度管理计划中。

21. 三点估算考虑了估算时的不确定性和风险，估算了风险影响下的最乐观，最悲观和最可能三种情况的平均工期。

22. 通常要召开规划会议来编制成本管理计划和其他管理计划。

23. 几种预测项目完工情况的方法：

自下而上的ETC估算：最准确。完工估算等于实际成本价完工尚需估算。由于实际成本是已知的，只要酸楚完工尚需估算即可。由于项目管理团队对ETC进行自下而上估算，最麻烦，但也最准确，因为要开展实际调查。

按预算单价的ETC估算：此方法假设所有剩余工作都将按预算单价完成。

按累计CPI进行的ETC估算：此方法假设项目将按截止目前的绩效水平继续进行。

按关键比率的ETC估算：如果截止目前的成绩绩效和进度绩效都不理想，又须近期完工，则用关键比率来估算。

这3种方法比较方便，但不一定能较好的反映项目后续时期的实际情况。

24. 进度绩效指标，用来评估进度绩效： SPI=EV/PV, 大于1表示进度超前。

25. 成本绩效指标，用来评估成本度绩效，CPI=EV/AC, 大于1表示成本结余。小于1表示超支。

26. 做决策时需要考虑机会成本，但机会成本不是实际会发生的成本，不应计入活动成本估算中。

27. 估算成本时，要考虑下列成本： 人工成本，材料成本，通货膨胀补贴

28. 回归分析，是参数估算方法的典型代表。比如，依据过去项目所表现出来的各因素之间的量化关系，来预测项目成本。

第八章 项目质量管理

1. 3个过程组：

规划质量管理，

管理质量，

控制质量

2. 如何划分工作是属于管理质量，还是控制质量？只需要把控制质量的界定清楚，剩下的就是管理质量。

3. 控制质量里如何纠偏：

成果是否符合质量要求？

有没有按照质量计划去执行？

绩效好不好？

答题时，把题目的情况和上述三个特点相比较，如果都不属于这三个特点，那就是管理质量。

4. 什么是标杆对照？

用于标杆对照的而项目，不局限于本组织或本行业。任何项目，只要与本项目在某个局部科比，就可以作为标杆。

5. 只有经过控制质量过程核实为质量合格的可交付成果，才能交给确认范围过程，由主要相关方进行正式验收。

6. 控制质量过程中召开的回顾会议，不审查已经批准的变更请求是否实施到位，需要单独召开会议审查已批准的变更请求的实施情况。

7. 一致性成本，包括预防成本和评估成本。为避免产品不合格的质量成本，是一致性成本。

非一致性成本，包括内部失败和外部失败。

8. 控制上限和下限：系统正常运行时的变异区间。系统的声音。

规格上限和下限：客户的声音。

9. 在规划质量管理的阶段，考虑使用“测试与规划”这个工具，确定如何测试和检查。

10. 管理质量的常见工作：开展过程改进，重新评估质量标准的合理性，编制质量报告

11. 控制质量的常见工作：检查特定可交付成果的质量。

12. 控制质量应该在整个项目期间开展，以确保达到验收标准。

13. 管理质量的目的：增强相关方对项目将要达到的质量要求的信息。进行过程持续改进，减少非增值活动，提高实现质量目标的可能性。

14. 检查可交付成果的质量是否合格，并对不合格的可交付成果进行纠正，这是控制质量额的工作。

15. 流程图包括一个过程从输入到输出的所有环节，有利于估算该过程的质量成本。

所有的流程图都会显示活动，决策点和处理顺序。

不一定显示每个活动的责任人。

16. 问题解决步骤：

定义问题

分析根本原因

生成可能的解决方案

选择最佳解决方案

执行解决方案

验证解决方案的有效性

17. 针对某个具体可交付成果的缺陷补救建议，属于变更请求，不会逐一写入质量报告。

18 控制质量的相关工作：由项目团队检查可交付成果的完整性，合规性和适用性。

19. 直方图：一种显示各种问题分布情况的柱状图。每根柱子代表一个问题，柱子的高度代表问题出现次数。

帕累托图：一种按问题出现的次数从高到低排列柱子的特殊的直方图。

因果图：为了发现根本原因

散点图：为了找出两个变量间的联系

矩阵图：用于考察各种指标之间相关性强弱

20. 面向X的设计：

旨在优化设计，以控制或提高产品的最终特性

X可以是产品的某种特性，比如可靠性，可用性

这一技术可以提高客户满意程度。

但是，与质量成本的提高或降低没有直接关系。

21. 朱兰：强调的是适合使用，提出质量和等级的区别，提出质量管理三部曲。

克劳斯比：提出零缺陷的概念

戴明：主要贡献包括戴明环，质量管理14条，持续改进，预防胜于检查等

田口玄一：提出质量损失函数，提出稳健设计方案，实验室设计方法

22. 统计抽样的频率不是一种质量测量指标，而是用于检查质量的一种手段。

23. 质量测量指标的例子：

识别的缺陷数量，每月总停机时间

测试覆盖度，故障度

客户满足度分数，每个代码行的错误

24. 关于过程分析

过程分析旨在实现过程的持续改进，把产品做得符合要求与适合使用。

基于过程分析的结果，可以找到需要改进的具体环节。

过程分析是管理质量过程中使用的一种数据分析技术。

需要分析问题，制约因素和非增值活动，制定改进措施。

25. 管理质量过程中的数据分析技术：

备选方案分析

文件分析

过程分析

但是，多标准决策分析，是决策技术，不是数据分析技术。

26. 外部失败成本：为修补问卷调查中外部客户发现的缺陷所需要的成本是外部失败成本。（外部失败成本可能给组织带来的不仅有金钱上的损失，可能还包括信誉损失。）

内部失败成本：在交付客户之前，项目团队识别的缺陷的相关成本才是内部失败成本。

沉没成本：是已经花掉的钱，与成本花在哪方面无关。

27. 质量：符合要求，适合使用

28. 质量管理的目的，是保证项目满足其预定的要求。高质量的产品是符合要求的使用产品，而不是超过要求的优质产品。

29. 测试或产品评估是一种结构化的方法，通过测试直接找出产品存在的质量问题，提供有关被测产品的客观信息。

第九章 项目资源管理

1. 6个过程：

规划资源管理

估算活动资源 （确定完成项目所需的资源种类，数量和特性）

获取资源

建设团队

管理团队

控制资源

2. 管理团队被列入执行过程组。 西方思维，强调管理者不能从外人的角度去监控团队成员，应该作为其中的一员，共同为项目目标努力。

3. 虚拟团队可以临时集中办公。特别需要沟通规划。

4. 合作或解决问题：双赢

妥协：双输

撤退/回避：双输

强制：赢输

5. 团队绩效评价中，评价团队有效性的第一个指标就是个人技能的改进。

个人和团队评估是用来让项目经理了解团队成员的优势和劣势的工具技术，不是项目文件。

工作绩效报告全面综合反映项目的有关情况，但不会记录每个人的技能是否得到了提升和改进。

6. 问题解决：作为控制资源的工具。

应该用结构化方法解决实物资源获取，分配和使用中出现的问题。

7. 平衡式矩阵中，通过召开面对面的团队建设会议，有利于团队建设。这也是临时集中办公的一种形式。

8. 实物资源分配单，记录了项目将使用的材料，设备和用品的详细信息。

资源需求，记录了活动，工作包和整个项目所需的资源的类型和数量，不够详细。

资源日历，规定了在项目期间团队和实物资源何时可用，可用多久。不针对材料。

资源分解结构，是按资源类别和类型，对团队和实物资源的层级列表，不包括其他详细信息。。

9. 资源需求是估算活动资源过程的输出，识别了各个工作包或活动所需的资源类型和数量，并进行汇总。

第十章 项目沟通管理

1. 3个过程：

规划沟通管理

管理沟通

监督沟通

2. 拉式沟通：适用于沟通对象很多，或者要沟通的信息很多的情况。

推式沟通：适用于沟通对象不多的情况，比如发送邮件。

交互式沟通：互动式沟通。比如会谈。

官网属于正式沟通。

3. 规划沟通管理时，需要先确定沟通需求（集中办公，分散办公），再确定收集和发布信息的方法。

4. 解决冲突或批评别人，最好采用非正式的口头沟通。

5. 相关方参与度评估矩阵，通常不用于评估团队成员的参与度，也与工作绩效无关。

6. 工作绩效报告是管理沟通过程的输入，不是监督沟通过程的输入。

7. 口头沟通时，口头语言只能传达全部信息的45%，大约55%的信息是通过非口头语言传达的。

8. 在监督沟通过程中，通过审查相关方参与度评估矩阵中的变化，来确定沟通是否起到了应有的作用。

9. 监督沟通时检查沟通的效率和效果是否达到了沟通管理计划的要求，而不是以监督的名义限制沟通。

10. 沟通管理计划中包括为沟通活动所分配的时间和预算。如果项目需要使用项目管理软件，也要写入沟通管理计划中。

第十一章 项目风险管理

1. 7个过程：

规划风险管理

识别风险

实施定性风险分析

实施定量风险分析

规划风险应对

实施风险应对

监督风险

2. 风险数据质量评估，是实施定性风险分析过程的工具与技术。

3. 风险报告，包括整体风险敞口评估以及风险应对策略，是实施风险应对的重要依据。

4. 次生风险，因应对一个风险而直接导致的另一个风险。

5. 决策树分析是一种风险中立的决策方法，与人们的风险态度无关。

6. 如何计算预期货币价值？

7. 风险：未来可能发生或不发生的事件。注意，是未发生的。

8. 在定性分析风险中，使用风险概率和影响矩阵对风险进行排序。

风险级别矩阵=风险概率和影响矩阵

9. 规划风险应对过程，要考虑风险应对策略带来的效益和策略的实施成本之比。比率越高，代表有效性越高。

10. 风险管理计划中包括风险管理方法论。

识别风险过程指定潜在风险负责人。

实施定性分析过程最终确认风险责任人。

这些都会写入风险登记册。

在规划风险应对过程中制定风险应对措施，并列入风险登记册和风险报告。

风险登记册是识别风险过程的输出，并在后续的风险管理中得到完善。

11. 敏感性分析，必须针对某个具体变量来做分析。

可以是单个项目风险，易变的项目活动或具体的不明确性来源。

不能是整体风险。

12. 数据分析？敏感性分析？龙卷风图？

13. 核对单可用于（不仅限）：

识别风险

控制质量

制定项目管理计划

核对单是吸取已完成的类似项目的经验教训的有效方法，

可以列出以前出现肯恩关于新项目有关的具体单个项目风险。

核对单不是规划风险应对的工具。

14. 未知风险是不能进行主动管理的，需要分配一定的管理储备。

被动接受的风险也是没有主动管理的，可分配应急储备或不采取任何措施。

15. 分享：把应对机会的部分责任分配给有能力的第三方。

开拓：消除积极风险相关的不确定性，确保机会一定出现。

提高：使积极风险发生的因素最大化，提高机会发生的概率。

转移：把威胁造成的影响连同应对责任一起转移给第三方的消极风险应对策略。

16. 概率和影响矩阵：通常由组织来设定概率和影响的各种组合，根据组织的偏好来设定高中低风险级别。

17. 接受策略：可同时用于威胁应对，机会应对，整体项目风险应对。

规避策略：可用于威胁应对，整体项目风险应对

上报策略：可用于威胁应对，机会应对

分享策略：机会应对，整体项目风险应对

18. 识别风险过程中识别出的潜在风险应对措施，记录到风险登记册。

识别风险过程得到的风险报告，包括：

整体项目风险来源，

已识别单个项目风险的概述信息。

19. 多标准决策分析，是用来做备选方案分析的一种具体技术。

从多种标准特征入手，对多个方案进行排序，以选择靠前的方案。

成本效益分析，仅考虑效益成本比。

备选方案分析，不一定会综合考虑多个方案的多种特性。

敏感性分析，用来确定某一个变量单位变化对项目的影响程度。

20. 风险临界值：

是组织能承受风险的程度，低于该值不需要采取措施，高于该值必须采取措施。

21. 风险承受力：

是组织能承受的最大风险。超过该承受力，项目就要终止。

22. 风险偏好：

是组织为实现某个目标而愿意承受的某个风险。

23. 敏感性分析：

是常用的单因素分析，把其他因素固定在一个基准值，分析某因素变化对进度的影响，这样就可以知道哪个因素对进度影响最大，从而重点管理。

24. 根本原因分析:

识别风险的技术之一，属于数据分析技术。

25. 决策树分析：

用于分析备选的方案。

26. 过程分析：

是管理质量的技术，用于识别过程改进的机会。

27. 弹回计划：

在主要应对措施不起作用时启用。知识备用的应急计划，不是首选的。

28. SWOT分析？

29. 风险识别活动的参与者：应该鼓励全体项目相关方。

30. 概率分支图：与活动无关的风险以及其他不确定性来源。

概率分布图：单个项目风险。常见的有：三角分布，正态分布，均匀分布。

龙卷风图：敏感性分析的结果的图形展示方式。

31. 蒙特卡洛模拟得到了项目成本的S曲线图，会显示成本的不确定区间，实现特定成本目标的概率。

32.低风险区域内的风险对项目影响不大，可以不做定量风险分析，直接开始规划风险应对过程。

33. 提示清单：比如使用风险分析结构的底层要素，使用PESTLE等战略分析框架，为团队识别风险提供出发点和框架。

第十二章 项目采购管理

1. 3个过程：

规划采购管理

实施采购

控制采购

2. 实施采购和控制采购，都需要采购文档作为输入。

采购文档包括：招标文件，采购工作说明书等

采购管理计划不是项目文件。

3. 索赔的本质是要求赔偿损失，不带任何惩罚性质。

谈判是解决索赔和争议的首选办法。

一般，买方向卖方索赔比较容易。

4. 作为控制采购的输入，批准的变更请求包括：根据新发布的法规，对合同可交付成果的质量标准的修改。

5. 在多供应商合作的项目中，项目团队应该注意某个卖方提出的变更对其他卖方造成的影响。

6. 项目经理应该参加投标人会议，以便提供必要的协助。

7. 买方应该尽力保证每个潜在卖方（参会者）都在投标人会议上得到相同的信息。

8. 采购管理计划，记录了：项目是需要开展国际性招标，还是仅从当地招标。

采购策略，是对采购管理就好的内容的细化，包括支付方法，合同类型和采购阶段三方面内容，不包括如何采购的决策。

招标文件在发布之前，就已经确定了如何招标的方案。

采购工作说明书，是对即将外包出去的工作的书面描述，不包括如何采购的决策。

9. 国内的法规和技术规范变化，是境外承包商无法掌控的风险，我方作为买方必须承担该风险。

10.不需要发起人正式验收单次采购，通常由授权的采购管理员对采购进行验收，并发出合同已经完成的正式书面通知。

11. 成本补偿合同，实报实销，卖方绝不会亏本。

也由于成本实报实销，卖方没有积极性控制成本。

买方而言，项目是成本中心，不是利润中心，无所谓亏本与否。

12. 合同包括：对费用和保留金的规定，规定是否允许分包以及应如何批准分包商，明确合同变更的流程。可能指定几个重要岗位的人员，不会规定全部人员的名单。

13. 控制采购过程的输出工作绩效信息，包含合同的履约情况，可以从中发现当前问题或潜在问题，支持后续索赔。

14. 在规划阶段制订功放选择标准，主要目的是：确保选出能提供最佳所需服务的卖方建议书。

15. 卖方绩效评估文件，由买方编制，记录卖方继续履行合同的能力，不可能作为卖方想买方索赔的证据。该文件通常不会发给卖方，甚至对卖方保密。

卖方绩效评估文件：可以未做提前终止合同，罚款，或支付合同金额和奖金的依据。可以根据卖方绩效评估的结果，把卖方假如合格卖方清单。可以用来决定是否允许卖方承接未来的项目工作等。

16. 都可称为协议：合同，订购单，谅解备忘录。

要约：称为发盘或报价。是一方当事人向另一方当事人所做的，邀请订立合同的意向。要约不是协议，只是单方面的行为。

17. 成本加激励费用的算法？

18. 工料合同适用的情况？

19. 总价加激励费用合同，会规定一个最高限价，付款总数不得超过最高限价。

工料合同适用于规模小，工期短，不复杂的工作。

成本补偿类合同，买方的成本风险最大，因为买方对卖方的成本要实报实销。

固定总结合同的前提是范围固定，如果范围变化，则允许调整价格。

20. 控制采购过程的数据分析技术：

绩效审查：通过对照协议来审查合同工作的绩效。

挣值分析：通过计算进度和成本偏差，以确定偏离目标的程度。

趋势分析：用于计算项目的完工估算EAC，以确定绩效是正在改善还是正在恶化。

补充（不属于控制采购过程的数据分析技术）

决策树分析：旨在从若干备选行动方案中选择一个最佳方案，是实施定量风险分析过程的数据分析技术。

21. 在合同约定中，按项目输出以及可交付成果来付款，可以更有效的开展采购控制。

22. 由于时间紧迫，相关方希望简化所需步骤，此时可以从组织预先蒲准的卖方清单中选择。因为这清单上的供应商，已经提前经过了组织的审查，可以简化一些采购步骤。

23. 通过绩效审查，确定卖方的工作绩效是否令买方满意，以便决定该卖方是否有能力承接以后类似的工作。

（检查只针对本合同，不涉及后续）

24. 小型采购，不值得过多计较，直接选择具有所要求的资质的卖方。

25. 招标文件要求足够详细，而非非常详细。能让卖方做出一致且恰当的应答。

26. 谈判应该由采购团队中有签合同权力的人主导。

项目经理和其他团队成员可以参与并提供帮助。

27. 谈判策略：

最后期限：设定一个达成协议的最后期限。

既成事实：坚持某个问题已有既定的解决方案，不需要再讨论。

红脸白脸：参与谈判的成员中，一个唱红脸，一个唱白脸，与对方周旋。

权力有限策略：声称自己无权对某些问题做出决定，需要向领导请示。

28. 对于索赔和争议的处理，最好的顺序：

先谈判

谈判无效，则尝试替代争议决定ADR方法（调解仲裁）

最后是诉讼

29. 采购工作说明书包括：履约期限，性能参数，工作地点

应答格式要求不在采购工作说明书中，是招标文件的内容。。

第十三章 项目相关方管理

1. 4个过程：

识别相关方

规划相关方参与

管理相关方参与

监督相关方参与

2. 某相关方退出，是一种普遍的项目风险。

要先把他从相关方登记册中去掉（更新），再评估退出造成的影响。

3. 凸显模型是根据相关方的权利，紧迫性和合法性这几个方面，对相关方进行分类。

权利：职权级别或对项目成果的影响能力

紧迫性：主要立即关注

合法性：有合法资质对项目施加影响

4. 管理相关方参与过程，是直接与相关方打交道的过程。该过程最能直接提高相关方对项目的支持，降低相关方对项目的抵制。

5.相关方的参与程度：

不了解型：根本不了解项目，对项目无任何参与

抵制型：了解项目，但抵触项目

支持型：了解并支持项目，但不一定很积极

领导型：了解项目，并积极促进项目成功

6. 在凸显模型中，可以用邻近性取代合法性，用以考察相关方与项目的关系密切程度。

7. 相关方参与度里，没有参与度这个维度。

8. 管理相关方参与，需要在整个项目生命周期内与相关方持续沟通和协作。相关方应该在整个项目生命周期中参与项目工作。

9. 相关方登记册中包含：

相关方身份信息，评估信息，相关方分类。

10.效益管理计划中可能指出将从项目成果交付中获益的相关方。

11. 头脑写作是头脑风暴的改良法，是识别相关方过程的工具和技术。大家围成一圈，每个人单独思考，将识别出的相关方写在A4白纸上，再传递给下一个人，一轮接一轮书写和传递纸张，知道每张纸都传回最初发出者那里。

名义小组是结构化的头脑风暴法。

通常的头脑风暴，是大家口头发言，主持人实时公开记录在白板上，然后再讨论。

12. 识别相关方时，需要进行相关方分析，需要考虑相关方的这些信息：

权利：合法权利，道德权利

贡献：相关方对项目做出的贡献

所有权：相关方资产或财产的法定所有权

13. 数据分析，是监督相关方参与过程的工具和技术，其中包括相关方分析，用于确定相关方在项目某个使其的实际参与情况。

专家判断，是识别相关方，规划相关方参与，管理相关方参与这3个过程的工具和技术。

基本规则，是管理相关方参与过程的工具和技术。

数据收集，是识别相关方，规划相关方参与这2个过程的工具和技术。

14. 识别相关方：全面识别项目相关方，并对他们进行分析

规划相关方参与：通过使用相关方参与度评估矩阵，发现相关方当前参与程度和所需参与程度的差距，再策划该如何提升相关方的参与程度。

管理相关方参与：根据相关方参与计划，实实在在地和相关方打交道，引导相关方积极主动参与项目工作，支持项目。

监督相关方参与：监控项目团队和其他相关方之间的关系，以及其他相关方相互之间的关系，提出变更请求。

15. 相关方参与度评估矩阵，用于直观的陈列当前参与程度与所需参与程度。

16. 根据相关方对项目的影响方向，分为：

向上：通常把高级管理成归为向上。

向下：团队成员或临时为项目贡献知识或技能的专家，归为向下。

向外：项目团队外的相关方群体或代表，归为向外。

横向：把项目经理的同级人员归为横向。

17. 相关方立方体：采用三维模型来呈现相关方的信息。三维包括权力，影响和作用。

凸显模型：按权力，紧迫性和合法性三个维度对相关方进行分类。

影响方向：按相关方对项目团队本身的影响方向进行分类，不是三维模型呈现的。

18. 思维导图，用图形可视化表现相关方之间的联系。

权利利益方格，是对相关方按权力和利益进行分类的结构化工具，不能表现相关方之间的关系。

相关方参与度矩阵和相关方立方体，都不能表现相关方之间的关系。

敏捷型

1.  四个敏捷宣言价值观：

个体和交互胜过过程和工具。

工作团建胜过全面文档。

客户合作胜过合同谈判。

响应变化胜过遵循计划。

2. Scrum宣言，是团队在执行工作中所必须遵守的，应该记录在Scrum团队心中。

3. 在XP框架中，“同步”最好的描述了分析师，设计，开发和测试活动的关系。

4. 在敏捷中，团队都是自组织的，所以没有管理层。

5. 燃烧图展示的是团队未来还剩下多少工作没有完成。

6. XP（极限编程）的3个核心价值：简单，沟通，反馈。

7. 看板开发的5核心原则：

可视化工作流，管理六，流程原则明确，改善协作

8. 如果工作是时间盒，这就意味着分配了一个最大的持续时间。这就确保团队花费合理的而时间在工作上，没有浪费。

9. 在敏捷中，任务板是帮助敏捷团队理解完成用户故事的可能工作量。

10. IRR，内部返回率。返回率越高越好？

11. 当开发团队确定在一个迭代中无法达成承诺时，由产品负责人和开发团队来评审和调整所选择的迭代工作。

12. 项目章程中包括：

目标说明，用户和客户的收益，要点，技术上的考虑，概要的问题和风险，干系人，主要里程碑，团队成员。

13. 商业论证主要是为了证明这个项目是可行的，能给组织带来收益，所以有助于项目获得批准。

14. 在敏捷方法中，术语MoSCoW和“优先级1，优先级2，优先级3”形成优先级，用于将用户故事进行优先级的排序。

15. 客户或商业代表参与到工作的优先级划分中，主要的收益：能更好的响应业务需求和项目。

16. 迭代0（项目最早期的那部分）比较关注建立工具，环境和提供方法。

风险燃烧图很好的限制了团队目前的工作。

虽然业务功能不能达到峰值，但是团队也希望减少技术风险。

17. 产品路线图：显示了发布日期和概述的发布内容。可以向发起人澄清产品什么时候发布和发布包含了哪些内容。

产品演示：主要是给发起人展示已经构建好的产品。

产品所有者：指的是人。

18. 为了理解产品需求，团队制作了一些代表用户的任务介绍。每一个任务介绍包括姓名，工作title和使用产品的目的。这是创建虚拟人物。

19. 用户故事的特性，包括了角色，功能，收益。

20. 线圈图，虚拟人物，用户故事，都是为了理解干系人的目标。

当我们试图更好的理解干系人的特征以及总体需要时，比较适合虚拟人物。

21. INVEST：

independent

negotiable

valuable

estimable

small

testable

22. 线框图被用于确认设计，没有测试设计或配置报告那么详细。

23. 速率是一种多维度的度量，提供了团队能力。但不用于定义需求。

比如可用于：评估团队的工作能力，检查发布计划的有效性，在每个迭代中识别完成的工作。

24. 需求从大到小的层级：特性，用户故事，任务

25. 理想日和故事点，用于敏捷估算中。

26. 打扰 是能在软件开发中引起理想时间的变动和流失时间。

27. 敏捷估算中最普遍的技术：专家观点，类比，分解

28. 故事点，单纯地度量用户故事的大小。

29. 选择迭代的长度，应该通过这些因素来指导：

不确定的数量

很容易得到反馈

保证不变的优先级的长短

30. 什么是理想日

31. 在敏捷项目中，知识共享是许多实践中的核心。

32. 在敏捷项目中，流程剪裁最好是在实施敏捷实践很困难的时候来做。

33. 在敏捷方法中，信息交换被设计为，协助知识的共享。

34. 团队驻扎指的是团队在一起共同办公，有助于团队的团结。是展示合作的前提。

35. 用户无需参加技术类型的会议。

36. 每日立会的一个议题就是遇到的困难障碍是什么。

37. 个人指导更适合在迭代工作。

38. 情商，指的是某个人天生对于环境的反应能力，以有意识的决定要做什么。

39. 自组织团队最明显的特点是，当时作出决策。

40. 让团队解决冲突，不是推荐的一对一的教练方式。

41. 高效团队的特征：建设性的意见，授权，自组织，拥有共识

42. 头脑风暴技术，包括：安静的协作，循环方法，无限制方法

43. 敏捷团队中，客户和程序员的共鸣，程序员和测试员的共鸣，有助于增强团队信任。

44. 技术债务，是由团队为了短期的项目利益故意做了欠佳的技术决策而导致的。

真正的技术债务，是团队为了获得短期利益故意做了会导致长远债务的决策。

45. 重构：对软件内部结构的一种调整，目的是在不改变“软件之可察行为”前提下，提高其可理解性，降低其修改成本。

46. 产品最好的反馈，就是来自市场的反馈。

47. 持续集成引擎的角色：

每次交付的时候运行构建。

发送电子邮件以通知团队测试结果。

执行自动化的单元和验收测试。

48. 为了有效的重构，需要代码共有。

49. 持续集成要求的是有任何的新代码被check in进来，就需要被集成进来。

为了获得持续集成的收益，团队必须在什么时间集成他们的代码：测试员记录的缺陷总.

???

50. 在敏捷开发环境中，度量产品质量，以帮助通过客户验收通过的数量。

51. 溜走的缺陷，用于质量保证和控制过程中措施的缺陷。

52. 在敏捷项目中，周期时间指的是从刚开始到完成工作所花费的时间。

53. 快速失败，指的是在生命周期的早期遇到一个无法解决的障碍。

54. EVM，挣值管理，是根据成本和计划用于评估项目绩效的管理技巧。

BAC 完成预算

AC 实际成本

PV 计划价值

EV 获得价值

CV 成本变化

SV 计划变化

CPI成本绩效指数

SPI 计划绩效指数

55. 控制界限，是指可视化的控制以展示可接受的范围。控制界限是可视的，展示的是可接受的范围，它们并不管理流程，改进估算，或者升级问题。

56. 产品负责人PO，是客户的一个代言人，可以自己决定停止开发。既然某部件对用户不重要，那就可以停止。

57. 价值流分析聚焦于发现工作中的浪费，提高增值活动的比例，做到持续改进。

鼓励团队开展活动有助于提升团队士气，自行找到解决方法。

58. 探针Spike， 又称探测故事。

主要用于对一项技术风险比较大的工作单独安排一个用户故事或任务，进行预研工作，了解其可行性，探针故事的目的不是要实现该特性。

比如在迭代中的商业要求模糊或者不明确的时候。

59. 独立工作的小组在敏捷中不建议竞争，鼓励沟通协助去完成工作。

分享进展情况，并使用减少孤岛思维区域的方法。

60. 多项目对资源的占用，属于风险应对。

比如一个员工被几个团队分配了任务，这时候需要将问题添加到风险清单，一起探讨解决。

61. 每一次迭代都是按照优先级进行排序的，要想知道某个功能是否包含在下一次迭代中，就看一下优先级排序。

62. 产品演示会议，review meeting, 是在开发团队完成产品功能阶段性开发之后，邀请干系人或客户参与的产品功能展示会议，在此会议上并不需要估算开发所需的时长。

该会议的作用：了解功能的可用性，了解功能是否合适，了解新的需求。

63. 敏捷强调每次迭代都能产生可工作的产品，使用可工作的软件产品来衡量和管理进度。

敏捷的核心概念：可工作的解决方案是看到工作进展最准确的方式。

64. scrum主管职责就是负责移除障碍，下一次站会上解决有点儿晚，应该及时沟通处理。

65. 信息看板展示sprint状态。

66. 燃尽图，体现了已完成工作与迭代计划的比较，可以反应工作的进展情况，体现已经完成工作的累积情况，完成工作的走势以及后续工作的期望。

67. 回顾会议的主要任务是对上一次迭代期间的过程回顾，在下一次迭代器保留做的好的地方，改进做的不好的地方。

68. 一项任务所花费的时间比原始估算的时间长，很可能是将用户故事拆分成任务时，该任务规模太大，所以可以将任务分成多个部分，拆分后，可以被其他成员进行领取。

69. 对于增加的额外的工作量是否增加了产品价值，只有产品负责人最有发言权，所以这种变更需要经过产品负责人的批准，再决定是否继续。

70. 敏捷宣言中的简洁，包括减少不必要的产品特性，不必要的设计，不必要会议等阻碍产品快速发布的工作。

71. 为变更预留缓冲可以有效的降低计划与实际的偏差。

72. 敏捷需要干系人具有直接沟通和互动的理念。敏捷专业管理师有责任传播敏捷理念给干系人。

73. 敏捷教练要避免微观管理。

74. 速率不是用来评价过去是否完成承诺的，而是用来更好的为未来做预测。

敏捷不强调评价个人绩效，鼓励团队协作，从团队的角度完成工作。

75. 故事点数，指的是一个用户故事的相对大小。

76. 敏捷项目团队完成初始计划和蓝图后，需要：跟踪迭代，并根据需要重新规划。

77. 管理层应该如何识别需要应用其他资源中减轻潜在影响的领域：让每个开发团队在信息看板（information radiation）上等级最高风险项。

将风险通过看板形式反映出来，以便进行风险识别与减轻。

78. 在产品发布前，项目团队应已完成：开展阶段结束演示。

通过评审会对产品进行演示，得到产品负责人对产品的确认。

79. 燃尽图能展示实际情况与参考情况，满足需要。

80. 看板：可以提现迭代的进展情况。

Moscow分析法：排优先级的

计划扑克技术：评估的

81. 看板需要限制在制品数量，以快速交付产品。

​​​​​​​82. 每个迭代产出应该是可用的产品功能，这些功能可以交付，但是不一定交付。

因此，是潜在的可交付产品增量。

83. 结对编程的过程中，可以由资深的工程师带领经验不足的工程师一同工作，快速提高团队整体水平。

84. 信息看板，即信息发射源。将项目信息透明化，醒目，方便项目相关人都能了解到项目进展。

​​​​​​​85. 敏捷故事是基于一个有纪律性的迭代进度计划，这些迭代进度逐渐提高可预测性，同时适应变更。

86. 计划扑克，是敏捷估算故事规模的常用技术。

87. 价值映射图是将项目可视化，找出整个流程中哪些节点是增值活动，哪些节点是非增值活动，以最大限度的消除浪费。

88. 减少对程序员的干扰，是提高速度的最佳方法。

89. 项目章程是重要的管理文件，需要所有干系人的参与。

虽然专家建议章程应该不超过一页，单因为所有的干系人必须参与进来并且达成一致意见，所以创建项目章程是非常具有挑战性的。

项目章程包含3个关键信息：前景，任务和成功标准。

90. 产品代办事项，是一列所有需要在迭代中开发的产品特性综合性清单，它不断变化，以适应客户需求。随着项目发展，因为客户逐渐理解产品需要更完备，所以待办事项中的项目特性更明确。

91. 敏捷项目管理着重强调持续完善。从迭代后客户提供反馈，到迭代后团队保留时间回顾和反思执行情况，持续完善已经进入敏捷方法论中。

进行的单元，一体化测试和适应技术，工业开发三者是持续完善中的一部分。

持续完善也是精益方法论的一个重点原则，注重从价值流中消除浪费。

92. 持续集成的xp（极限编程）的原则，是代码建立后，即集成到完整代码库。

由此集成后，代码库和整个系统即建成和测试完成。

持续集成只是提高快速软件交付和集成缺陷早期探测的一个极限编程的原则。

持续集成理论上，是指随时有可发布的工作产品。

93. 如何估算用户故事规模：故事点，理想时间

理想时间代表时间量，即不受会议，个人工作，非工作日或其他拖延，障碍和分心的干扰的情况下，相对于代办事项中其他用户故事，单独个人建立，测试发布用户故事所花的时间。

94. 估算敏捷项目，常用类比估算，属于自上而下的估算。

敏捷不推荐在事先做非常详细的估算，鼓励适当的估算精确度，尽早开始探索实际工作。

95. 基于价值的分析，致力于了解用户定义的价值与产品中的不同部分，如特性和任务之间的关系是如何的。

特性通常以基于价值和风险的优先级得到优先处理。

通过风险-价值指标，成本-价值指标，使用MoSCow或Kano方法可执行优先级，这也是两个处理产品优先级的常用方法。

MoSCow：将产品特性分为：必须含有，应该含有，可以含有，会含有这4类。

kano：将产品怒特性分为：必须含有（开端）， 不满足因素（是指反过来影响感知价值而应该移除的特性），满足因素（是指此类因素越多客户越满意，能够正相关地增加感知价值的特性，但并不是必需的），愉悦因素（是指指数型的增加感知价值来满足客户的特性，依据风险来优先处理特性）。

敏捷团队往往在相对价值和风险方面优先处理需求或用户故事，特性。价值由客户决定（客户-价值优先级）。

96. 敏捷工作尝试将WIP减少至可管理和可持续的水平。与精益相似。

97. 故事点代表成本。能被看作开发一个用户故事的成本。

价值点代表收益。能看作开发用户故事的收益。

98. 价值，成本，风险，是优先处理用户故事时考虑的重点因素。

价值高，成本低，风险高的故事需要优先考虑。

99. 用于定义用户故事的罗恩杰弗里斯的3C，是指：卡片，对话和确认。

100. INVES

independent: 独立故事，是指在任何顺序下开发，避免依赖，使开发更难过复杂的故事。

negotiable: 可协商故事，是指客户和开发者可自由分析和采用用户故事来达到客户需求的故事。

valueable: 有价值的故事，是指客户描述产品特性如何提供价值的故事

estimable: 可估算故事，是指已准备就绪，开发者可用来估算开发这些用户所需的工作量或市场的故事

small: 小故事，是指需要2-5天执行的故事

testable: 可测试故事，是指根据接受标准可验证，来确保价值的故事。

101. 透明化沟通，支持对项目成功或失败开放诚实的品质。

102. WIP，是指材料或部分已开始生产单还未完成的产品，是正在进行中的工作。

103. 敏捷团队在预测过程中使用的速度，是指：每个迭代完成的用户故事点活故事数量。

104. 可提高团队动力的简单步骤：

共度黄金时间。团队成员可在个人层面上了解他人以此营造社区氛围。

提供反馈，指导和训练。赞扬和感谢团队成员的出色工作，同时为技能和能力提升提供指导和训练。

授权，授权团队成员做关键决策，在此期间，建立信任并显示领导对团队能力的信任。

105. 有效沟通是敏捷的基石。

沟通计划

信息分布

绩效报告

管理项目干系人

106. 一个健全的站立会议的重点特征：

同辈压力

密切的配合

专注

每日承诺

辨别障碍

107. 累积流量图：和燃起图类似，是信息发射源。

它可以跟踪敏捷项目的流程。

跟传统的燃起图不同，因为它可以整个待办事项的总范围（不是开始，结束）。

跟踪的项目可以是特征，故事，任务或使用案列。

通过跟踪总范围，累积流量可以传达绝对进度，并提供项目进度的百分比。

108. 部分完成故事的故事点，不包括在速度指标里。要全部完成的才算。

109. 在敏捷设计流程中，原型有助于客户了解当前设计状态。

3种常见的原型，是HTML，书面（概述），线框。

线框：是用户界面的概述，确认它的内容，设计和设计功能，常师黑白色，剔除细节性的图片和图像。

线框可在纸上，白板上或者软件上创作。

110. Shu Ha Ri：守，破，离。

代表遵守规则，打破规则，创建规则。

111. 解聚：将故事进行拆分。

解聚和分解的区别在于解决的结果仍然是完整的故事，而分解是把故事拆分成了任务，每个任务不再能够独立实现某个特性。

112. 只有燃起图才能查看所有已完成故事的总点数。