PMP测试题

敏捷

三种角色

• PM SM DEV TEAM

• 产品负责人负责确保工作按照领导层面的指示方向和产品愿景展开

• 产品负责人发现或了解一个新的需求时,第一件事就是更新产品待办事项列表

• 产品负责人会见内部和外部的利益相关方,以确保即将到来的冲刺的优先级是正确的

• 相关方要了解项目状态,可以看信息发射源,进行敏捷实践,不一定要找产品负责人

• 产品负责人对待办事项列表排序是为了更好的理解和吸收利益相关方重视的内容

• 敏捷中的变更是由产品负责人对产品待办事项列表进行排序的

• 产品负责人的主要工作是确保团队从事最高价值的工作.首先要做高风险高价值的事情.

• 在冲刺过程中外部相关方希望开发团队对应冲刺待办事项列表以外的工作，必须要首先通知产品负责人，由产品负责人进行沟通和决策

• 产品负责人负责决定待办事项的优先级，而开发团队在冲刺过程中也只做冲刺待办事项列表中的工作

• 项目经理和产品负责人在确定可行的产品迭代计划和优先级时,需要先定义产品的开发方向,需要查阅发布计划

• 针对问题召集会议讨论解决方案，应该是SM和TEAM的职责，并非产品负责人

• 产品负责人要求重新安排挤压工作项的优先级；安排工作项的优先级是产品负责人的职责，所以应该遵照产品负责人的意见重新排列优先级

  ---

• SM 是Scrum框架中开发团队和流程负责人的教练

• 在敏捷实践中,项目经理重要的核心是消除障碍

• 针对问题召集会议讨论解决方案，应该是SM和TEAM的职责，并非产品负责人

• “团队工作速度下降”,针对这个问题Scrum主管应把问题交给团队，由团队自行处理和解决，回顾和分析工作速度下降的原因，找到解决方案

• 引导,知道和帮助团队消除障碍,团队应关注项目,不应该拉上团队一起解决障碍.

---

• 将工作项添加到冲刺的行为是TEAM决定，不是产品负责人
• 任务列表是团队为实现用户故事需要完成的各项工作的列表.是开发团队的文件.
• 产品规划和交付的具体工作,可以委派给团队成员,项目风险管理也是产品规划和交付的一部分
• 敏捷团队的属性之一就是跨职能团队成员为完成任务，整合所有工作活动

三种工件

• 产品backlog 迭代backlog 产品增量
• 用户故事待办事项列表显示了项目上还有哪些工作要做
• 敏捷发布计划是根据业务目标,依赖关系和障碍来确定需要开发多少以及需要多长时间才能完成一个可发布产品
• 敏捷发布规划规定了发布迭代的次数和冲刺的次数
• 迭代是有时间限制的,团队只需完成迭代计划的内容.将审查附加功能放在下一次迭代中完成.
• 冲刺时长在开始冲刺后不会改变
• 敏捷实践使用产品列表,产品增量将工作划分为多个版本

五种仪式

- 迭代 迭代计划 每日站会 评审会议 迭代回顾

• 每日站会不解决问题

• 每日站会参加人员: devTeam必须参加 ,Scrum主管可选择参加

• 每日站会规定的时间盒是15分钟.

• 每日站会团队以某种方式’'过一下"看板或任务板,团队中的任何人都可以主持站会

• 每日站会能以最短的时间获取第一手信息,比信息发射源更及时

• 冲刺时长在开始冲刺后不会改变

• 冲刺评审会议是现场展示已完成工作的会议,未完成的工作不进行评审.

• 迭代演示会上暴露的问题或者新需求，应该进入产品待办事项列表，确定优先级，最紧急的安排进入下一个迭代。

• 回顾是一个重要的实践,能让团队学习,改进和调整其过程

• 回顾总结会通过审查之前的绩效来进行绩效改进

• 回顾总结会的三个步骤: 反思–>改进–>计划. 完成三个步骤下一步结束会议

• 冲刺回顾会议的参加人员: PO SM devTeam

  ---

• 不断优化执行效率属于PDCA循环.

• 待办事项细化会议:把整个故事的概念呈现给团队。团队进行讨论，并根据需要将其细化为许多故事

• 待办事项细化会议:项目需求的逐步阐述 或 团队审查,更新和编写需求以满足客户需求的持续活动

• 团队要专注于每个迭代的软件增量的质量，也就是专注于一个迭代的小批量产品的质量

五种价值观

• 勇气 开放 专注 承诺 尊重
• 敏捷的项目章程由高级管理层签署
• 问题比较小的情况下,让团队自己解决,可以促进他们的技术能力和协作能力
• 敏捷领导尝试将团队的个人目标和个人动机与团队实现项目目标的进度保持一致
• 五拳投票发中握紧拳头意味着该成员不同意决定(give me five )
• 仆人式领导善于激励项目人员,把问题提出来,让团队自己解决

其它未分类

• 口诀

  口诀
  清障碍,找教练	对客户,找po
  优先级,找PO	有评审,找PO
  开站会,不讨论	要总结,找回顾

• 使用信息发射源是敏捷项目独有的

• 产品路线图显示了计划合适完成工作

• 刺探是项目中的一个短时间暂停,有固定时长

• 测探期间,团队开展研究或对解决方案的某个方面进行原型设计,以证明方案的可行性.
  - 看板方法通过限制在制品将提高工作效率和质量

• 看板方法能够推动和实现整个系统中工作流的可视化，让每个人都可以看到信息，从而确保工作流和价值交付的持续性。

• 任务板是显示在制品的最佳工具

• Scrum of Scrum(sos) 由多个scrum团队所使用的一种技术.

• SoS的目标是确保团队协调工作并清除障碍，以优化所有团队的效率，可以帮助多个敏捷团队的项目解决问题

• 频繁及持续的整合作用于一个敏捷团队中，类似多个敏捷团队的情况，持续整合会减低团队效率，使整合时间的占比在团队扩大

• 敏捷团队使用信息发射源来确保工作的透明化

• 信息发射源通常要放在一个显眼的位置,以便所有团队成员和利益相关方能看到最新的项目信息

• 工作软件大于流程和文档

• 团队没有掌握敏捷方法的技能,培训并指导团队使用敏捷方法

• DOD完成的定义,明确团队成员在某个冲刺必须完成.质量标准也在DOD中定义.

• 剩余故事点的燃尽图

• 迭代燃尽图 跟踪了迭代中剩余的工作/描述了迭代中计划的工作/描述了迭代中预计剩余工作

• 显示已完成故事点的燃起图

• 敏捷PMO可以制定和实时标准,提供用户故事,测试案例,积累流程图等模板

• 发布计划是对整个产品发布过程的展望,是开发团队交付一个可以工作的软件给团队外部人员使用,以满足他们的目的

• 迭代计划是发布计划的进一步计划,只是对一次迭代的展望.只有Spring开始时才开始做迭代计划

• Scrum待办事项列表是所有工作的有序列表,它以故事形式呈现给团队,并根据需要进行不断的调整和细化

• 系统交互图是收集需求的工具

• 速度不应该被比较,因为团队可以有不同的项目规模

• 识别风险的工具技术: 根本原因分析/清单/提示列表

• MoSCoW技术:必须有，应该有，可以有，不会有 Must have, Should Have, Could Have, Won’t Have

变更

• 在基准确认之前,变更无需正式受控于实施整体变更控制流程,先讨论,然后做出决策.
• 基准还没确定,重要的需求可以直接考虑纳入
• 团队内部提出变更(发现问题),先分析影响,然后再提交变更.
• 外部提出变更先沟通(了解需求,正式提出,核对信息)
• 相关方提出变更后,项目经理和团队分析变更造成的影响
• 涉及了基准优先选择提交变更请求到CCB,不影响基准的时候优先选择评估影响.
• 项目经理分析项目绩效后,可能会对成本基准和进度基准或项目管理计划的其他组成部分提出变更请求
• 审批前三步骤: 提出变更–>分析影响–>提交审批
• 变更请求有问题,应该创建一个新的变更请求,不能直接更新变更请求
• 变更请求批准前,如果提交变更和分析影响同时出现,选择 提交变更请求
• 变更请求经过了分析评估并获得批准,接下来就是实施变更请求
• 变更请求批准后要做: 1.更新变更日志 2.变更项目管理计划 3.通知有关相关方 4. 实施批准过的变更 5. 确认或验收已批准变更的实施情况
• 客户不验收,只能推迟实施,在提交变更
• 对于范围变更,问参考什么文件,范围管理计划和变更管理计划同时出现,选变更管理计划
• “新功能” 影响了范围基准,需要或得CCB批准.
• 纠正措施属于变更请求的类型之一,对纠正措施的处理要遵循整体变更控制流程.

风险

• 风险整体流程
• 项目启动阶段,还没有进入规划阶段,项目面临的搞层次风险记录在项目章程中
• 风险是有概率的(没概率的是问题). 风险是还未发生的.问题是已经发生的
  
• 风险的概率发生了变化,首先要将这种变化纳入到风险登记册中,然后在考虑应对措施
• 加权风险影响与概率矩阵
• 如果已识别的风险没有发生,就可能要从项目预算中扣除未使用的应急储备,为其他项目或运营腾出资源
• 应急储备用于已知风险管理储备未知风险.(已知-未知)
• 风险应对计划是用来应对风险,降低风险发生的概率或危害.
• 风险再评估:控制风险中需要计划地识别新风险,对现有风险进行在评估,以及删去已过时的风险.
• 次生风险:应对某个风险时带来的另一个风险.如付不应对主风险,次生风险不存在
• 残余风险:采取风险应对措施后仍然存在的风险,是没有主动应对的,被动的风险.
• 未知风险发生后应对措施叫权变措施,已经风险发生后的应对措施是实施应急计划
• 风险报告是向相关方提供风险的情况信息.
• 识别完风险后在风险登记册登记潜在的应对措施
• 风险登记册用来跟踪风险,不用来管理风险.
• 风险管理计划是描述如何安排和实施风险管理活动
• 规划风险管理的输入:项目章程,项目管理计划,相关方登记册,事业环境因素,组织过程资产.
• 规划风险管理的输出:风险管理计划
• 风险管理计划中没有风险的具体内容,属于程序性计划
• 风险被触发,首先查看风险登记册是否被识别(遇风险,先查册), 如果已识别则执行预设的应急计划, 如果未识别,则对风险进行评估,制定权变措施.
• 规避风险是指项目团队采取行动来消除威胁.或保护项目免受威胁的影响
• 风险应对措施
• 大量测试 风险缓解/风险减轻
• 规避策略用于应对概率和影响非常大的风险.
• 风向应对策略
• 在项目章程中授权项目经理可以实施自动权变措施,不必等待审批
• 应急计划:事先制定的风险应对计划,以便在风险发生或出现某些规定的情况(风险触发器)时采用,是风险主应急计划.
• 权变措施:针对以往未曾识别或被动接收,目前正在发生的风险,而紧急采取的,原来没计划过的应急措施.要经整体变更控制过程综合评估.
• 弹回计划:一般针对严重风险的备用计划.在主应急计划不起作用时才启用.
• 应急计划,弹回计划,权变措施(除紧急情况下的已授权的自动权变外)实施钱都需要经过变更控制程序,获得批准
• 风险已经过期,无需继续跟踪,关闭即可.
• 蒙特卡洛分析是其它定量分析工具的基础
• 蒙特卡洛分析是量化风险分析的一种.通过计算机模拟每增加单位预算对应的项目完成的概率变化.来分析预算变化与项目完成概率的关系曲线
• 蒙特卡洛分析曲线,可以回答发起人,从75%的概率提升到85%.需要追加的预算.
• 进行优势,劣势,机会,威胁 (SWOT)分析,是识别风险的工具
• 敏感性分析有助于确定哪些单个项目风险或其他不确定性来源对项目结果具有最大的潜在影响.
• 敏感性分析通常以龙卷风图的方式来标识.
• 定量分析的步骤
• 决策树:分别计算每个方案成功和失败的收益/损失概率.取最终预期货币价值EMV高的方案
• 决策树是用于选择的最佳方案.
• 风险审计关键字:评估风险应对措施.

相关方

• 相关方在项目中的角色,记录在相关方登记册中
• 确定哪些团体影响项目,典型的识别相关方
• 新相关方出现,先要更新相关方登记册
• 识别到一个新的相关方,需要更新他的基础信息,包括相关方登记册和相关方参与计划的所有内容.
• 识别完相关方以后,要完成相关方参与计划,从而更好的管理相关方
• 尽早的识别,并引导相关方,可以提高项目的成功性
• 凸显模型适用于复杂的相关方大型社区
• 相关方分析会产生相关方清单和关于相关方的各种信息. 利益,关系,期望,影响
• 需求跟踪矩阵,将相关方和可交付成果连接起来
• 相关方参与度评估矩阵
  • 不了解型. 不知道项目及其潜在影响.
  • 抵制型. 知道项目但抵制
  • 中立型. 了解项目,但中立
  • 支持型. 了解项目,并支持
  • 领导型. 了解项目及其潜在影响,而且积极参与以确保项目取得成功
• 相关方抵制项目,使用相关方的管理方法来进行管理
• 项目已经延迟,可能会引起相关方的不满,因此要管理相关方的期望.期望在相关方登记册中.
• 相关方意见不一致或有冲突, 引导式研讨会 与有关的相关方开会,统一意见.
• 权力利益方格:
  • 权利高,利益低,通过不断地咨询,令其满意.
  • 权利高,利益高,需要重点管理
• 开工会议(kick-off) 旨在传达项目目标.获得团队对项目的承诺以及阐明相关方的角色和职责
• 相关方始终不予响应，做为项目经理已经无法调动相关方参与到项目当中，此时需要寻求发起人的介入

质量

• 质量规划是为在整个项目期间如何 管理和核实质量 提供指南和方向

• 质量管理计划: 问题发生了,要先看计划,然后分析原因,再采取适当的纠正措施.

• 质量保证着眼于项目使用的过程,旨在高效的执行项目过程.向相关方保证最终产品可以满足他们的需求,期望和要求.

• 当客户或发起人对项目质量担心,不放心时,正确答案只能是质量管理计划.

• 质量七工具

  质量工具	作用	特点	关键词
  因果图	根本原因	分解	根本原因
  核对单	避免遗漏	避免遗漏	大量 , 遗漏
  流程图	展示一系列步骤	展示步骤	输入输出 查找原因
  控制图	监控任何过程,提前预测失控	监控任何过程,量化数据,审查	预测,稳定,过程,运行
  散点图	两个变量关系	两个变量	变量关系 相关性
  帕累托图	大量原因中的主要原因	80/20原则	主要原因,大多数原因
  直方图	确定频次
  核查表		计数	计数

• 因果图/鱼骨图/why-why分析图/石川图

• 具体原因分析,项目过程有问题选择质量审计,可交付成果选择石川图

• 项目反复出现缺陷,不是具体的可交付成果有缺陷,而是过程有问题,需要执行质量审计

• 质量成本

  • 一致性成本
    • 预防成本 (打造某种高质量产品): 培训 /文件过程 /设备/完成时间
    • 评估成本(评估质量):测试/破坏性试验损失/检查
  • 不一致成本
    • 内部失败成本(项目中发现的失败): 返工/报废
    • 外部失败的成本(客户发现的失败): 债务/保修工作/失去业务

• 质量保证任务繁重,可以通过质量审计不增值的过程,以提高效率,加快进度.

• 测试是有早期预防的作用

• 管理层对85%的质量费用负责,员工负责15%.

• 质量测量指标用于描述项目或产品属性,以及控制质量过程将如何验证符合程度,质量该怎么检查,检查到什么程度

• 通过检查来判断工作和可交付成果是否符合需求和产品验收标准

• 审计是用于确定项目活动是否遵循了组织和项目的政策,过程,程序的一种结构化且独立的过程

• 质量审计通常由项目外部的团队展开.如 组织内部审计部门,PMO,组织外部的审计师

• 亲和图用于将大量收集的事实,意见或者构思等资料按照亲和性归纳整理

成本

• 成本构成
• 估算工具
• 最粗略的估算是类比估算
• 从未做过的项目,意味着存在较大的不确定性和风险,这种情况通过三点估算来估算成本
• 三点估算公式
• 需要提交成本状态报告,S曲线能够展示成本,进度与基准的偏离情况
• 挣值分析确定成本绩效与基准是否一致.挣值代表已完成工作的价值
• 趋势分析旨在审查项目绩效随时间的变化情况,以判断绩效是否正在改善还是正在恶化.
• 偏差分析通常用于分析项目的执行情况和计划之间的差距
• 独立估算 独立估算就是让专业的人把市场上的报价算清楚

收尾

• 收尾流程
• 有收尾,找验收;遇终止,查原因,做经验教训总结.
• 项目已经完成,可以正常进入收尾,买方有新的工作需求,可以签订新的合同
• 结束项目阶段,记录经验教训,庆祝项目结束,解散项目团队
• 收尾阶段,已经通过验收,项目的范围已经实现,暴露出来的问题记录进最终报告
• 偏差分析是收尾的工具,用来总结经验教训,并不是用来做收尾决策.
• 项目做收尾,通过专家判断来决定是否继续收尾
• 经验教训总结:已经移交,接下来要测量相关方的满意.完成经验教训总结

商业环境

• 项目章程关键字:一个新项目, 新任项目经理, 项目经理的权利和责任,高层级风险
• 敏捷项目的项目章程是由高级管理层签署
• 工作环境的潜在问题属于假设与制约，应该记录在项目章程中
• 项目生命周期早期应确定目标效益.制定效益管理计划战略一致性.
• 项目还没有启动,先看商业文件,商业文件包括:商业论证和效益管理计划
• 新了解的信息哟重新进行商业论证,用来论证项目的可行性
• 项目经理不能更新商业论证,可以提供建议
• 看项目要不要开始,要不要继续就选 商业论证
• 商业论证包括 : 商业需求 ,成本效益分析
• 对商业分析/商业论证的结果，需要获得关键相关方的认可，形成共识
• 发起人没空批准项目章程,审查项目章程以查看是否有另一方可以对其进行授权
• 制定项目管理计划在开工会议之前
• 开工会议是完成自上而下的传达和自下而上的承诺,阐明每个相关方的角色和职责
• 开工会议的关键字:承诺,规划结束执行开始,传达目标

人员

• 冲突管理首先采用合作/解决问题.

• 冲突处理的三个步骤: 自行解决–>私下处理–>正式程序

• 冲突管理:在弱矩阵中,项目经理找团队的意义不大,需要找职能经理同意以后才能安排

• 冲突已经发生,应该如何预防: 1.基本原则 2.团队建设

• 团队建设工具

  工具	解释
  集中办公	作战室
  虚拟团队	适用于不同工作地点的项目团队成员
  沟通技术	解决集中办公和虚拟团队的信息交互,沟通技术至关重要
  团队建设	工作内:共同完成; WBS:项目计划; 工作外:举办活动
  认可与奖励	只有满足成员重要需求的奖励才是最有效的; 应在项目生命周期中考虑奖励,而不是完成后.
  培训	对技能的培训:培训可以作为计划的一部分,包含在进度与成本计划中

• 团队建设工具:看到技能优先想到培训.

• 团队内部的培训由项目经理负责

• 对于资源技能上的短板,通常采用培训的方式加以解决.

• 团队成员的关系问题,团队建设最有效.

• 建设团队后,通过团队绩效评价对建设效果进行评估.

• 团队建设的主要作用是通过团建提高团队绩效,进而提高项目绩效.

• 团队管理

• 紧急问题,用强迫来解决

• 相互介绍 属于形成阶段

• 形成阶段不引发冲突.

• 塔克曼阶梯 ,看到 “开始…” 一般选择 规范阶段 . 看到 “已经…” 一般选 成熟阶段

• 塔克曼阶梯理论

• 形成阶段:指导型;震荡阶段:教练型;规范阶段:参与型;成熟阶段:委任型;

• 当团队到达执行阶段时,团队成员不需要领导者的太多指导和支持;他们一起工作的非常顺利,基本可以自我指导和自我支持.

• 组建时,获取资源问题,看到职能经理一般选 谈判/协商

• 获取资源的步骤 : 谈判–>找领导–>招募

• 组织资源有限,属于事业环境因素.

• 矩阵型,项目成员可以跨过直接上级(职能经理) 与项目经理直接沟通

• 资源管理计划提供了如何分类,分配,管理和释放资源的指南.在资源管理计划中包含团队建设信息.

• RACI(责任分配矩阵)用来说明需要完成的工作与团队资源之间的关系.

• RACI矩阵对明确划分角色和职责特别有用

• RACI(执行,负责,咨询,知情)是RAM(责任分配矩阵)的一种,

• 在团队是由内部和外部人员组成的情况下,RACI矩阵对明确划分角色和职责特别有用

• 项目组织图以图形的方式展示项目团队成员及其报告关系

• 组织结构只显示汇报关系.

• 解决虚拟团队的信息交互,沟通技术至关重要

合同

• 与供应商或客户有争议,首先看合同
• 项目经理的采购绩效审查是对供应商的合同绩效进行管理的重要工具
• 合同类型及风险
• 总价加激励合同计算合同款
• 工料合同适用于,无法快速编织出精准的工作说明书的情况下扩充人员,聘用专家或寻求外部支持的情况
• 无法准确定义工作说明书选择工料合同
• 成本补偿合同适用于工作范围预计会在执行期间发生重大变更.
• 索赔管理步骤 : 谈判–>ADR(替代争议解决方法 )–>法院

沟通

• 项目信息问题都是沟通问题,首先看沟通管理计划

• 拉式沟通适用于大量复杂信息和大量信息受众的情况

• 在两方或多方之间进行的实时多向信息交互,适合采用交互式沟通

• 文化意识和文化敏感性有助于项目经理依据相关方和团队成员的文化差异和文化需求对沟通进行规划。

• 沟通与相关方的核心

  	核心	关键字	总结
  沟通	信息的正确传递	报告,信息,通知,邮件	凡信息,找沟通
  相关方	支持与抵制	支持,抵制,不满意,拒绝	不满意找计划

• 为了解决信息传递出现的问题,就找沟通管理

• 遇到相关方抵制,就找相关方参与计划或者沟通管理计划

• 沟通管理计划的关键字:信息,报告,项目状态,误解,通知,开会,上报步骤,术语表

• 上报步骤:发布信息的原因,发布所需信息,确认已收到,或做出回应上报步骤在沟通管理计划里.

• 沟通管理计划是项目管理计划的组成部分,描述将如何规划,结构化,执行与监督项目沟通,以提高沟通的有效性

• 沟通技能/沟通技术/沟通方法

进度

• 赶工:增加资源; 快速跟进:任务并行
• 快速跟进是进度压缩技术其中一种，它将正常情况下按顺序进行的活动或阶段改为至少是部分并行开展
• 进度网络分析是一个反复进行的过程，一直持续到创建出可行的进度模型。
• 关键路径:浮动时间为0
• 关键链法就是考虑了资源约束的关键路径法

其他

• 一个新的行业，一般行业的问题都找专家会更好

• 亲和图可以对潜在缺陷成因进行分类，展示最应关注的领域

• 亲和图用来对大量创意进行分组的技术，以便进一步审查和分析

• 德尔菲技术：相关专家匿名参与。对专家的答卷进行归纳，发还给专家作进一步评论。

• 焦点小组召集相关方和主题专家讨论项目风险、成功标准和其他议题比一对一访谈更有利于互动交流。

• 名义组技术，对头脑风暴的结果进行排序，以便找出更好的方案

• 优先矩阵，多个方案、多重标准、排序

• 精益六西格玛是精益生产与六西格玛管理的结合，其本质是消除浪费