第六章 pmp易于混淆概念解析 Part 2

$\color{red}{ 二十一：风险 vs 问题}$

$\color{red}{ 二十二：规划风险 vs 应对策略}$

开拓 vs 提高：前者100% 后者提高概率

回避 vs 减轻：前者消除，后者降低概率

$\color{red}{ 二十三：风险再评估 vs 风险审计}$

风险再评估：

• 属于控制风险

• 识别新风险，确认旧风险，清理过期风险。$\color{red}{（强调识别，确认，清理）}$

风险审计

• 属于监督风险

• 检查风险应对措施的有效性。$\color{red}{（强调过程）}$

CAB：才能调整成本绩效基准 选：D

$\color{red}{ 二十四：四种分解结构}$

资源类别（包含人力资源分配管理者，工人【初级，中级，高级】）

工作范围

风险类别

明确职责

$\color{red}{ 二十五：四个审计}$ $\color{orange}{！！！考点}$

• 质量审计：执行过程组，检查是否遵循过程
• 风险审计：监控过程组，检查风险管理（风险过程及应对措施）
• 采购审计：监督过程组，检查采购过程（采购过程【完整，正确，有效】及总结经验教训）
• 配置项核实与审计：公司资产例：如电脑核查cpu型号 存储空间配置项等

$\color{red}{ 二十六：行政收尾 vs 合同收尾}$

• 合同收尾（对外交接，货款两清）---> 行政收尾（对内交接，释放资源，总结经验）

$\color{red}{ 二十七：相关方管理计划 vs 沟通管理计划}$

• 相关方管理：强调相关的人的支持（相关方的$\color{red}{识别，照顾，分析，跟踪}$）

• 沟通管理：强调信息传递（传递内容的$\color{red}{足够，及时，准确}$ ）

• 相关方管理计划：调动相关方参与制定的计划

• 沟通管理计划：描述项目如何沟通制定的计划（计划结构化及明确相关方沟通需求）

$\color{red}{ 二十八：八大会议}$

• 项目启动会：启动阶段（制定项目章程） --> 启动结束，开项目启动会（发布章程，任命PM，调配资源）
• 项目开题会/项目开工会：规划阶段（制定管理计划） --> 规划结束（团队认识，誓师， $\color{red}{获取相关方支持}$ ）
• 规划会议分析：规划风险应对
• 状态评审会：监控风险
• 投标人会议：潜在卖方理解买房需求 --> 提交投标书之前
• 评估会议：总结经验教训 --> 项目结束阶段

• 开工大会目的：获取相关方的支持及承诺
• c

• c

$\color{red}{ 二十九：管理质量 vs 控制质量 工具}$

同 第十六讲：质量管理vs控制质量

$\color{red}{ 三十：矩阵}$

• 常考如下：
• 需求跟踪矩阵
• 责任分配矩阵
• 概率影响矩阵
• 相关方参与度评估矩阵

$\color{red}{ 三十一：四种生命周期}$

总结：

• 预测性：
• 需求明确，风险小项目，一次性交付
• 迭代性：
• 变更频繁，强调优化质量，一次性交付
• 增量型
• 变更频繁，强调交付速度，频繁交付
• 敏捷性（含迭代型，流程型）：
• 兼容迭代型及增量型，变更频繁，强调频繁交付及优化质量，频繁交付（使用短周期）
• 迭代型敏捷：时间盒相等，频繁交付
• 流程型敏捷：时间盒不等，按流程

分析：

D 敏捷不适合周期长 pass

$\color{red}{ 三十二：燃尽图 vs 燃起图 vs 风险燃尽图 vs 累计流量图}$

一：燃尽图：

• 用户故事点数，随时间逐渐降低
• 反映项目进度（时间、工作量），项目范围变化不能显示
• 例如：某天进度没有减少，可能并非没工作，只是做了范围外的工作

一：燃起图：

• 用户故事点数，随时间逐渐递增
• 迭代需求累计完成情况，可以显示项目范围

一：风险燃尽图：

• 风险问题，随时间逐渐降低
• 查看风险管理绩效

一：累计流量图：

• 各任务状态此消彼长（完成增多，待办变少）
• 分析项目问题（约束，瓶颈），预测完成时间
• 直观体现任务中的任务状态（部署，测试，开发，分析，待办）
• 体现任务状态的，不是tm分析用户流量的

$\color{red}{ 三十三：敏捷中的计划}$

敏捷计划	内容
一：敏捷愿景	项目章程中记录，敏捷第一层计划
二：产品路线图	概述产品层级，近期项目发布版本，大致范围（关注目标非细节）负责人：PO 【周期：6个月更新一次】
三：发布计划	展示产品预期发布的中长期计划，交待用户故事代办事项 负责人：PM 【周期：3-6个月】
四：迭代计划	较短研发周期，一个项目包含多个版本，每个版本由多个迭代组成，迭代计划关注从产品代办事项列表中，选取高优先级用户故事，纳入当前迭代计划 【周期：2-4周】
五：每日站会	关注昨天做了啥？今天要做啥？遇到啥问题！【周期：每天进行】

$\color{red}{ 三十四：计划扑克 vs 亲和估算}$

计划扑克

理解：

• 估算技术/ 获取一致性结果
• 参与者同时出牌（防止从重），展示自己的牌面，通过多轮交流得到近乎一致的结果。类似德尔菲，只不过他不是匿名，但是也同时出牌也避免的从重。
• 如果多轮仍然无法达成一致，则 “取大为先” 取出较大的估算值作为结果

运用时间：

• 场景一：项目正式启动前，或是第一次迭代中
• 场景二：开发迭代中书写新用户故事后，确定故事点之前

亲和估算：

• 理解：
• 估算技术 / 适用于批量用户故事快速估，应用于大型产品代办事项
• 例如：用户故事难易程度分级，分别将s m l xl 写在会议墙上，参与者依次把自己的用户故事，贴在相应的尺码上

$\color{red}{ 三十五：scrum中的会议}$

ps：每个Sprint（译：冲刺）

$\color{red}{ 三十六：产品路线图 vs 故事地图}$

一：产品路线图/产品地图：

定义：产品发布，产品主要组件可视化概述

作用：提供相关方快速查看 主要发布点 及 该发布点计划功能 的沟通工具

拥有者：PO

属性：描述产品演变过程，项目层面粗颗粒度计划，关注目标非细节

二：故事地图：

定义：所有用户故事上墙，团队讨论，产出需求进行开发（这些用户故事属性划分，为骨干，行走的骨架，额外属性等）

作用：客户价值 优先级排布 的工具

属性：故事地图对比产品路线图是 更优选项

$\color{red}{ 三十七：产品Backlog vs 迭代Backlog}$

一：产品Backlog

理解：项目所有产品待办事项列表（需求池）

属性：PO可以编辑

二：迭代Backlog

理解：本轮Sprint代办列表，

属性：团队可以编辑

$\color{red}{ 三十八：PO vs SM}$

在敏捷项目中，BA（Business Analyst）的职责主要是协助团队理解业务需求，并将其转化为可执行的任务。