- 1设计模式-组合模式_组合设计模式菜鸟
- 2Windows系统安装onlyoffice_windows安装only office
- 3Flask项目快速部署_flask部署到服务器
- 4深入理解Linux内核-磁盘IO-I/0体系结构和设备驱动程序
- 5Win10内置Ubuntu重启Docker服务_win10重启docker服务
- 6拜占庭容错共识（PBFT）
- 7数智赋能内涝治理，四信城市排水防涝解决方案保障城市安全运行
- 8Github authenticator登录问题_github-recovery-codes
- 9深入学习Java：关于List下标越界源码分析_removeall 避免数组下标越界
- 10编写测试用例标准_测试用例设计要求连贯性
PMP刷题小结2_分析进度灵活性最小的活动排序
赞
踩
目录
【预测型】
1. 项目章程是授权项目经理动用活动资源的文件。由发起人或管理层批准。
2. 开始项目，发现预算不足，先澄清范围，如果范围没问题，再进行风险分析。
3. 要求提前完工，对于规划过程来说，可以当成风险来对待开展识别风险工作。
4. 经验教训总结，是在项目的收尾和结束的工作。
5. 项目收尾的最后工作：解散项目团队
6. 客户已经接受该项目，就可以开始项目收尾。
7. 注意区分题目问的是事前预防，还是事后行为。
8. 行政收尾完成，表示项目已正式结束。
9. 项目在什么时候被考虑结束：项目档案已完成。这是最后的工作。
客户接受产品，经验教训总结在此之前。
10. 项目收尾包含产品收尾和行政收尾。
在获得项目可交付成果的最终验收时，为存进项目收尾，项目经理应该立即执行：
将可交付成果的所有权转移到任命的相关方（客户或发起人）。这是产品收尾。
行政收尾：与团队总结经验教训，通过收集客户对项目的反馈衡量客户满意度，为项目文件和资料存档，保留组织知识。
11. 经验教训文件：问题与风险信息，适用于未来项目的有效技术的信息
12. 注意题目问的是过程，还是工具，或者资料
13. 项目整体管理需要将项目可交付成果与执行组织的日常工作整合。
但不包括具体的项目工作与执行组织日常运作的整合。
14. 基准，是批准的计划，用来作为比较的依据。
如果基准已经过时，那么数据也就失实，比较也有失去意义。
当需要用目前真实而不是过时的数据来测量实际绩效时，就需要更新基准。
15. 对于可交付成果变更的跟踪审批，主要是通过整体变更控制过程进行处理的。
16. WBS最底层是工作包，确保只有一个人负责。
17. WBS的作用：改进估算的准确程度，定义项目绩效的基线，而且有助于职责分配。
18. 当信息足够时，利用滚动式规划的工具，对于规划报的分解进行渐进明细。
19. 工作包的详细程度，因项目大小与复杂程度而已。
20. 确认范围时，应该怎么做（工具）：检查
21. 关于WBS，不同的可交付成果可以有不同的分解层次。
22. WBS 100%原则，WBS包含了全部的产品和项目工作，当有新的可交付成果时，WBS需要更新。
23. WBS的典型用途：组织和定义项目的所有范围
24. 新项目和旧项目的范围类似，可利用旧项目的WBS作为模板。参考组织过程资产的历史信息。
25. 分解WBS的有效方式：按项目阶段或项目可交付成果
分解，就是把项目可交付成果分成较小的，便于管理的组成部分，直到工作和可交付成果定义到工作包水平。
26. 在进入最后阶段之前，应该重点关注可交付成果的验收，即确认范围。
27. 确认范围的重要依据（输入）：核实的可交付成果
28. 确认范围属于监控过程组，需要贯穿整个项目生命周期。
29. 确认范围的一项重要特点：
与质量控制的不同之处在于，确认范围关心工作结果的验收而非纠正。
控制质量在于确定可交付成果的正确性，以及是否满足质量要求。
30. 类比估算：本质上而不是表面上类似
自下而上估算：从下到上，逐层汇总估算的方法
三点估算：考虑估算中的不确定性和风险，提高持续时间估算的准确性
专家判断：找专家寻求意见
31. 活动持续时间估算，应该由项目团队中最熟悉具体活动的人来进行。
32. “在…开始…周前开始”，是开始开始关系。提前量应该用减法。
33. 定义活动，对活动排序绘制网络图，估算活动持续时间，制定进度计划
34. 资源优化：资源平衡，资源平滑
资源平衡：资源被过度分配，出现了资源短缺
资源平滑：当各个时间段内所需的而资源数量起伏太大时
35. 自由浮动时间的计算
36. 当项目进度估算不充分，项目经理首先要收集信息，分析并评估这些数据，以分析进度的估算和满足项目要求。跟进分析结果，决定是否需要提出变更，以确保项目进度与范围一一对应。
37. 总时差为负，说明进度已经延期，需要进度压缩。赶工。
38. 进度控制，应该重点关注关键路径上的活动。
39. 项目进度延迟时，要积极采取主动的方法。
依据项目进度管理计划可能的应对措施，以确保项目按时完成。
40. 赶工会导致风险，要关注风险。
41. 进度计划（第六章：项目进度管理）：
（1）里程碑图 /里程碑进度计划：
描述可交付成果的状态（完成多少），代表工作的关键节点，用来向高层汇报。
（2）横道图 /概括性进度计划：
描述活动的进度状态，即项目的进度状态，描述具体工作的完成百分比，也用来向高层/管理层汇报。
（3）进度网路图 /详细进度计划：
描述所有活动之间的逻辑关系，是项目团队具体使用执行的。
注：甘特图（横道图？）表示时间，不表示逻辑关系。网络图表示逻辑关系，不表示时间。
42. 每个任务有一天的时差，任务1和2按进度完成了，说明么有动用时差，后续任务的时差还是1天。
43. （1）紧前关系绘图法，也叫节点法，前导图法，单代号法AON。
（2）4种逻辑关系
完成-开始：FS，紧前活动完成之后，紧后活动才能开始。
开始-开始：SS，紧前活动开始之后，紧后活动才能开始。
开始-完成：SF，紧前活动开始之后，紧后活动才能完成。
完成-完成：FF，紧前活动完成之后，紧后活动才能完成。
（3）活动之间的逻辑关系 16字箴言：
左为开始
右为结束
箭指紧后
反向紧前
！！！这里的左右，指的是线跟方框的连接点是在方框的左边还是右边。
44. 进度计划制定好之后，应该先获得批准，成为进度基准。（而不是先开始资源规划）
45. 涉及到资源冲突时，关键路径法相关的办法，最无效。因为关键路径不考虑资源制约。
46. 分解可用于创建WBS, 也可用于定义活动的技术。
分解在定义活动中的作用：最终输出被描述为活动或行动步骤。
47. 规划会议：用来编制成本管理计划，和其他管理计划
48. 哪种预测项目完工情况的方法最准确：自下而上的ETC估算
完工估算：等于实际成本+完工尚需估算
项目管理团队对ETC进行自下而上估算，最麻烦，但也最准确，因为要开展实际调查。
49. SPI=EV/PV，进度绩效指标，大于1，表示进度超前。
CPI=EV/AC，成本绩效指标，大于1，表示成本结余。考量资源利用率，即成本是否一致。
SV=EV-PV：进度偏差
50. 回归分析，是参数估算方法的典型代表。
51. 估算成本，除了要考虑与项目相关的所有WBS成本之外，还要根据已识别风险等级册的风险分配项目的时间和成本的应急储备。即，利用储备分析的工具，考虑估算的完整性和准确性。
52. 挣值EV：到目前为止所执行工作的价值。即，反映的是已完成工作的计划价值。
53. 项目进度和成本可以，在失去资源的前提下，要确保项目目标不变，则需要进行风险分析和影响评估，用偏差分析的方法分析可能的偏差和应对措施。
54. 项目在进度和成本都符合预期的情况下完成，此时，EV=PV=BAC
55. SV=EV-PV，但进度落后，说明该做的活动（关键活动）没有做，不该做的活动（非关键活动）做了。
因此，进度偏差需要与关键路径发+风险管理一起使用。
56. 项目成本分类，包括直接成本+间接成本。
如果某成本由多个项目共同分摊，则属于间接费用。
软件更新淘汰，会折旧减值。
57. 量级估算：用于项目刚开始时。
58. 项目经理时项目的唯一负责人，对项目的质量负有最终责任。
59. 测试或产品评估：一种结构化的方法，通过测试直接找出产品存在的质量问题，提供有关北侧产品的客观信息。
检查：对照之前确定的书面标准开展检查，也可以发现产品的质量问题。不如测试客观。
审计：确定活动是否遵守了质量政策，过程和程序的结构化审查，并不针对具体的产品质量问题。
统计抽样：选取不烦你样品本进行质量检查，并推论出全部产品的质量。不如测试客观。
60. 满足客户真正需求的质量特性：适用性
61. 可以用控制图来确定服务时稳定或具有预期性能的。
控制图：
控制上下限，横轴反映的过程质量随时间的变化。也可用于结果是否稳定或达到了预期的质量。
控制图上的点，反映了测试的结果，以及测试结果是否超出了控制的最小或最大限制的要求，超出控制点意味着过程失控，需要立即采取措施。
62. 检查是控制质量过程的工具。
63. 要确保质量成本满足项目特性，通过成本效益分析，在规划质量时就考虑质量成本，在达到质量要求的情况下减少返工，提高生产率，降低成本与提升相关方满意度。
64. 在规划质量过程中，由高级管理层颁布并确定组织质量工作方向的质量政策。
如果没有，则需要项目管理团队来。
65. 因果图：能发现根本原因。
66. 散点图：显示两个变量间的关系，可以用于研究并确定两个变量之间可能存在的关系，比如造成问题的共同原因。
67. 项目将采用的质量标准，时质量管理计划的组成部分。
质量测量指标，用于描述项目和产品属性，以及控制质量过程将如何验证质量符合测量指标程度。
注：
易错。即使时进行了一个外部供应商的项目，要查找原因，此时具体的质量标准也记录在质量管理计划中，而不是合同之类的。
68. 防止出现返工，应该加强培训，做好预防，预防胜于检查。
69. 质量审计工具：可以确认已批准的变更请求（包括纠正措施，缺陷补救，预防措施）的实施情况。
70. 管理质量的工具：解决问题
管理质量，是验证过程，树立信心，提高实现质量目标的可能性。
71. 如何直接减少由标准差衡量过程中的随机偏差：改进整个生产系统
随机偏差：正常偏差。通过改进过程或系统，可以减少误差。
72. 执行质量审计，识别违规做法，差距和不足。采取后续措施纠正问题，可以带来质量成本的降低。
73. 属性抽样：定性判断，判断合格与否。
74. 在质量计划编制中，质量政策应当由项目管理团队通知到利害相关方。
项目经理是总责任人。
具体事情由项目团队完成。
75. 项目经理需要积极主动了解公司新项目对自己项目可能产生的影响。
76. 配置管理，就是版本管理，有助于确保项目配置项（比如WBS）组成的正确性。
77. 配置管理三步骤。
客户认为不符合验收标准，要求返工。此时应该检查配置项的客观数据，包括返工进度的信息都在配置状态记录中。先查看配置状态记录，再进行配置核实和审计。
78. 批准的变更影响了范围基准，首先要更新的包括：项目管理计划中的范围和进度基准。
79. 项目管理计划完成后，必须得到重要相关方的反馈和批准。
80. 工作授权系统：建立一套程序，以保证工作按正确的顺序，在规定的时间内完成。
81. 项目管理计划必须在编制完成并经过关键相关方进行审批之后，才可以作为项目的基准，
82. 变更控制系统，是关于变更管理的一系列正式的书面程序。
83. 对于已经发生的变更，应该马上补上变更单，再确定变更的影响。
84. 变更顺序
（1）剔除变更
（2）分析该变更对项目工作，日程和进度的影响，并将其提交给变更控制委员会
（3）做出相应变更并要求团队实施变更
（4）将变更的影响通知相关方
85. 如果题目意思是成本基准已经变更，说明范围的变更情况在变更申请时已经评估过。
接下来就是通知相关方，发布更新的预算。然后执行得到通过的范围变更。
？
86. 停工的选项都不要选。
87. 项目内的问题，找发起人或管理层，都不可选。
88. 在控制过程中，两个过程同步进行，以保证工作的正确性和验收：质量控制+确认范围
89. 确认范围：就是让客户验收可交付成果。
90. 什么阶段参考需求跟踪矩阵：整个项目生命周期
91. 需求跟踪矩阵的作用：为便于在项目生命周期内对需求进行管理，确保每个需求都具有商业价值，为管理产品范围变更提供系统的框架。
92. 在规划阶段，如果发现范围没有定义清晰，就继续定义清晰。
93. 当分包商在按照不完整并且不同的范围说明进行工作时，项目经理首先要做：检查按照正确对待的范围说明完成工作。
检查：工具。确认范围和质量控制的工具。
94. 范围是基础，当范围不充分时，估算时间或成本就会遇到困难。
95. 收集需求的输入：识别相关方。
96. 如果你没有参与范围的定义，那就先要确认范围是否定义清晰，相关方是否提供了完整的需求。
97. 对项目范围的变更，有可能在项目范围管理计划中涉及，规定项目范围和产品范围变更所应遵循的程序。（变更控制系统更准确）
98. 定义范围，是为了确定项目的详细范围说明书，详细描述项目的主要可交付成果。
工具和技术：专家判断，产品分析，备选方案识别，引导式研讨会
99. 定义范围的下一步，创建WBS 。
即面向可交付成果，进行层级结构分解，目的是将任务分解成可管理和可配置的部分，再进一步进行进度规划和成本估算。
100. 注意区分确认范围和控制范围。
控制范围：分析范围偏差的原因和程度。
101. 项目范围说明书：产品范围描述，产品验收标准，项目可交付成果，项目的除外责任
102. 原型完成后，必须经过反馈，确认，批准。才可以成为需求文件的内容。
103. 原型法：是制定需求文件的主要工具和技术。
符合渐进明细的理念。
需要重复经过制作，试用，反馈，修改过程并最终确认后，才能获得足够完整的需求。
104. 强制性依赖关系：工作本身属性所固有的。
105. 专家资源不确定是否能到项目中，那就按照普通资源来估算，即正常的资源水平。
106. 里程碑：仅表示主要可交付成果和关键外部接口的计划开始或完成日期。
107： 进度压缩：赶工，快速跟进
进度压缩的前提：不缩减项目范围
108. 为了成员不承受太大压力，并避免进度延误的风险，则应该多一些缓冲。即储备分析。
109. 如果项目因某些活动时间限制而无法如期完工，则这些活动最有可能：存在负浮动时间
110. 向管理人员做月度进度报告的合适方式：以时间为尺度的横道图
111. 滞后：介于两个任务之间等待时间的名字
112. 制定项目进度计划需要：网络图 （不要 范围核实）
113. 假设情景分析：对各种情景进行评估。
114. 在进度控制过程中，应该重点关注关键路径上的活动。
进度压缩时，
向关键路径要时间。
向费关键路径要资源。
所以，在考虑资源再次分配时，必须考虑活动具有浮动时间，使用该资源不会导致项目的总工期延误。
115. 关键路径的最佳描述：可以通过分析进度灵活性最小的活动序列来预测项目所需工期。
116. 收益递减规律：随着投入的增加，单位投入的产出，会呈现逐渐减少的趋势。
117. 成本基准，是制定预算的输出，不是估算成本的输出。
（规划成本管理，估算成本，制定预算，控制成本）
118. ETC：绩效测量，告诉我们完成一个项目还需要多少预算。
119.
（1）EAC = BAC / CPI
其中：
EAC是完工估算
BAC是完工预算
CPI是成本绩效指数
这是假设以当前CPI完成ETC工作 ？典型偏差预测的方法。
知道当前的CPI和BAC,可以计算出ETC（常用题型： CPI为1.04， 预计成本200000， 则最终成本是多少，计算出ETC即可）
（2）EAC = AC + （BAC - EV）
这是假设将按预算单价完成ETC工作。非典型偏差的计算公式。
（3）EAC = AC + ETC
判断项目能否在预算内完成，需要知道项目剩余工作完成费用。
120. 成本估算的依据：工作分解结构
121. 制定预算过程的工具：成本汇总，储备分析，资金限制平衡 （没有 质量成本）
122. 成本管理计划中，确定：成本跟踪的格式，控制临界值，报告频率和准则。
所以，项目经理需要随时了解项目的成本绩效信息，应该在监控过程中考虑成本管理计划。
123. 成本超支，最有可能是范围没有定义好。
124. 制定项目成本预算过程中，考虑项目进度计划可以允许将成本按发生的时段进行分配。
根据项目进度计划，将费用按照其拟定发生的日历期限汇总。
125. 项目总预算（项目总资金需求） = 成本基准 + 管理储备
126. 鱼骨图：激发思考，组织思路，可以发现背后隐藏的根本原因
127. PDCA：计划-实施-检查-行动
由休哈特提出，经戴明完善。
是持续质量改进的基础。
补充：
质量规划的工具：标杆对照，成本效益分析
128. 直接成本：外包合同费用
间接成本：办公场地租金
129. 散点图：两个变量的关系。用两个变量来作图，一个自变量，一个因变量。
130. 控制图：
作用是识别过程何时因特殊原因导致失控。
可以反映结果相对于质量控制标准的符合程度。
也可以反映工艺变更改进质量结果的改善状况。
131. 如果题干信息表示，在做过程分析。那就属于管理质量的工作。
过程分析，是管理质量的工具。
132. 重新确定质量标准，这属于规划质量管理过程的活动。
133. 规划质量管理过程，需要参考事业环境因素中的政府法规。
134. 根本原因分析（RCA）：可以用来确定偏差，缺陷，风险基本的潜在原因
135. 质量控制的范畴：
针对结果，采取措施提出建议，以消除质量缺陷。
提出措施建议，消除不合格属性的根本原因。
监测具体的项目成果，以确定它们是否符合相关的质量标准。
136. 石川图：可用于调查项目所面临的风险和问题。属于根本原因分析的例子。
分析根本原因，并找出各种因素如何与潜在问题或结果相联系。
补充：
分析根本原因的技术：问题解决，石川图，过程流程图
控制图不是，控制图用于确定过程是否稳定，是否具有可预测的绩效结果，并不能用于根源分析。
137. 返工多，意味着质量管理差。应该在项目质量管理过程进行评审，解决问题。
138. 要使客户满意，产品需要：符合需求，适于使用
139. 确保符合需求，属于质量成本里的一致成本。
140. 误差幅度，是讨论制定具体的质量测量指标，描述项目或产品属性以及质量控制过程如何对其进行测量。
项目经理参与的是规划质量过程，目的是建立质量管理计划。
141. 控制质量里如何纠偏：
成果是否符合质量要求？
有没有按照质量计划去执行？
绩效好不好？
答题时，把题目的情况和上述三个特点相比较，如果都不属于这三个特点，那就是管理质量。
142.
（1）头脑写作：
头脑风暴的改良。
是识别相关方过程的工具和技术。
大家围成一圈，每个人单独思考，将识别出的相关方写在纸上，再传递给下一个人，一轮接一轮书写和传递纸张，直到每张纸都传回最初发出者那里。最后，把纸张交给主持人，主持人组织大家讨论。
（2）亲和图
用来针对各种主意，进行归类的技术。
（3）名义小组技术
结构化的头脑风暴。
（4）头脑风暴
大家口头发言，主持人实时公开记录在白板上，而后再讨论。
143. 问题解决后，要及时确认。并做好记录。否则会导致再次发生。
144. 团推建设的5阶段模型：
形成
震荡
规范
成熟
解散（终止）
145. 团队对于满足可交付成果十分吃力，项目绩效差时，项目经理应该启动绩效评估，寻找导致绩效低下的根本原因。
146. 项目经理与职能经理的主要沟通技能：谈判
147. 之前达成解决方法，后来又改变主意，说明之前并没有解决问题。所以这种争论解决技术属于：调解。不属于解决问题。
148. 责任分配矩阵：
详细说明人员的角色分配。
详细说明角色和职责。
和WBS或者范围定义相关联。
不能详细说明员工何时分配到任务上。
149. 建设团队的工具：
对成员的优良行为给予认可和奖励。
鼓励非正式的沟通活动，以建立信任关系。
几种办公，设立项目作战室。
150. 集中办公对团队沟通的贡献最大。
151. 管理团队过程：
跟踪团队成员的表现。
提供反馈。
解决问题并管理变更。
也可以提交变更请请求。
更新资源管理计划。
152. 代际：沟通中的障碍。不同时代人群沟通障碍。
153：
（1）监督沟通：
通过审查相关方参与度评估矩阵中的变化，来确定沟通是否起到了应有的作用。
（2）规划沟通：
搞清楚信息需求，编制沟通管理计划的过程。
（3）管理沟通：
按计划生成，收集，发布，存储，利用和最终处置项目信息的过程。
154. 交互式沟通，推式沟通，拉式沟通
没有“虚拟沟通”
155. 管理沟通的工具：人际关系和软对技能之会议管理。
制定并发布会议议程。
156. 变更需要正式书面的沟通。
157. 书面沟通，可以保留证据，有助于解决复杂问题。
158. 规划沟通管理的工具：沟通需求分析
159. 推式沟通：把信息发送给需要了解信息的特定接收方。
160. 沟通的层级：
水平型：向沟通
垂直型：向上或向下沟通
161. 风险应对中，已知风险应使用应急计划，或弹回计划。应急计划无效时，用弹回计划。
未知风险应使用权变措施。权变措施时针对以往未曾识别或被动接受的，目前正在发生的风险，而采取的未经事先计划的应对措施。
162. 每个项目是独特的时候，就会有不确定性，就比较容易受到风险影响。
163. 标准差：是指实际值对平均值的偏离程度，标准差越大，说明越不确定，风险越大。
即，标准差告诉你估计的不确定程度。
164.
（1）机会转移
（2）机会接受
（3）机会分享
（4）机会开拓：团队识别出一个可能发生的积极结果，管理团队分配了最有经验的高级工程师以确保该组件被尽可能的开发结束
165. 应急计划编制：定义一旦已识别风险发生后要采取的步骤
166. 风险定性分析过程：对已识别风险按其重要性进行排序。
167. 低风险放到观察清单中（非关键风险列表）。
168. 最有可能引起不好的风险管理的原因：缺乏按照优先排序的风险列表
风险排序：就是为了更好的分配精力，优先关注重点风险，低风险放到观察清单中观察。
169. 在风险责任人对于风险减轻活动完成时，需要进行风险审计，以检查并记录风险应对措施在处理已识别风险及其根源方面的有效性，并更新风险登记册。
170. 触发条件：显示风险即将发生的事件或条件/情形
171. 有效风险管理的首要条件是：决策所需信息的透明度高。信息要公开透明
172. 敏感性分析：实施定量风险分析的工具。
检查当其他要素保持在基线值的时候，某一要素对目标的影响程度。
173. 预期货币价值分析：各种情况和对应的概率的乘积之和
174. 如何对待观察清单上的风险：存档记录和重新查看
监控风险观察清单中的风险。
175. 次生风险：实施风险应对措施，直接导致的风险称为次生风险。又称二次风险。
残余风险：是指在采取预定应对措施之后仍然存在的风险。
176. 风险责任人：负责规划风险应对措施，并确保应对措施的实施。
在风险监督过程中，风险应对负责人应该告诉项目经理中间需要的任何纠正。
177. 对于未界定工作的合同，可能按执行小时费率计价。
未确定范围，用工料合同。
在不完全了解范围的情况下，对于买方成本风险较低的，是工料合同。
178. 固定总价合同：
能确定SOW，说明采购范围确定，能既定产品，成果和服务。这种情况，用固定总价合同。
对买方最有力，对承包商最不利。
179. 激励和奖励费用，可用于协调买方和卖方的目标，达到双赢。
180. 总价激励费用合同：由目标成本，利润，最高价，共享比率或风险组成。
181. 合同谈判的主要目标：保护双方的关系。
采购谈判是指在合同签署之前，对合同的结构，各方的权利和义务，以及其他条款加一澄清，一遍双方达成共识。
182. 建立一个筛选系统：建议一个供方选择标准以确定评估标准。
183. 在规划采购过程需要考虑风险登记册和与风险有关的合同决策。
184. 长期的（排除工料），不确定范围的（排除总价），用成本加固定费用合同。
185. 成本补偿合同：是支付全部合法实际成本，买方要审核卖方的成本。
186. 关闭合同是控制采购的内容之一。
187. 采购工作说明书：对拟采购项的详细描述，以便潜在卖方确定他们是否有能力提供这些产品，服务或成果。
188. 合格卖方清单是实施采购的输入，并非供方选择标准的条件。
189. 首次开展识别相关方过程，不会提出任何变更请求。
重复开展本过程，就可能提出变更请求。
190. 所有已识别出来的相关方，都应该列入相关方登记册。
191. 标杆对照：寻找一流做法，以此为标杆。
这几项都不如标杆对照贴切：文献检索，图书馆服务，专家判断
192. 规划相关方参与过程：
通过使用相关方参与度评估矩阵，发现相关方当前参与程度和所需参与程度的差距，再策划该如何提升相关方的参与程度。
193. 管理相关方参与过程：
根据相关方参与计划，实实在在的和相关方打交道，引导相关方积极主动参与项目工作，支持项目。
194. 监控相关方参与过程：
监控项目团队和其他相关方之间的关系，以及其他相关方相互之间的关系，提出变更请求。
195. 识别相关方的工具：权利利益，权利影响，凸显模型。（没有权利作用）
196. 为了有效的识别相关方，需要进行：
（1）识别相关方及其信息
（2）对相关方进行分类
（3）评估关键相关方的反应
（4）制定相关方参与计划
197. 识别相关方过程的输入：
项目章程
商业文件
组织过程资产
198. 先识别相关方，后规划沟通管理，相关方登记册和相关方参与计划都是规划沟通管理的输入。
199. 相关方分析：会产生相关方清单和关于相关方的各种信息（与项目的利害关系，期望态度等）
200. 某人应该负责某项工作，是记录在资源管理计划的角色和职责中。
其表现形式为：责任分配矩阵，或RACI矩阵。
201. 面对，解决问题的策略：把冲突当做需要解决的问题来处理，以取舍的态度进行公开对话。
202. 团队成员技能不足，培训是首选。
203. 明确正式的角色和职责，是团队形成阶段。调整习惯并开始协同工作，是团队建设的规范阶段。
204. 责任分配矩阵：反应工作与项目团队成员之间的关系。
项目组织图：以图形的方式展现项目团队成员及通报关系。
205. 在矩阵环境中，项目经理对团队往往没有或只有很小的直接权力，所以项目经理影响相关方的能力，对保证项目成功非常关键。
206. 团队建设的目的：通过提高项目团队绩效，从而提高项目绩效。
207. 资源日历反映了每种具体资源可用性。
208. 工作授权系统：描述了团队成员什么时候需要做什么事
209. 预分配的三种情景：项目章程制定，专有技能，竞标承诺
210. 团员生病，采用替代资源避免项目未来产生问题，降低消极风险发生的可能性或影响，属于预防措施。
211. 分析沟通需求，确定项目相关方的信息需求，包括对所需信息的类型和格式，以及信息对相关方的价值。
审查沟通管理计划中的相关方沟通需求，如需修改，可以提出关于沟通管理计划的变更请求。
212. 制定详细的沟通管理计划，项目经理必须要了解相关方的数量和沟通渠道的额数量，进行沟通需求分析包括对潜在沟通渠道或途径数量的分析。
沟通的复杂性随着沟通渠道数量的增多而增大。
213. 规划沟通管理过程：确定项目相关方的信息需求，并定义沟通方法的过程。相关方对信息管理不满意，首先要审查沟通管理计划。
识别相关方的信息需求，并确定满足这些需求的适当方法，是决定项目成功的重要因素。
214. 制定沟通管理计划的输入：相关方参与计划，需求文件，项目章程
215. 项目经理必备的管理沟通的人际关系技能包括：积极倾听，冲突管理，文化意识，会议管理，人际交往和政治意识
216. 沟通模型：包括信息发送者，接受者，信息编码，解码和反馈。并规定了发送者和接受者的职责，是规划沟通的重要工具。
217. 项目经理确保有效果和有效率的沟通，必须建立详细的沟通管理计划，包括项目状态会议的指南和模板。
218. 沟通管理计划：
是解决和谁沟通，沟通什么，如何沟通的问题。必须先了解相关方的需求。
还包括 项目状态会议，项目团队会议，网络会议，电子邮件等各方面的指导原则。
还包括：对要发布的信息的描述，包括格式，内容，沟通相关信息的责任人，信息接受的个人或组织等文件。
219. 监督沟通的输出：变更请求
220. 状态报告：
项目的进展应该包含在项目的绩效报告中，
状态报告是绩效报告的内容，记录项目的状态信息。
221. 问题日志：管理沟通过程的输入。
项目存在问题，应该记录在问题日志或行动日志，并指定行动责任人，解决问题。
222. 发送方（项目经理）：负责信息内容清晰明确，不模棱两可，完整无缺，以便放接收方能正确接收，并确认理解无误。
接收方：保证信息接收完整无缺，信息理解正确无误。
223. 风险负责人：负责监测，选择并实施恰当的风险应对策略。
负责在监督风险过程中报告风险应对策略的有效性，任何预期之外的影响和任何纠正措施。
224. 风险审计：一种审计类型，可用于评估风险管理过程的有效性，是监督风险的重要工具。
225. 储备分析：是指在项目任一时点，比较剩余应急储备与剩余风险量，从而确定剩余储备是否仍然合理。
226. 出现问题时，项目经理首先要确定关键资源辞职对项目的影响以及是否发生了已识别的风险，然后再根据评估的结果提出纠正措施的变更。
227. 变更请求，是实施风险应对过程的输出之一。在实施风险应对后，可能会就成本基准，进度基准，项目管理计划的其他组件提出变更请求。应该通过实施整体变更控制过程对变更请求进行审查和处理。
228. 假设条件分析：验假设条件在项目中的有效性，确定其中哪些会引起风险，从假设条件的不准确，不稳定，不一致或不完整，可以识别出威胁。
是识别风险的工具和技术。
229. 积极的风险和机会的应对策略：上报，开拓，提高，分享和接受。
230. 风险分类：
风险类别是组织过程资产的内容，通常借助风险分解结构来构建风险类别。
风险类别的修改，调整或变更跟随风险管理过程。
风险类别模板是风险管理规划的依据之一。
231. 预期货币价值分析：未来情况包含不确定结果时，可用这个来计算平均成果。
其表现形式为决策树分析。
补充：
敏感性分析：表现形式为龙卷风图。用于找出对目标影响最大的风险要素。
232. 实施风险应对之后，可能需要更新风险登记册，反映开展本过程所导致的对单个项目风险的已商定应对措施的任何变更。
233. 监控风险的工具：技术绩效分析，风险审计，储备分析
234. 转移：将消极风险转移给承包商，通常可能需要为转移风险支付一定的费用
回避：需要改变或变更项目管理计划
减轻：降低消极风险发生的概率或者影响
235. 当某个风险发生的可能信或影响变化时，首先需要更新风险登记册，再审查并确认可能的风险应对措施，提出相应的变更。
236. 识别风险阶段的风险登记册：包括已识别风险清单，潜在的应对措施清单。
在应对措施清单可作为规划风险应对过程的输入。
237. 项目风险管理的4个主要步骤：
风险识别
风险分析
风险应对措施
风险监测与控制
238. 定量风险分析：就已识别的单个项目风险和不确定性的其他来源对整体项目目标的影响进行定量分析的过程。
239. 采购审计的回顾内容：从规划采购管理过程，到控制采购过程 的采购过程进行审查。是对采购过程的结构化审查。
240. 合同变更控制系统：用来收集，跟踪，裁定，沟通有关合同变更的系统。
241. 关于合同中采购设备的技术要求和成本发生变化，必须提出变更请求或者批准。
242. 合同未正常收尾，说明采购管理过程存在问题。应该实施采购审计，对所有采购过程进行结构化审查，找出可供借鉴的经验教训。
243. 检验完毕并交付所有可交付成果，意味着采购结束，下一步需要进行可交付成果的移交（职能型项目组织）
244. 控制采购过程的成果：采购文档更新，卖方绩效报告，支付计划和请求，变更请求
245. 固定总价合同：买方风险最小，卖方风险最大
246. 在获得卖方建议书和相关响应采购工作说明书的文件后，还需要利用供方选择标准，来评价卖方的响应情况。
247. 成本补偿合同（成本加固定酬金合同）：项目要有最大的灵活性
248. 卖方想要了解买方的需求，需要：获得采购工作说明书，参加投标人大会
249. 投标人大会：实施采购的一个工具。让投标人充分了解采购内容，并将对问题的回答编入采购文件。
250. 对承包商的审计，应该使用正式，书面的沟通方式。
251.
（1）总价合同：需求或范围定义明确的采购。买方风险最小，能够最大限度的刺激卖方在最低的成本最快的时间内完成合同。
（2）工料合同：适用于不能很快编写出准确工作说明书的情况。
（3）成本补偿合同（成本加固定酬金合同）：适用于工作范围在开始时无法准确定义的情况。项目要有最大的灵活性。
（4）固定总价加经济价格调整合同：由于卖方履约要跨越相当长的周期（数年），可以保护买方和卖方免受外界不可控情况的影响。
（5）时间加材料合同：范围不确定的情况下。
252. 建议书评价技术：对于复杂的采购，往往要综合采用建议书评价技术，根据事先确定的供方选择标准来评价卖方，或签订合同，或确定合同谈判的顺序。
253. 识别相关方，输出：相关方登记册
254. 进行相关方分析后，与相关方参与计划相关的某些信息可能敏感，不宜纳入公开的文件中，需要审核相关方分析的结果。
255. 基准未获批准之前，不会有变更发生。
256. 相关方对项目可交付成果持不同意见，这是由于在项目规划过程未让相关方尽早参与，也是识别相关方过程中相关方分析的结果存在了问题。
257. 启动大会的重点：召集客户，发起人等关键相关方，对项目章程中项目的目标进行评审，并获得批准。
258. 项目经理必须利用时间，通过相关方分析，按照相关方的利益，影响力和参与程度，对相关方进行分类。提高积极相关方的正面影响，降低消极相关方的负面影响。
259. 管理相关方参与过程的工具：基本规则和会议
输出：变更请求
260. 发起人和用户对可交付成果持不同的态度，说明最终的可交付成果未能满足相关方的要求，即，相关方参与计划中，对于项目目标与不同相关方的要求未能有效管理。
261. 相关方对于项目目标持不同意见，则需要分析相关方的作用和影响，确定其参与项目的程度和时机，以便尽可能提高和时机，以便尽可能提高他们的正面影响。降低潜在的负面影响。
262. 识别项目内外所有相关方，是谁的职责：项目管理团队
263. 管理质量过程的工具：根本原因分析，散点图，流程图
264. 项目章程的批准，意味着正式授权。
265. 变更要做综合评审。客户，总工程师，项目经理，会计人员等，均是与变更相关的相关方。
在评估变更的时候，通常由变更控制委员会来进行。
变更控制委员会的角色和职责，应该在配置控制程序与变更控制程序中明确规定，并经相关方一致同意。
266. 变更必须进行风险分析和影响评估。
267.配置管理定义了：
哪些是配置项，
哪些配置项需要正式变更控制，
针对这些配置项的变更控制过程。
确定并记录产品的功能和物理特性：属于配置识别和配置状态记录，描述了配置管理关于变更控制的属性。
268. 计算玩进度绩效指数和成本绩效指数之后，下一步：进行偏差分析，了解项目的总体偏差情况，以决定是否需要采取核实的预防或纠正措施。
269. 项目启动的输入之一：商业文件，包括商业论证+效益管理计划
商业论证：启动项目的依据。
270. 工作绩效数据，包括：
每个正在执行的活动中收集到的原始观察结果和测量值
补充：
可交付成果状态，是工作绩效信息。
推荐的纠正措施等意见，是在绩效报告里。
271. 识别相关方的主要原因：
通过相关方分析，以尽可能提高他们的正面影响，减低潜在的负面影响。
272. 相关方登记册，作为这些过程的输入：计划沟通，收集需求，计划质量，识别风险
273. 风险分解结构 RBS ：
按风险类别和子类别来排列已识别的项目风险的一种层级结构，
用来显示潜在风险的所属领域和产生原因。
属于风险管理计划的内容。
274. 制定风险管理计划的工具和技术，只有：规划会议，分析。
确定实施风险管理活动的总体计划。
275. 风险定性分析：
识别风险后，需要确定风险的优先级排序，确定风险发生的概率，对目标的总体影响。
276. 采购管理计划组成部分的合同：记录了变更的条款和要求。但不涉及变更控制。
如果项目的自制和外购决策发生变化，属于采购方面的变更，应该遵循整体变更控制流程。
277. 控制采购的工具：实施采购绩效审查。
为了管理卖方的绩效，通过采购绩效审查工具，依据合同来审查卖方在规定的成本和进度内完成项目范围和达到质量要求的情况。
278. 成本加固定费用合同 CPFF：为卖方包销履行合同工作所发生的一切可列支成本，并向卖方支付一笔固定费用，该费用以项目初始成本估算的某一百分比计算，并且不因卖方的绩效而变化。
279. 供应商执行变更存在问题，意味着在范围绩效存在偏差，需要通过爱狗绩效审查来衡量卖方履约的好坏。
280. 相关方管理3步走：全部识别，分类，重点管理
281. 执行过程组：
为了完成项目管理计划中确定的工作，以实现项目目标，输出的是可交付成果以及工作绩效数据。
执行的结果为监控提供依据。
282. 从管理团队发现的问题，需要提出纠正措施，去建设团队。
283. 项目收尾的工具和技术：专家判断
284. 发生问题，需要采取纠正措施，首先要提出变更请求并进行风险分析和影响评估，再提交给CCB召开变更控制会议，对变更进行审批。
285.实施采购过程：根据功放选择标准来评价卖方建议书，以确定合同授权的对象。
286. 请求获得批准，并影响到进度和成本时，需要将新的进度和成本信息，更新到成本基准和进度基准中。
287. 定性风险分析：
输出 根据概率影响矩阵对风险进行分类的风险登记册，并包含项目风险的相对排序或优先级清单。
定量风险分析：
标明风险，以及风险对于项目实现成本和时间目标的概率。
288. 风险登记册中，有：潜在的应对措施。
查看风险登记册，并选择既定的风险应对策略，提出变更批准之后，实施应对措施。
补充：
风险分析结构，是指按风险类别和类型分类的风险。
289. 质量测量指标：
规划质量的输出。
有关检查规定，以及具体的检查指标，记录在里面。
是一种操作性定义，用非常具体的语言，描述项目或产品属性以及质量控制过程如何对其进行测量。
290. 要求准确估算每个工作包的成本核算和时间，通过WBS分解，并进行自下而上的估算方法最可靠。
291. 已经识别的风险发生了，项目经理首先应该更新风险登记册，对风险的概率和影响进行记录。
（为什么不更新风险日志？）
292. 计划，设计，分析，测试：属于生命周期的阶段。属于工作分解结构的第二层次。
工作包：工作分解结构的最底层。
293. 项目进度网络图：
反映了项目活动之间的依赖关系，但不能反映活动的开始时间和结束时间。
补充：
组织分解结构：按照组织现有的部门，单元或团队排列，并列出不嗯的项目活动工作包。
294. 管理多个供应商以及拟采购的内容采用的合同类型，都是采购管理计划的内容。
还包括指导：如何管理从编制采购文件直到合同收尾的指南。
295. 可交付成果和验收标准，属于项目范围说明书的内容。
范围基准：批准的WBS, WBS词典，范围说明书
296. 定义范围 的输出：范围说明书，项目文件更新
297. 德尔菲技术：
本质上是一种专家匿名调查法。
大致的流程：
在对所要预测的问题征得专家的意见之后，
进行整理，归纳，统计，
再匿名反馈给各专家，再次征求意见，
再几种，再反馈，
直到得到一致的意见。
在这过程中，由一名管理人员分别与专家单独联系。
298. 控制图上：标明过程失控的状况，分两类：
（1）七点法则：连续7个点在均值的一侧
（2）单个超出控制上下线
299. 预期货币价值 EMV:
也叫决策树分析。
是当某些情况在未来可能发生，也可能不发生时，计算平均结果的一种统计方法（即不确定性下的分析）。
或者是决策树的不同情景对应的结果。
300. 项目范围说明书，包含了：项目的主要可交付成果的详细描述，产品验收标准，项目边界条件，制约因素，假设条件等。
301. 挣值技术，综合考虑：项目范围，成本与进度指标。并可以量化基准的偏差，帮助项目管理团队评估与测量项目绩效和进展。
302. 有关采购过程的经验教训，记录在组织过程资产中。
是采购审计的工具和技术的结果。
303. 变更获得批准，新的工作包和额外资金，都应该反映在：批准的变更请求中。额外资金也要对成本基准进行更新。
304. 蒙特卡洛分析：
根据活动的持续时间概率分布，再确定整个项目的可能工具概率分布。
也用于制定进度表过程 假设情景分析的工具。
补充：
项目经理利用进度网络分析技术，为每项活动都定义了可能的活动工期分布范围。
应该用蒙特卡洛技术，来计算整个项目的可能结果分布。
305. 总价合同：买方风险最低
成本补偿合同：卖方风险最低
306. 针对结果采取措施，属于质量控制。
307. 防止范围蔓延，就是要做好范围变更的管理。
遵循变更控制程序。包括变更的文书工作，审批层次和跟踪系统。
308. 综合大家的一致意见（少数服从多数），并解决冲突，属于合作的策略。
309. 管理合同可交付成果的变更，属于变更合同范围。
需要使用合同变更控制系统，包含在变更控制系统中。
是控制采购的工具和技术。
310. 绩效测量基准：综合了范围，进度，成本基准。
据此测量项目的整体绩效。
绩效测量基准，用于政治测量，有时也包括技术和质量绩效。
311. 在启动过程识别相关方，在规划沟通过程确定相关方的沟通渠道数量，并在执行过程建立并实施沟通。
312. 质量成本包括：
在产品生命周期中预防不符合要求，
评价产品或服务是否符合要求，
以及因未达到要求（返工）而产生的所有成本。
313. 团队章程：
对项目团队成员的可接受行为确定了明确的期望。
尽早认可并遵守明确的规则，有助于减少误解，提高生产力。
讨论注入行为规范，沟通，决策，会议礼仪等领域。
团队成员可以了解彼此重要的价值观。
314. 考点：
激励理念，工作环境是典型的保健因素。
麦格雷戈XT理论
马斯洛层级需求理论
赫兹伯格双因素理论
亚当斯公平理论
315. 风险登记册：记录的是风险的分类，以及定性定量分析的结果。
风险管理计划：对相关方的承受力进行修订，以适应具体项目不同风险的情况。
在事业环境因素中，记录了相关方组织对风险的态度和承受力。
316. 财力实力，全生命周期成本：是评价卖方建议书的具体标准。是实施采购的输入。
在确定评估标准的时候，买方要努力确保选出的建议书将提供最佳质量的所需服务，包括公司的财务稳定性。
317. 里程碑清单，包括：所有里程碑，包括强制的和可选的
318. 收集需求 过程的输入：项目章程，相关方登记册
319. SWOT: 是识别项目风险的工具。包括组织内部和外部的风险。
优势
劣势
机会
威胁
320. 过程分析，是管理质量的工具。是在过程中检查遇到的问题和制约因素，并分析过程改进机会，可以确保质量的改进，并提高实现质量目标的可能性。
321. 变更存在不确定性，需要记入风险登记册。
对变更请求的执行做出决定存在不确定性，说明变更管理计划有问题，需要更新。
322. 在职部门内部开展项目的例子。
项目经理的角色是协调员，是兼职的项目经理和兼职的项目团队成员。
323. 监控风险的工具：风险审计，储备分析，状态会议
324. 识别风险的工具：数据分析，头脑风暴，访谈
325. 决定和影响范围控制的计划，包括：范围管理计划，变更管理计划
326. 统计抽样：质量控制的工具
蒙特卡洛分析：定量风险分析
石川图：因果图。找出可交付成果质量问题的根本原因并解决问题
帕累托图：特殊的垂直条形图，用于识别造成大多数问题的少数重要原因
327. 在识别干系人之前，项目章程通常由发起人进行批准，关注的是发起组织和执行组织的初步要求。
项目章程包含项目的成功标准。可以和发起人核对成功标准，并将其添加到项目章程中。
328. 三点估算
老师应该是说：
（1）没有特别说明，估算成本首选贝塔分布
（书本在该章节同时列出了三角分布和贝塔分布，而贝塔分布相对三角分布准确）
（2）估算活动持续时间首选三角分布
（因为书本该章节仅列出了三角分布）
329. 积极和消极风险都有的应对策略：接受
330. 威胁应对策略：
主要指的是针对消极风险，对项目产生负面影响的。
5个策略：
（1）上报：
上报管理层，由管理层做决定。
（2）规避：
不是回避，这里是消除风险的意思。什么是消除风险，就是改变项目管理计划。
（3）转移：
把风险转移给第三方。给第三方支付一定的费用，由第三方来承担风险责任。本身并不消除风险。
（4）减轻：
降低风险发生的概率。不是为了规避风险。通过间接侧面的手段，曲线救国的方式，去影响导致风险发生的要素，导致风险发生的概率降低。
（5）接受：
不采取措施。主动接受，就让风险发生，采取后续的补救措施，降低风险带来的后果。被动接受，让风险发生，发生后不采取任何措施。
331. 机会应对策略：
5个策略：
（1）上报：
上报管理层，由管理层做决定。
（2）开拓：
对应规避。确保机会发生。怎么确保机会一定发生，一种是分配最有能力的资源去应对这个风险。一种是采取全新的技术，获得技术升级，去应对。
（3）提高：
对应减轻。提高机遇发生的概率。比如增加资源赶工，以便尽快完成项目，得到奖金。
（4）分享：
对应转移。把责任和利益分享给第三方。
（5）接受：
不采取措施。主动接受，就让风险发生，采取后续的补救措施，降低风险带来的后果。被动接受，让风险发生，发生后不采取任何措施。
332. 发起人的职责：
项目筹资
澄清项目范围
解决超出项目经理控制范围之外的冲突，为项目提供支持
333. Kickoff meeting: 在计划完成后，执行开始前。目的是在相关方之间就项目管理计划达成一致，获得对计划承诺，也是团队建设的活动。
334. 风险评估：
包括风险概率和影响评估，风险数据质量评估。
是风险定性分析过程的工具。
目的是确定风险的优先级排序，以便进一步的量化分析的制定 可能的应对措施。
335. 储备分析：估算持续时间，估算成本，控制成本，监督风险的工具。
招标人会议：实施采购的工具。
自制或外购分析：采购规划的工具
336. 成本补偿合同=成本加激励费用合同
337. 制定预算的输入：
活动成本估算
估算依据
范围基线
项目进度计划
商业文件
合同，组织过程资产
338. 采购管理计划：描述如何管理从编制采购文件，直到合同收尾的各个采购过程。帮助管理过个供应商和协调采购工作与其他工作。
339. 决策树技术：
使用预期货币价值分析，某些情况在未来可能发生，也可能不发生时，计算平均结果的一种统计方法。
340. 风险应对：
（1）回避
是指改变项目管理计划，以完全消除威胁。
项目经理也可以把项目目标从风险的影响中分离出来，
或改变受到威胁的目标，如延长进度，改变策略或缩小范围等。
最极端的回避策略是取消整个项目。
在项目早期出现的某些风险，可以通过澄清需求，获取信息，改善沟通或取得专有技能来加以回避。
（2）转移：
是指把风险的部分或全部消极影响，连同应对责任转给第三方。
转移风险，是把风险管理责任简单的推给另一方，而并非消除风险。
对处理风险的财务后果最有效。
几乎总是需要向风险承担者支付风险费用。
（3）减轻：
是指把不利风险事件的概率和/或影响，减低到可接受的临界值范围内。
提前财务行动来降低风险发生概率和可能给项目造成的影响。
（4）接受：
项目团队已决定不为处理某风险而变更项目管理计划。
或无法找到任何其他的合理应对策略。
该策略可以是被动的或主动的。
341. 控制账户，是一种管理控制点。
342. 团队绩效评估，是建设团队的输出。
不是项目或阶段收尾时的活动。
343. 应急储备，包括：时间和钱 这两个量化指标。
344. 赶工：通过权衡成本与进度，确定如何以最小的成本来最大限度的压缩进度。
快速跟进：把正常情况下按顺序执行的活动或阶段并行执行。只适用于能够通过并行活动来缩短工期的情况。
345. 识别风险 的输出：风险报告，风险登记册
风险登记册：已识别的风险清单，潜在风险责任人，潜在风险应对措施
346. 组织用来存取信息的知识库：
测量指标数据库
项目档案 （项目过程中的众多基准，计划，日历，图，风险相关）
历史信息与经验教训知识库 （项目记录和文件，绩效信息，风险相关）
问题与缺陷管理数据库
配置管理知识库
财务数据库
……
347. TCPI：完工尚需绩效指数
是指为了实现特定的管理目标（BAC或EAC）,剩余工作实施必须达到的成本绩效指标（预测值）
348. EAC = AC + BAC = EV
按预算单价完成ETC工作。
这种方法承认以实际成本表示的累计实际项目绩效（不论好坏），
并预计未来的全部ETC工作都将按预算单价完成。
349. 头脑风暴：
参加会议的专家在一起，各自卸除自己对于风险的额记录内容。有主持人。
名义小组技术：
结构化的头脑风暴。
通过投票排列最有用的创意，以便进一步开展头脑风暴或优先排序。
350. 风险审计：
检查并记录风险应对措施在处理已识别风险及其根源方面的有效性，
以及风险管理过程的有效性。
351. 风险分解结构 RBS：
风险类别的描述。
风险类别提供了一个框架，确保在同一细节水平全面，系统地识别各种风险，
并提高识别风险过程的效果和质量
352. 项目正常完工，则 PC=EV=BAC
353. 控制质量的工具： 控制图，直方图，统计抽样
354. 鼓励合作型的问题解决和决策方法，可以实现团队的高效运行。达到团队协作，并实现项目目标。
355. 对项目成果享有既得权益的人：客户
356. 提高/增强：机会提高措施，包括为尽早完成活动而增加资源。
357. 配置管理系统：
用于将技术和行政管理的知道与监督应用于产品特性的定义和控制的正式成文程序汇总。
配置控制重点关注 可交付成果及各个过程的技术规范。
附带整体变更控制功能的配置管理系统可以提供标准化，效果好和效率高的方式，来集中管理已批准的变更和基准。
358. 理论X：该理论假设员工缺乏抱负，基本没有解决问题的能力和创造力。
359. 影响力的主要体现：
清晰表达观点和立场。
积极有效的倾听。
综合考虑各种观点。
360. 质量核对单：是一种结构化工具，通常列出特定组成部分，用来核实所要求的一些列步骤是否已得到执行或检查需求略表已得到满足。
361. 项目成本偏差可接受幅度：相当于 成本管理计划中的控制临界值。
输出这计划是项目经理工作范围内的事情，由项目团队确定。
362. 强迫：以牺牲其他方位代价，推行某一方的观点，只提供赢输方案。
妥协：寻找能让全体当事人都在一定程度上满意的方案。
缓解/包容:强调一致而非差异。
面对/解决问题，撤退/回避，合作：综合考虑不同的观点和意见，引导各方达成一致意见并加以遵守。从实际或潜在冲突中退出。通过审查备选方案，把冲突当做需要解决的问题来处理。需要以取舍的态度进行公开对话。
363. 规划质量过程 的输入：范围基准，范围说明书
范围说明书 包括：项目描述，主要项目可交付成果及验收标准
产品范围描述中 包含：技术细节，以及会影响质量规划的其他事项
验收标准的界定，可导致项目成本与质量成本的明显增加或降低。
达到所有验收标准，意味着满足客户需求。
364. 区分内部和外部项目相关方：以项目内核外围区分点。
举例：
内部相关方：高层管理，属于项目团队组成部分的外部咨询顾问，项目承包商的主要分包商
外部相关方：组织中的职能经理
365. 在项目估算中是否应该包括间接成本和其他成本，都需要在估算依据里面明确说明。
如果没有明说包括，那么不需要考虑项目间接成本。
366. 项目开始时，风险最大，随着决策的制定与可交付成果的验收，风险逐步降低。
变更的影响和纠正错误的成本，通常随着项目越来越高。
367. 最初的风险登记册：已识别风险清单。对已识别风险进行可能详细的描述。可采用简单的结构对风险进行描述。
罗列出已识别风险之后，这些风险的根本原因可能变得更加明显。
风险的根本原因，就是造成一个或多个已识别风险的基本条件或事件。
这些都应记录在案，并在以后用于支持本项目和其他项目的风险识别工作。
368. 项目治理：
是指用于知道项目管理活动的框架，功能和过程，
从而创造独特的产品，服务或结果以满足组织，战略和运营目标。
项目治理框架为项目相关方提供管理项目的结构，过程，角色，职责，终责和决策模型。
项目治理为控制项目和确保项目成功提供全面，同意的方法。
该方法应记录与项目管理计划中，而且必须适应项目集或项目发起组织的大环境。
项目经理和项目管理团队应在考虑上述制约因素和时间，预算等其他限制条件的基础上，确定最合适的项目实施方法。
369. 需求跟踪矩阵：
是指把产品需求从其来源连接到能满足需求的可交付成果的一种表格。
能满足需求，自然也就包括业务需求。
370. 迭代关系：
在迭代型生命周期的项目中，
先为整个项目确定一个高层级的愿景，
再一次针对一个迭代器明确详细范围，
通常，随着当前迭代期的项目范围和可交付成果的进展，
而详细规划下一个迭代期的工作。
371. 项目经理的个人目标，就是完成项目目标。
只有项目目标是项目启动阶段的事，其他都是规划过程的活动。
372. 引导式研讨会：
研讨会是快速定义跨职能需求和协调相关方差异的重要技术。
由于群体互动的特点，被有效引导的研讨会有助于建立信任，改进关系，改善沟通，
从而有利于参加者达成一致意见。
引导式研讨会：
能够达成共识，确保持续关注任务，
并以创新方式处理人际冲突或偏见来源，
来改善引导式研讨会的有效性。
373. 通过监控过程，对项目工作进行持续监控，来发现新出现，正变化和已过时的单个项目风险。
低概率和影响的风险在风险分析过程中，别列入风险登记册中的观察清单，以供未来监控。
374. 影响图：
实施定量风险分析的工具。
用图形方法，表示变量与结果之间的因果关系，事件时间顺序，以及其他关系。
375. 凸显模型：
相关方分类方法。
根据相关方的权力，紧急程度，合法性等，对相关方进行分配。
376. 360度反馈评价：
可称为多源评估或多评价者评估。
评价者不仅仅是被评价者的上级主管，还包括其他与之密切接触的人员，比如同事，下属
，客户等，同时包括自评。
377. 经验教育必须传送到公司的知识库中，否则项目还是未完成状态。
378. 质量成本：
预防成本，评价成本，失败成本。
其中，预防成本最重要。
379. 沟通计划 包括：项目相关方的沟通需求分析，确定项目相关方的信息需求，包括所需信息的类型和格式，以及信息对相关方的价值。
380. 资源管理计划：
规划资源管理过程的输出
其内容之一包括：认可计划-指导给与团队成员那些认可和奖励，以及合适给予。
381. 规划沟通管理的输入：
需求文件，相关方参与计划，项目章程
382. 可交付成果，是指导与管理项目工作 的输出。
指导与管理项目工作，执行项目管理计划中所确定的工作。
完成工作，输出可交付成果，
然后再通过控制质量过程输出核实的可交付成果。
383. 项目经理应该以建设性方式，来解决冲突。
冲突的来源：资源稀缺，进度优先级排序，个人工作风格的差异。
成功的冲突管理，能够带来积极的结果，可提高生产力，改进工作关系，提高创造力和改进决策。
384. 谈判是解决所有索赔和争议的首选方法。
385. 所有的变更，拒绝和立即做，都不是合适的选项。
386. 配置核实与审计：
能保证项目配置项组合的正确性，保证想赢的变更都被登记，评估，批准，跟踪和正确实施，从而确保配置文件锁规定的功能要求都已实现。
387. 问题解决流程：
识别问题
定义问题
调查
分析
解决
检查解决方案确认是否已解决问题
388. 成本加奖励费用 CPAF：
为卖方报销履行合同工作所发生的一切合法成本，
但只有在满足了合同中规定的某些笼统，主观的绩效标准的情况天，
才能向卖方支付大部分费用。
完全由买方根据自己对卖方绩效的主观判断来决定奖励费用，并且卖方通常无权申诉。
389. 管理储备：
项目经理无权动用管理储备，
管理储备的使用，需要通过变更控制程序得到管理层的批准授权，
且在获得批准后，把适量的管理储备移入成本基准中。
390. 变更控制委员会 CCB：
负责审查变更请求，
也可以审查配置管理活动。
因此，委员会的角色职责应当在配置控制程序中明确。
配置控制程序支持变更管理和配置管理。
391. 费用绩效指数 = 成本绩效指数
392. 对 “将估算成本与独立的进度活动或工作包结合起来，建立一个项目成本基线” 而言，资源日历是非常有价值的输入。
393. 管理团队：
人员配置变更，包括转派人员，外包部分工作，替换资源
394. 风险管理计划，包括：风险类别。
风险类别：提供了一个框架，确保在同一细节水平上，全面系统的识别各种风险，并提高识别风险过程的效果和质量。
组织可用预先准备好的分类框架，它可能是一个简易分类清单或风险分解结构 RBS.
RBS是按风险类别和子类别来排列已识别的项目风险的一种层级结构，用来显示潜在风险的所属领域和产生原因。
395. 发布信息，即管理沟通过程输出的组织过程资产更新内容。
396. 高层次风险，即主要风险，整体风险。
397. 价值分析，属于产品分析技术，针对的是产品的实现，不针对如何选择项目。
可以作为评价项目管理给组织带来的价值：成本效益分析，净现值分析，需求评估。这几个都是针对项目可行性。
需求评估：
通常是在商业论证之前进行，包括了解业务目的和目标，问题及机会，并提出处理建议，需求评估的结果可能会在商业论证文件中进行总结，执行项目效益管理计划中也需要使用，而商业论证和效益管理计划都是项目章程的输入。
398. 软技能：人际关系技能和团队管理技能。
属于个人能力。
项目经理需要使用软技能来平衡项目相关方之间相互冲突和竞争的目标，以达成共识。
399. 制定预算过程的输入：
项目资金需求
成本基准
范围基准
风险登记册
项目进度计划
400. 干系人担心被排斥，是情绪而未必是事实，属于相关方管理问题。
沟通管理计划，只跟信息有关，沟通问题（信息传递，接收问题）。不是人的参与问题。
401. 识别相关方过程中，给相关方排序的工具：
影响力
利益
影响水平
402. 如何进行团队建设：
开展团队建设活动
举行跟进会议
审查项目范围
重新检查沟通渠道
403. 项目中最常发生的问题，即主要缺陷。
帕累托图：
一种排序后的直方图。
它把缺陷按发生频率从高到低排序，显示主要问题，主要缺陷。
404. 管理质量过程 的内容，主要包括：所有预防工作，以及通过质量审计来改进过程。
405. 凡正式向相关方回报项目情况的文件，都称为绩效报告。
406. 创建工作分解结构WBS，只有两个工具：专家判断，分解技术
407. 质量核对单：
是一种自查工具，
作用是提醒在质量过程中需要做的工作，
防止遗漏。
408. 更新风险登记册，是风险问题的一个绝对选项。
409. 项目进度计划不能满足公司高层批准的里程碑计划，这属于可行性问题。
项目中遇到可行性问题，项目经理应该主动寻找解决方案。即另立方案，解决问题。
410. 龙卷风图：
敏感性分析有助于确定哪些单个项目风险或其他不确定性来源对项目结果具有最大的潜在影响。
411. 针对机会，威胁，项目整体风险应对规划三大策略。
412. 应该在项目章程中，记录整体项目风险的情况。
413. 工作验证系统：
是整个项目管理制度的部分，
用来确保该工作由明确的组织在正确的时间以恰当的顺序完成。
工作验证系统包括步骤，文档，跟踪系统和定义的用来给工作授权的适当层次。
可以用来防止镀金。
PERT：三点估算法，也叫PERT估算法。
CPM：关键路径法。
414. 绩效报告：
为项目相关方提供了关于项目范围，成本，进度绩效信息。
比如哪些预算已满足，哪些没满足，绩效报告还可以给项目成员提出关于未来可能潜在问题的警告。
415.确定并交付所要求的质量与等级水准，是项目经理和项目管理团队的职责。
416. 通过EVM分析，或许能看到不可预料的问题或风险，指示出项目不能在计划的进度或成本目标内完成。
当项目发生指的关注的基线偏离时，更新的风险识别和分析必须要执行。
417. （10.32）
【敏捷】
1. 敏捷项目中，典型的信息发射器：项目燃尽图，任务板，燃起图，缺陷图表
2. 敏捷评估的特征：团队，协作，迭代
3. 看板：
是一个及时的库存控制系统。
产品流程只有在收到命令信号时才执行。
用这种方式谨慎控制库存，确保了没有机器生产多余或无序的产品。
而机器只有在当时有能力执行生产时才发出命令信号。
因此，库存（WIP）不会在机器备份或称为瓶颈，这是因为库存的命令信号是高度控制的，并且是基于流程速度和绝对的需求的。
4. 产品路线图：
为产品负责人所拥有的产品路线图，是产品需求的高层次概述，常用作特性优先处理。特性归类和粗略时间框架确定的工具。
创建产品路线图的4个步骤：
（1）确认需求（这些会成为产品代办事项的一部分）
（2）将需求分类或分定主题
（3）评估相对工作量（比如：计划扑克，亲和估算），优先化（价值）
（4）评估粗略时间框架（评估告诉和冲刺持续时间，以及粗略发布时间）
5. 敏捷团队必须时常处理产品待办事项里的产品特性优先级问题。
从发布计划到迭代计划，敏捷团队必须优先处理 产品的用户故事/特性，来确保高质量和高价值的特性优先得以开发，以此帮助带来乐观和较早的投资收益。
6.往往在相对价值和风险方面，优先处理需求或用户故事/特性：价值由客户决定（客户-价值优先级）
两个处理产品优先级的常用方法：
MoSCow:
将产品特性分为“必需含有”“应该含有”“可以含有”“会含有”
Kano:
“必须含有”“不满足因素”“满足因素”“愉悦因素”
7. 风险-价值指标：包含4个象限。横轴表示价值，数轴表示风险。
8. 成本-价值指标：类似风险-价值
9. 敏捷中所有优先化，都是相对的。一个用户故事只是相对优先于其他用户故事，而非在固定规模上得到优先处理。
10. 一个开放，面对面的沟通文化，最适合敏捷团队。
11. 价值流程图：
敏捷采用的精益生产分析技能。
用于对形成客户产品或服务的原料和信息（价值）的流动性分析。
执行价值流程图的5个步骤：
（1）确认产品，客户和范围（流程的始末）
（2）地图作为团队或者个人现时价值流，确认流程步骤，延时和信息需求。估算流程步骤的持续时长和前置期持续市场。前置期是指发生前一项流程或事件需等待的时长。
（3）分析价值流程图，来确认浪费存在的地方（比如前置期），和流程可完善的地方（流程事件通常认为是价值增加时间，但是应尽量减少整个流程的时间，由此来缩短向客户交付价值流的时间）
（4）通过分析，总结出一份展示价值流应努力达到的前景或者目标的未来价值流程图
（5）通过流程完善活动，或者其他方法来达到目标的一些工作。
包括：
当前价值流程图（包括流程步骤，信息流，前置时间，流程事件）
未来价值流程图 ？？
12. 服务式领导：
关注敏捷团队的需求，清除团队障碍，并为提高生产率提供工具和其他支持。
13. 项目的燃尽图：
用来展示迭代进度的信息发射源。
记录两项序列：剩余的实际工作，剩余的理想/预估工作。
竖轴：工作单元，通常是故事点或时间。估计剩余工作量。
横轴：迭代持续时间，通常是日期数字。日历时间。
理想/预估的工作序列，是一条向下倾斜的直线：由需完成工作价值的竖轴触发，延长至横轴上迭代的最后一天（0故事点）。
实际工作序列每日更新，取决于敏捷团队的生产率和任务的复杂性。
实际工作序列尝尝是易变的，并非直线，它随着项目团队干涉开发流程而消长。
14. 教练和指导：
帮助个人或团队提高绩效，实现实际目标的一种行为。
对敏捷团队，教练和指导的尺度是变动的。
通常，一名指导人员在冲刺迭代阶段共同帮助团队，然后在迭代阶段帮助指导个别的团队成员，这样的情况很常见。
15. 时间，预算，成本：敏捷中重要的知识和技能板块。
敏捷方法的本质：由于敏捷接受变动的范围，意味着为固定的预算和进度提供良好的支持，单变动的范围使总成本的估算更艰难。
总之，
预算和调度的约束是已知的，但这发生在项目初始阶段开始需要定义一组商定的挤出产品功效前。
固定的范围降低了敏捷团队提供提高的价值的创新趋势。
16. 固定总价合同：需求已经商定好，这就不适合敏捷。
17. 适用于敏捷的合同：
初始阶段的一般服务协议和为迭代或用户故事分开设置的固定价合同。
工料合同。
不超过固定费用合同。
最后，奖励性合同（固定价加激励，成本加酬金和奖励合同）
18. 所有的敏捷团队都需要领导。
敏捷领导者所需的重要方面：
授权团队成员决定高敏捷实践和方法的标准。
允许团队进行自主管理和自我约束。
授权团队成员和客户合作决策。
激励团队创造力和探索新思想和技术才能。
成为提倡者，想团队成员阐述产品前景，一次激励完成整体目标。
移除并解决团队工作中肯恩关于到的障碍和问题。
向可能不熟悉敏捷的干系人沟通和宣传敏捷项目管理的而价值和原则。
确保包括商业管理人员和开发者在内的所有干系人有效协作。
最后，能够依据工作环境改变领导风格，一次确保有力支持敏捷价值和原则。
领导人的最佳定义：是指授权开发团队使其获得产品的所有权，并在一个协作环境中做重大决策的人。
19. 积极倾听的定义：全神贯注与演讲者
关注当下，集中精力与演讲者。
做笔记，不打断。
用意译来确认和回顾所收听的内容。
讲话结束时，为后续归纳对话内容。善用开放式问题，适当肢体语言和沉默来提高聆听技巧。
20. 传统的铁三角：范围，进度，成本
敏捷的铁三角：价值，质量，约束
21. 在使用负责项目的滚动波或滚动预测未来计划时，敏捷团队计划在下几个迭代中的工作。
滚动波或滚动预测未来计划聚焦于计划准备完成的工作，并非超出这个门槛的工作，未来太遥远。
22. 集体所有权：团队成员集体对项目结果负责，并被授权参与角色和问题解决流程。
23. 计划扑克（scrum扑克）：
用于估算用户故事点的一个常用敏捷计划技能。
基于宽带德尔菲估算技能，也是以公式为基础的工作量估算技能。
在故事点和开发用户故事中，用来估算相对工作量。
在计划扑克会议中，每一个估算师各派有一副相同的价值范围宽广的计划扑克卡片。
斐波那契数列常用来衡量计划扑克的价值（0，1,2,3,5,8）。
另一种常见数列是（问号，0,1/2,1,2,3,5,8,13,20,40,100）。
计划扑克会议按如下运行：
（1）一名调停人，主持会议，不参与估算
（2）产品负责人，管理人员，对用户故事作概述，并回答开发者提出的额澄清问题，往往产品负责人不参与投票。
（3）每一位估算师抽取一张卡片来估算工作量。
（4）没人抽取一张卡片后，同时将他们的卡片翻转。
（5）持高和低估算的估算时，各有一个机会作立场辩护。
（6）达成共识前，不断重复以上流程。
持有用户故事的开发者往往拥有较高可信度。
补充：
（1）计划扑克的参照点用户故事是中码或均码。
（2）计划扑克通常设定的时间值是2-3分钟来讨论一个用户故事。
24. 敏捷失败（失败模式）的钱12条：
（1）承诺没有自动产生组织变化或获得支持
（2）文化不支持变化
（3）文化没有反思，或执行反思不足
（4）在项目收尾过程中丢失标准和质量
（5）计划中缺乏协作
（6）缺乏或过多产品负责人
（7）项目领导力不足，或scrum主管不信任团队并不允许团队自主管理和自我约束
（8）没有现场的敏捷支持者或教练
（9）缺乏一支完善，高绩效的团队
（10）不维持严格的测试标准的情况下，技术债务会增加
（11）文化维持传统的绩效评估，即推崇个人时丢失团队方面
（12）因为变化难以进行，所以传统或旧式的经营方式出现。
25. 亲和估算：
是预测工作量的一个方法。
通常在故事点，开发用户故事中，而尤其在大型产品代办事项中作用巨大。
亲和估算模式，涉及从小到大范围里测量用户故事。
这个范围可以是斐波那契数列或者T-Shirt尺码，尝尝贴在大型会议室墙上。然后参与者在估算时可将他们的用户故事贴到这面墙上。
这种估算常在无声中进行，知道评估用户故事，常伴有若干迭代。
26. 敏捷项目管理的重要特征：
持续完善
多功能短迭代
增量方法
商业优先权
客户的价值
27. 高敏捷情商：
自我意识
控制自己的情绪
并能注意到其他团队成员的情绪
高敏捷情商使团队成员之间有效协作。
28. 敏捷团队和质量标准是 发展的，进化的。
所有敏捷工作均由项目和质量标准。并努力遵从这些标准，同时在整个项目过程中随时准备调整这些标准。
在一项工作初期，由团队协作的定义，并在整个工作期间协作的改进、
项目和质量标准有助于敏捷团队的凝聚力，同时尽管敏捷团队可随着项目发展做调整，单仍提供一个结构来营造一个自我约束的氛围。
29. 常用的缩写：
EVM：挣值管理，是评估关于成本和调度的项目绩效中常用的管理技能。依赖于其他常见的经济指标。
BAC：完工预算
AC：实际成本
PV：计划价值
EV：挣值
CV：成本偏差
SV：进度偏差
CPI：成本绩效指标
SPI：进度绩效指标
30. 时间箱：分配给估算每一个用户故事的时间。
31：故事点：估计开发一个用户故事相关工作成果的典型单元
计划扑克和亲和估算中，估计用户故事的单位都是故事点。
32. 在缺乏面对面沟通的情况下，通常可用：视频会议，电子邮件，即时通讯
33. 可提高团队动力的步骤包括：
（1）共度黄金时间，团队成员可在个人层面上了解他人一次营造社区氛围
（2）提供反馈，指导和训练。赞扬和感谢团队成员的出色工作，同时为技能和能力提升提供指导和训练。
（3）授权，授权团队成员做关键决策，在此期间，建立信任并显示领导对团队能力的信任。
34. 每一项迭代通常产生的工作产品是完美整合的，迭代往往持续2-4周，期间不断的进行验证和确认，以确保产品的质量。
验证，是为了确保产品的执行符合客户的描述需求。
确认，是为了证明产品的执行符合预期。
有时一个产品可能是依照规范完美整合，即可通过验证。但它不符合客户的目标，即不能通过确认。
35. 4个敏捷宣言：个体和交互，遵循计划，客户合作，响应变化
个体和交，互胜过过程和工具。
工作团建，胜过全面文档。
客户合作，胜过合同谈判。
响应变化，胜过遵循计划。
36. 价值成本矩阵：基于价值分析的方法
致力于了解由客户定义的价值，与产品中的不同部分（比如特性和任务）之间的关系是如何的。
特性通常以基于价值和风险的优先级得到优先处理。
37. 常见的问题解决技能：
大声提问
再次讨论问题
5Y
沉没成本谬误
故意持不同意见的人
保持善良，回放
提问探究性问题
反映式/主动式聆听
38. WIDETOM
W 等待
I 库存
D 缺陷
E 额外流程
T 运输
O 过度生产
M 动态
39. 最小可售功能MMF：
是一个最小和可市场化的软件特征或者产品特征。
简单和小。
拥有部分价值，无论是产生收益或节约成本，都可进行市场化或销售。
为客户和用户增加价值的最小功能单位。
40. WIP：是指材料或部分已开始生产但还未完成的产品。
精益生产理论，是指估算浪费，其中一定义的浪费类型是库存，也指限制WIP 。
减少库存的一个方法是通过移除最慢的机器或处理器（系统瓶颈）来减少WIP。
敏捷致力于通过在开发新特性前完全完成所有特性的WIP限制来控制WIP。
一项迭代或冲刺可以想象成可开发若干数量特性的一个过程。
在这个类比中，WIP限制相当于冲刺待办事项。
通过保持WIP限制等同于冲刺待办事项，在冲刺审阅时所有的特性都应当完成。
41. 理想时间：
除了用故事点来估算用户故事的相对尺码，还可以用理想时间。
代表时间量，即不受会议，个人生活，非工作日或其他团员，障碍和分心的干扰的情况下，相对于待办事项中其他用户故事，单独个人建立，测试和发布用户故事所花的时间。
42. INVEST：
independent
negotiable
valuable
estimable
small
testable
43. 0故事点是开发团队最小的努力
44. 基于价值的分析：
致力于了解由客户定义的价值与产品中的不通部分之间的关系是如何的。
特性通常以基于价值和风险的优先级得到优先处理。
通过风险-价值指标 和 成本-价值指标，使用MoSCoW 和 Kano方法，可执行优先级。
45. 干系人管理：
通常在引导原则和价值的背景下定义。
干系人，是任何对项目感兴趣的人。
干系人管理 的 10个原则：
（1）干系人的利益点需要随着时间而趋于一致
（2）我们需要一个志愿者原则-联合干系人并经营关系，而不是留给政府
（3）我们要找到同时让各个顾客满意的方法
（4）我们所做的都是为服务顾客，我们从不以一个人的利益换取其他人的利益
（5）我们充满目标完成对干系人的承诺，我们充满抱负实现我们和他人的梦想
（6）我们需要和所有干系人彻底的沟通
（7）干系人包括有姓名样貌的成人和小孩儿，错综复杂
（8）需要概括市场营销方法
（9）我们与首要和次要干系人接洽
（10）我们不断监督和重设计过程变得更好去服务干系人。因为干系人的参与对项目成功很重要。
46. XP 极限编程：
代码建立后即集成到完整代码库。
由此集成后，代码库和整个系统即简称和测试完成。
持续整合只是提高快速软件交付和集成缺陷早期探测的一个极限编程的原则。
理论上是指随时有可传输的工作产品。
XP可以不用提交比以前完成的迭代版本更多的故事点。
XP鼓励团队只做一次。
XP实行相比别的方法更短周期的迭代。
以编程人员为中心的敏捷架构，注重小而迅速的发布。
强调以下原则：
（1）结对编程
（2）可持续速度
（3）不断自动测试
（4）有效沟通
（5）简单性
（6）反馈
（7）勇气
（8）集体所有
（9）持续集成
（10）激励工作
（11）共享工作空间
（12）现场客户代表
（13）使用隐喻说明概念
47. MoSCoW 技术：
用在敏捷。
取优先排序用户故事和创造故事规划图的。
吧用户故事以降序进行优先顺序排列。
48. 敏捷中scrum框架的基石：一直存在一个理论上可传输的产品。
对于团队和产品负责人来说，有两点很重要：
（1）定义“完成”
（2）中介状态下需要以何标准考虑用户的特性和功能
48. 对优先级的最佳定义：基于价值对产品特征进行相对排序
49. Kanban:
告示板或信号板。
一个及时的库存控制调度系统。
产品流程只有在收到命令信号时，才执行。
用这种方式谨慎控制库存，确保了没有机器生产多余或无序的产品。
看板应用于敏捷中，以帮助控制工作流。
50.一块敏捷任务板通常跟踪的是 基于用户故事的任务 的流程。
典型的敏捷任务板跟踪和监控的，是为活跃的迭代所选择出的任务。
一个目录中包含迭代期间所选择的所有开发任务。
每一个任务都有一张相关卡片，放置在任务板的其他几个目录中：需要做，在进行，准备测试，完成。。。
根据当时的任务状态。
不同的团队会使用不同的目录，主要是依据项目的需求和他们的偏好。
51. 敏捷中，项目章程：
是重要的管理文件。
需要所有干系人的参与。
虽然专家建议章程不超过1页，但是因为所有的干系人必须参与进来并且达成一致意见，所以创建项目章程是分厂具有挑战性的。
项目章程授权团队从事该项目。
授权项目的预算。
提供团队需要考虑的里程碑。
项目章程包括3个关键信息：
（1）前景：“为什么”，项目的理论基础
（2）任务：项目的“什么”内容，并说明团队达到预期前景所要做的内容
（3）成功标准：管理的指标，定义项目“如何”是成功的
52. 滚动计划（计划前滚动）：
包括部分波动性和阶段性的计划，尤其是在大型复杂的项目中作用明显。
只有未来几个迭代会做细节计划，而时间较遥远的迭代则只作高层次计划。
逐步完善则假定细节和需求会逐步得到改良，并且会适时融入到计划流程中。
53. 敏捷中，控制限度：
是通过设置一个客观的限度，来指明一个过程是否受控制，或者是否稳定，或者是否无缺陷。
三个西格玛的控制限度：通常用在休哈特控制图上。
一个西格玛是指一个标准偏差。
所以三个西格玛是指在正负方向上均离平均值三个标准偏差的限度。
这种限度适用于能获取正泰分布曲线的普通数据。
54. 通过回顾，有助于敏捷团队促进简单而有效的沟通。
PMI关于沟通的定义：
（1）沟通计划：确定项目干系人信息和沟通的需要
（2）信息分布：适时的提供给项目干系人需要的信息
（3）绩效报告：手机，分配绩效信息，包括状态报告，进展衡量，预告
（4）管理项目干系人：管理沟通，去满足要求还有和项目干系人一起解决问题
从敏捷的角度而言：团队间的沟通建立在过程中，通过协作，信息散热器，日常站立会议，回顾等促进。
55. 验收测试驱动开发 ATDD：
需要编程人员在产品代码前编写出测试。
其中的测试，，旨在验证预期软件中的特性和行为。
验收测试驱动开发的迭代的4个步骤, 4个Ds：
（1）Discuss 讨论
（2）Distill 提取
（3）Develop 开发
（4）Demo 示范
55. 站立会议：
鼓励所有团队成员占理进行会议，以确保会议的效率。
讨论取得的进展，以及阻碍进展的问题或障碍，下次会议之前将要实现的事情。
56. 有效的需求层次结构，从大到小：功能，用户故事，任务
57. 哪项交流方式效率最高，内容最丰富：面对面
58. 敏捷建模的目的：以一种勉强足够的方式，捕捉设计的意图。
59. 冲突级别？1级，3级。。。。
60. 保留收益 Retained Revenue：
开发新产品特征或服务，以防止现有客户停止使用现有产品，期间保留下来的收益。
新收益 New Revenue：
向新客户销售产品或服务期间实现的新收益。
额外收益：
向现有客户销售新产品特征或服务期间实现的额外收益。
61. 一个完善的站立会议的重点特征：
（1）同辈压力：团队靠大家，同辈的期望可带动进步
（2）密切配合：团队应该理解每日站立会议中简洁的必要性，由此团队才有效益
（3）细在专注：团队应该理解对专注的必要性并独立工作
（4）每日承诺：团队应该理解对每人每日承诺的价值所在，并兑现这些承诺
（5）辨别障碍：团队应该集体意识到每个人的困难，由此团队可集体尝试解决
62. 商业论证：
敏捷项目管理中重要的起步点。
对项目的构想，目标，达到目标的策略，重大事件，所需投资和预期回收所做的简明概要文件。
商业论证向客户阐明该项目为什么和怎么样会带来价值。
63. 集中办公，神偷沟通，在团队成员之间可以增强：对问题，想法，信息的流动。
64. 用户故事特性：角色，功能，效益
65. 如何计算过程效率时间？
66. 风险消耗图：
可以解释项目团队在 interation 0 （项目早期部分）所做的工作
67. 增量交付的敏捷概念：
项目是按块构建和评估的。
这些块在项目结束时包含完整的产品，包括在过程中产生的商定的变更请求。
68. 客户或业务代表参与工作的优先级划分，主要好处：
更好的反映企业的需求和项目的需求。
69. 一个敏捷项目，通常是按照自上而下的方法去估算。
当估计敏捷项目，宏观方法是常用的。
首先是高级估计，接着是详细估计
70. 估算开发用户故事的相对工作量时，可以用：理想天数，故事点。
敏捷团队应该约定使用同一种估算方法。
因为这两种方法使用不同的测量单位。
71. scrum中的迭代计划会议（在每次迭代开始时进行）应该不长于：8小时
72. 重构：
对代码进行重组，使得代码更有逻辑并更易于维护，它不会影响效率和效益。
经过重构，软件将被更好的组织。
73. 高带宽沟通的例子：面对面交流
74. 故事点的定义：分配给迭代订单的度量单位 （或者说分配给用户故事的度量单位）
75. 现值PV：计算当前值，没有考虑成本
净现值NPV：计算时扣除了成本
76. 最适合的敏捷团队规模：7+-2，也就是5~9个人
77. 团队基本准则适用于所有项目成员，也是非正式的。
不是由敏捷专家编写的。
78. 不同的“创新游戏”：
购买功能
79. 力场分析：
寻找推动和阻碍变化的因素，并给因素分配编号，以了解两边的力量的总和。
80. 创建人物：用来模拟与系统的交互，以便收集需求。
可用于考虑不同的群体与他们的产品交互会怎样。
81. 史诗故事：
一个大型故事，可能横跨几个迭代周期。
也被称为一种能力。
82. 测试驱动开发：
先定义验收测试，然后围绕这些测试实际模块，等级和功能，软件根据怎样会被接受这一天梯而编写。
当按此正确完成后，软件肯定能通过测试并被验收。
软件应该按照如何会被接受的前提，而编写。
83. 相对规模估计：
估算某件事相比其他事情，需要更多或更少工作量的一种方法。
比如团队在估算软件工作量时，按照工作量从大到小的顺序，把故事贴在墙上。
84. 近似估计：
团队将工作量和其他事物进行对比。
比如 衬衫尺寸，咖啡杯大小等。
85. 敏捷的一个主要宗旨是，软件由集体共同维护。由团队负责。
86. 线框图：
一种无须实际功能或代码，就能演示界面的快捷方法。
也是向用户展示他们能够理解的概念的快速方法。
81. 时间盒：
管理某个时间被限定的项目的一种方法。
只要在规定时间内通过验收的功能包含在时间盒内。
使用时间盒的项目，仍然使用迭代完成工作。
时间盒帮助团队保持一种紧迫感。
时间盒使风险从客户价值上转移到技术难度上。
82. 戴明：推广了 计划-执行-检查-修正， PDCA循环
83. 可用的软件应该也具有全面的文档。
敏捷中，对文档的期望水平经常被描述为刚好足够。
84. 持续集成：所有代码变化要每天（每小时）提交和测试
不一定是团队共享一个代码库。可能创建多个临时代码库。
每天提交新功能。合格概念，最接近持续改善概念的表现。
85. 挣值管理 在迭代时被获取和用于沟通。
86. 发起人的任务：
为项目提供资金。
为功能和进度提供里程碑级别的目标。
87. 客户或产品负责人的任务：
提供产品信息和产品路线。
88. 周期：完成一个用户故事的时间
应该随着迭代器的推进，一直苏欧安，直到其达到最佳水平。
迭代的持续时间：应该是一致的，不建议随着时间推移发生变化。
开发速度：团队在一个迭代器能完成的故事点。加快是好事。
89. 燃烧图
燃烧率，是一个迭代期间团队花费金额的总和。
迭代4和5中，费用迅速上升，可能的原因：
团队加班或人员增加。
补：燃烧率和生产力不会直接产生关联。
低效率会影响速度而不是燃烧率。
90. 团队管理迭代未完项。
客户或产品负责人管理产品未完项。
91. 敏捷主题：
一系列故事，一个迭代或一个版本背后的功能推动力。
补充：
商业论证：驱动或判断项目的主要事情
92. 产品路线：
在愿景声明之后创建的文档。
比愿景声明详细，但不包括用户故事的细节。
显示目标版本的高层次特性，包含的细节比愿景声明多。
93. 产品负责人参加的会议：
发布计划会议
每日计划会议
迭代计划会议
不太有可能参加：迭代回顾会议。
这是核心团队的会议，团队自查自己的工作。
94. scrum的三大支柱：
可视性
检验
适应型
95. 技术债务：
发生在团队推迟了最终必须要做出的决定或行动时，这是难以接受的。
补充：
基本准则不一定包括编码标准。
96. 一个冲刺结束，接下来要做：召开迭代回顾会议
97. 将干系人引入信息发射源，可能满足干系人询问目前的项目状态。
98. 团队才刚开始迭代Ho，在这次迭代中，没有新的功能被开发。
迭代H也被称为加强迭代，没有新的功能被开发，而是已有功能要测试。
99. Scrum合作会议：
允许不同团队来参加。
以协调团队之间的工作。
这是Scrum项目集的理想状态
100. 迭代：
是团队完成一组公祖宝的承诺。
一旦迭代开始，尽量保护迭代是的团队能够实现承诺。
迭代一旦开始之后，迭代未完项就应该保持不变。
101. XP实践：
一共12条。
如果不能应用所有，建议运用前6条。
102. 梳理故事，在产品未完项阶段。客户和产品负责人的职责。
103. 史诗故事：需要分解的大型故事。
这些基本上可以在产品未完项的底部找到。
当它们被进一步分解后，则会逐渐移向顶部。
104. 冲刺不是仪式，是核心工作发生的阶段。
仪式类似于会议。
105. 敏捷项目管理和传统项目管理的主要不同点：
敏捷主张适应。
传统项目主张预期。
106. 产品未完项中，顶部条目的定义应该很明确，底部的可能定义得不太明确。
大型史诗故事可能在产品未完项列表的底部，并将随着向上进展而分解。
最重要的且未开发的用户故事，应该排在产品未完项的顶部。
107. 探测：
用一个快速试验来解决问题。
而不是永无休止的讨论。
108. 发布计划：
不是固定不变的，可以依照团队的开发速度和优先级排序做出调整。
一个发布版本可能包含多个迭代。
补充：迭代代表了团队做出的承诺。
108. 精益的第一三原则：尽量推迟决策
109. 成本估算：
主要是根据团队的燃烧率和速度，产品未完项，发布计划等得出的。
110. 哪种比较在敏捷中最有意义：两个团队的投资回报率
111. 敏捷中，如何制定进度计划？
通过估算故事点，开发速度，优先级。。
瀑布模式中制定进度计划（？）：通过分解和估算任务，通过分析任务和确定相关性
112. 敏姐团队和外部干系人沟通的主要方式：信息发射源
113. 时间盒法，来划分了版本的发布时间，但约束了团队。
尽管不是一种特别消极的方法。
它只是规定时间上不能灵活变化，但范围可以变化。
114. 哪种环境和敏捷项目最搭：复杂的且需求大部分不确定的项目。
115. 风险调整未完项：
按照风险而不是按照价值进行排序。因此跟产品未完项有不同的顺序。
风险估算方法：定性，定量
潜在的风险未完项，也是针对未来的。
116. 精益的几个核心原则：
全盘检视
尽可能玩决策
构建完整性
不包括：尽早测试
117. 积极倾听，包括：
倾听
理解，
保留（保持），
积极响应
不包括：记录
118. 敏捷团队玩创新游戏，最主要的目的：获取需求
119. 哪个管理方式最接近敏捷：团队
120. 计划游戏：
是一种XF的实践。
用来书写用户故事，并进行评估。
最主要的目标：最大化价值。
121. 工程任务：
一般在迭代计划期间创立。
这期间团队把用户故事分解成具体的开发任务。
122. 产品负责人的主要职责：确保产品达到其投资回报率。
123. 技术债务：推迟必要的技术决策或实施的累计成本。
124. 术语 DRY： “不要重复你自己”
125. 系统开发生命周期 SDLC：
实际上是瀑布开发模型的代名词。
补充：
敏捷项目也用戴明环。
敏捷在小型迭代中使用戴明环比瀑布项目中使用的多。
126. “比喻”：是极限编程XF的第三个原则。
127. 敏捷工具：
能使团队聚焦于敏捷原则，增强团队意识的任何软件或组织。
版本控制软件，属于敏捷工具。
128. “教练”，提示了很大可能是说 极限编程XF的情况。
129. 投资回收期：
较小的数值比较大的数值，更令人满意。
130. 燃尽图：
是描述范围和进度的一种形式。
131. 速度：一个迭代周期内团队完成的故事数。
132. 敏捷和看板是精益的子集。因为它们被命名为精益思想的实例，共享精益概念。
比如：关注价值，小批量，消除浪费
133. 敏捷技术和方法，能有效的管理颠覆性技术，范围变更和项目风险。
134. 延迟开发直到设计完成，是一种瀑布方法。
135. 使用看板可以帮助管理工作。
136. 频繁的回顾，可以让团队头脑风暴哪些工作进展顺利，哪些出错，从而真正促进过程改进。
137. 敏捷，可以被看作：一种方法，手段，实践，技术，框架。
取决于它的使用环境。
138. 迭代的持续时间是有时间限制的，并且不能被扩展。
所有没完成的故事，都需要返回到产品待办事项中，并与待办事项中的其他故事一起重新排列优先级
139. 看板提供了一种方法来可视化工作流程，使障碍容易可见，并允许铜鼓哦调整在制品在管理流程。
140. 如果不确定新的业务在实践中如何工作，请创建一个带有评估标准的概念，以探索所需的结果。
141. sprint的规模，需要以客户价值和满意度最大化为前提来确定，需要更多的信息来确定最佳的冲刺持续时间。
142. 看板和敏捷：都关注于交付价值，尊重他人，最小化浪费，适应变化，持续改进。
项目团队有时会混合各种方法来实现项目目标。
143. 问题解决步骤：
定义问题，
分析根本原因，
生成可能的额解决方案，
选择最佳解决方案，
执行解决方案，
验证解决方案的有效性。
