项目管理PMP知识点
2025-03-10 09:23:17 1 举报PMP知识点
作者其他创作
大纲/内容
知识汇总
1.1项目基本要素
项目定义
项目是为创造独特的产品、服务或成果而进行的临时性工作。
项目特点
独特性
独特性带来不确定性；
可交付成果是独特的、可核实的。
临时性
需要收尾的几种情况
达成目标
不会或不能达成目标
没有资金
没有资源
需求不存在
便利原因
项目是临时的，可交付成果是永久的
项目组织驱动变更
项目创造价值
有形
价值
股份
无形
品牌
商誉
项目成功标准
成功标准很多，具体以哪些标准来衡量要达成共识。
项目与项目给合、项目集关系
项目集强调“关联关系”
“方式”正确；
项目组合强调“竞争关系”
“选择”正确；
了解“运营”
持续的。
重复的
项目组合>项目集>项目
项目生命周期
定义
项目生命周期，项目生命周期指项目从启动到完成所经历的一系列阶段。它为项目管理提供了一个基本框架。不论项目涉及的具体工作是什么，这个基本框架都适用。这些阶段之间的关系可以顺序、迭代或交叠进行。
按顺序排列的，而且有时会交叉重叠的项目阶段、阶段名称和数量取决于参与项目的一个或多个组织的管理与控制需要
阶段
启动
项目整合管理
制定项目章程
项目相关方管理
识别相关方
规划
项目整合管理
项目范围管理
项目进度管理
项目成本管理
项目质量管理
项目资源管理
项目沟通管理
项目风险管理
项目采购管理
项目相关方管理
执行
项目整合管理
项目质量管理
项目资源管理
项目沟通管理
项目风险管理
项目采购管理
项目相关方管理
监控
项目整合管理
项目范围管理
项目进度管理
项目成本管理
项目质量管理
项目资源管理
项目沟通管理
项目风险管理
项目采购管理
项目相关方管理
收尾
项目整合管理
结整项目或阶段
阶段关口
方法论
传统瀑布模型
严格按阶段划分，关口评审正式且周期长（如工程建设、制造业）。
敏捷开发
以迭代评审（Sprint Review）替代阶段关口，注重持续反馈而非阶段性审批（如软件开发）。
混合模式
前期严格评审（如需求确认），后期通过迭代快速调整（如硬件+软件集成项目）。
关口名称：Gate 1：立项评审、Gate 2：计划确认、Gate 3：交付物评审、Gate 4：中期健康检查、Gate 5：终验移交
生命周期的特点
成本与人力投入：项目开始时“缓慢增加”，在“执行工作”期间达到最高，项目快结束时“迅速回落”；
风险与不确定性、相关方的影响力、变更的数量：项目开始时最大，后续“逐步降低“。
变更的代价、风险的影响：项目开始时较小，后续“显著增高”。
开发生命周期
预测型；
迭代型；
增量型；
适应型（敏捷）；
混合型。
产品生命周期
引入期：市场测试，初步推广。
成长期：扩大市场份额，优化功能。
成熟期：稳定收益，应对竞争。
衰退期：需求下降，策略转型或退市。
项目管理
项目管理过程：
为完成预定的产品、成果或服务而执行的一系列相互关联的行动和活动。
五大过程组
启动
规划
执行
监控
收尾
十大知识领域
项目整合管理
项目范围管理
项目进度管理
项目成本管理
项目质量管理
项目资源管理
项目沟通管理
项目风险管理
项目采购管理
项目相关方管理
项目管理中的数据和信息
工作绩效数据；
工作绩效信息；
工作绩效报告；
项目管理商业文件
商业论证：论证项目是否值得投资
商业需求；
成本效益分析。
效益管理计划：描述了项目实现效益的方式和时间，以及应制定的效益衡量机制。
没有包含经济可行性
在项目启动之前做的经济可行性，而效益管理计划是在执行项目中
目标收益
战略一致性
收益责任人
1.2项目运行环境
事业环境因素
定义
事业环境因素(EEFs)-是指项目团队不能控制的，将对项目产生影响、限制或指令作用的各种条件。
特点
不可控；
示例
组织内部
信息技术：组织使用的各种软件都属于事业环境因素；
组织文件和结构；
基础设施；
资源可用性；
员工能力
组织外部
法律限制；
政府或行业标准；
财务因素：关税、汇率等；
物理环境要素：天气等；
组织过程资产
定义
定义：执行组织特有并使用的计划、过程、政策、程序和知识库。
特点
可以裁剪使用，需要不断更新；
示例
组织内部
过程、政策和程序
指南；
项目启动时引用《立项审批流程》
- 变更管理中使用《CCB章程》
- 变更管理中使用《CCB章程》
模板
团队沟通
组织知识库
经验教训知识库；
规划阶段参考类似项目的《风险管理计划》
- 收尾阶段更新经验教训库
- 收尾阶段更新经验教训库
以往的项目档案。
各种组织结构
职能型(集中式)：兼职项目经理(联络员)，权力“很小”甚至“没有”。
矩阵型
弱矩阵：兼职项目经理(协调员)，权力“小”；
平(均)衡矩阵：兼职项目经理，权力“小~中”；
强矩阵：全职项目经理，权力“中~大”。
项目型：全职项目经理，权力“大~全部”；
其他
有机型或简单型组织；
多部门组织；
虚拟型组织。
PMO
定义
项目经理办公室(PMO)是对与项目相关的治理过程进行标准化，并促进资源、方法论、工具和技术共享的一个组织结构。
类型
支持型：资源库，控制程度低；
小公司
提供帮助培训、支持等
控制型：控制程度中等；
行业要求高
指定政策
指令型：控制程度高。
大规模，直接管理
作用
识别和制定“最佳实践”和“标准”；
项目审计；
制定政策、程序、模板；
培训指导项目经理。
1.3项目经理的角色
定义
有执行组织委派，领导团队实现项目目标的个人。
实现目标而不是制定目标（马仔）。
PMI人才三角
技术项目管理技能；
战略和商务技能：行业知识；
领导力技能。
项目经理的几种权力
专家权力；
参照（潜示）权力；
奖励权力；
正式（合法、法定、职位）权力；
惩罚权力；
项目经理的几种领导力风格
放任型：容易失控，但有利于创新；
交易型：定目标，给奖励；
服务型：仆人式领导；
变革型：通过促进创新来提高追随者的能力；
魅力型：精神饱满、热情洋溢、充满自信、说服力强、能够激励他人；
交互型：结合交易型、变革型和魅力型的特点。
2.1项目启动
2.1.1制定项目章程
要点
授权项目经理，确立项目的正式地位。
项目经理（参与）制定，发起人审批发布；
项目经理尽早任命，最晚需要在规划开始前任命。
输入
商业文件
商业论证
商业论证论证了项目是否值得投资（成本效益分析）。
商业论证需要定期审核；
项目经理不能修改，只能提建议。
效益管理计划
事业环境因素
组织过程资产
工具和技术
专家判断；
头脑风暴；
焦点小组；
访谈；
会议管理。
输出
项目章程
项目目的、目标、成功标准、退出标准；
高层级；
项目经理的职责。
假设日志
假设条件；
制约因素。
识别相关方
2.1.2识别干系人
要点
干系人是指会受项目的积极或消极影响，或者能对项目施加积极或消极影响的任何人。
要点：定期识别项目干系人，分析和记录他们的利益、参与度、相互依赖性、影响力和对项目成功的潜在影响的过程。
输入
项目章程；
商业文件；
协议
工具和技术
问卷调查、头脑风暴(写作)：身份信息；
干系人分析：评估信息；
权力/利益方格 —— 分类信息
权力高，利益高：重点管理；
权力高，利益低：令其满意；
权力低，利益高：随时告知；
权力低，利益低：监督。
输出
干系人登记册
身份信息；
评估信息
分类信息
变更请求
2.2项目规定上（范围、进度、成本）
项目范围管理
规划范围管理
范围管理计划：如何管理范围；
需求管理计划：如何管理需求。
收集需求
定义
为实现目标而确定、记录干系人的需要。
输入
项目章程
项目章程中记录的是高层级的（概括的）需求。
干系人登记册；
协议
商业文件
工具与技术
头脑风暴；
访谈：信任和保密的环境，获取机密的信息；
焦点小组：聚焦在某一个点，同一领域，同一职能（部门）；
问卷调查：地理位置分散、受众多样化，快速完成，适合开展统计分析；
标杆对照：识别最佳实践，形成改进意见，内部外部对照，同行业不同行业对照；
投票
一致同意（德尔菲）；
避免权威，一言堂，多人分析决策
大多数同意；
相对多数同意。
独裁型决策
多标准决策分析：多个标准设置权重，权重*得分算总分；
亲和图：分组、分类；
思维导图：整合，反应共性与差异，激发新创意；
名义小组：投票、排序；
观察和交谈：难以说清楚或不愿意说清楚，挖掘隐藏需求；
引导：协调干系人差异，协调跨职能需求
JAD
联合应用程序设计，Joint Application Design）
由IBM提出的结构化协作方法，通过集中式工作坊让干系人（客户、开发团队、业务专家等）共同参与需求确认。
▫️ 核心作用
快速对齐多方需求，减少后期变更风险
生成可视化交付物（如原型、流程图）
适用于复杂度高、需求模糊的项目（如软件开发）
▫️ 核心作用
快速对齐多方需求，减少后期变更风险
生成可视化交付物（如原型、流程图）
适用于复杂度高、需求模糊的项目（如软件开发）
会前准备 → 2. 引导式讨论 → 3. 原型设计 → 4. 需求确认 → 5. 签署文档
QFD
（质量功能展开，Quality Function Deployment）
将客户需求（Voice of Customer, VoC）逐层转化为产品/服务的技术指标，通过质量屋矩阵（House of Quality）实现需求优先级排序。
选择JAD：若需求模糊且需跨部门协作（如ERP系统开发）。
选择QFD：若需将客户语言转化为技术参数（如新能源汽车功能设计）。
组合使用：先用JAD梳理需求框架，再用QFD细化关键指标。
选择QFD：若需将客户语言转化为技术参数（如新能源汽车功能设计）。
组合使用：先用JAD梳理需求框架，再用QFD细化关键指标。
用户故事。
系统交互图；
原型法：减轻返工风险。
输出
需求文件：描述单一需求如何满足相关的业务需求；
需求跟踪矩阵
把产品需求从来源链接到可交付成果的一种表格；
确保每个需求都有对应的业务目标，确保每个需求都有价值；
确保每个需求都最终得以交付。
定义范围
要点
选取最终的需求；
定义好用什么可交付成果及验收标准来满足这些需求。
输入
项目章程
需求文件
工具和技术
备选方案分析；
多标准决策分析；
引导；
产品分析。
输出
项目范围说明书
代表了相关方之间就范围达成的共识
产品范围描述；
可交付成果；
验收标准；
除外责任
创建WBS
要点
WBS组织并定义了项目的总范围；
把可交付成果分解成较小的、更易于管理的组件。
输入
项目范围说明书
需求文件
工具与技术
分解
100%原则；
责任唯一；
输出
范围基准
项目范围说明书
输入与输出的本质差异：输入是“原料”，输出是“成品”；
范围说明书的动态演进：范围说明书在规划过程中逐步细化。
范围说明书的动态演进：范围说明书在规划过程中逐步细化。
更新后的范围说明书合并至范围基准（Scope Baseline）。
WBS
WBS词典
确认范围
要点
定义：正式验收已完成的项目可交付成果的过程，确保其符合需求和质量标准。
与“控制质量”的区别：控制质量检查可交付成果是否“正确完成”，确认范围检查是否“符合需求”。
与“收尾”的区别：确认范围是阶段性验收，收尾是最终项目关闭。
输入
核验清单
1. 验收标准（来自范围说明书）
2. 已完成的可交付成果（如软件模块、设计文档）
3. 需求跟踪矩阵（RTM）
4. 工作绩效数据（如测试报告、缺陷修复记录）
2. 已完成的可交付成果（如软件模块、设计文档）
3. 需求跟踪矩阵（RTM）
4. 工作绩效数据（如测试报告、缺陷修复记录）
隐性输入
干系人期望管理记录（如会议纪要中的签字确认）。
工具与技术
检查
硬件交付、软件模块验收
决策投票
需求优先级冲突
原型演示
敏捷开发中的迭代评审会（Sprint Review）
输出
正式验收文件：
签字的《验收确认书》或电子审批记录。
签字的《验收确认书》或电子审批记录。
更新文档：
需求跟踪矩阵（标记已完成需求状态）。
变更日志（记录验收引发的范围调整）。
需求跟踪矩阵（标记已完成需求状态）。
变更日志（记录验收引发的范围调整）。
项目进度管理
规划进度管理
输出进度管理计划，指南型文件，没有实质内容。
定义活动
要点
将工作包分解为活动；
输入
范围基准；
工具和技术
分解：团队成员参与有助于得到更准确的结果；
滚动式规划。
输出
活动清单；
活动属性；
里程碑清单
里程碑不是活动，持续时间为 0 ；
是一个重要的时间点或事件。
排列活动顺序
定义
要点：在既定制约因素下获得最高的效率；
输入
活动清单；
活动属性
里程碑清单。
工具与技术
PDM紧前关系绘图法：FS、SS、FF、SF；
确定和整合依赖关系
强制性依赖
法律或合同要求的，或者由工作内在性质决定的；
硬逻辑。
选择性依赖关系
基于最佳实践；
软逻辑；
可以调整，实现快速跟进。
软逻辑；
可以调整，实现快速跟进。
外部依赖关系：
项目活动与非项目活动之前的依赖关系；
内部依赖关系
项目活动之间的依赖关系。
提前量和滞后量
提前量：相对于紧前活动，紧后活动可以提前的时间（-）；
滞后量：相对于紧前活动，紧后活动必须推迟的时间（+）。
输出
项目进度网络图
路径汇聚点和路径分支点要注意高风险。
圆形代表活动，箭头代表方向
估算活动持续时间
要点：估算执行项目所需的团队资源。以及材料、设备和用品的类型和数量的过程。
输入
活动清单（WBS分解后的具体任务）
资源日历（人员、设备的可用性）
历史数据（类似项目的实际耗时记录）
风险登记册（可能影响时间的风险事件）
资源日历（人员、设备的可用性）
历史数据（类似项目的实际耗时记录）
风险登记册（可能影响时间的风险事件）
工具与技术
A[输入活动清单] --> B{选择估算方法}
B -->|信息不足| C[类比估算]
B -->|标准化任务| D[参数估算]
B -->|高风险任务| E[三点估算]
B -->|复杂任务| F[自下而上估算]
C/D/E/F --> G[生成时间估算]
G --> H[分析资源与风险]
H --> I[输出带缓冲的持续时间]
B -->|信息不足| C[类比估算]
B -->|标准化任务| D[参数估算]
B -->|高风险任务| E[三点估算]
B -->|复杂任务| F[自下而上估算]
C/D/E/F --> G[生成时间估算]
G --> H[分析资源与风险]
H --> I[输出带缓冲的持续时间]
团队协作估算：
使用计划扑克（Planning Poker）让开发团队共同投票，减少偏差。
蒙特卡洛模拟：
通过模拟风险事件概率分布（如服务器宕机率），生成时间概率分布图。
可视化跟踪：
在甘特图中用颜色区分计划时间与实际进度，预警延迟风险。
使用计划扑克（Planning Poker）让开发团队共同投票，减少偏差。
蒙特卡洛模拟：
通过模拟风险事件概率分布（如服务器宕机率），生成时间概率分布图。
可视化跟踪：
在甘特图中用颜色区分计划时间与实际进度，预警延迟风险。
专家判断；
类比估算：速度快，成本低，不准；
参数估算：基础数据，参数模型；
三点估算（PERT）：考虑风险和不确定性；
备选方案分析；
类比估算：速度快，成本低，不准；
参数估算：基础数据，参数模型；
三点估算（PERT）：考虑风险和不确定性；
备选方案分析；
储备分析
应急储备：项目经理可以直接使用；
已知-未知
管理储备：项目经理必须通过变更流程使用。
未知-未知风险时
输出
活动持续时间估算：带置信区间的范围值（如7±2天）
估算依据：记录假设条件和约束（如“假设测试环境无故障”）
更新文档：
风险登记册（新增时间相关风险）
资源日历（标注关键资源占用时段）
估算依据：记录假设条件和约束（如“假设测试环境无故障”）
更新文档：
风险登记册（新增时间相关风险）
资源日历（标注关键资源占用时段）
制定进度计划
要点
由最熟悉具体活动的个人或小组提供输入。
输入
工具与技术
进度网络分析
一种综合技术，综合了关键路径法、资源优化和建模技术。
关键路径法
一种综合技术，综合了关键路径法、资源优化和建模技术。
关键路径越多，风险越大；
顺推和逆推；
总浮动时间和自由浮动时间。
资源优化技术
资源平衡：会导致关键路径的改变，一般是延长；
资源平滑：不会该表关键路径，但是也无法实现所有的优化。
假设情景分析
如果出现情景A，情况会怎样；
模拟
蒙特卡罗；
进度压缩
不缩减范围的前提下，缩短或加快工期
赶工：以最小的成本增加来压缩进度，加班、假人、加急，会增加成本。
快速跟进：将顺序进行的活动改为至少部分并行，会增加风险。
输出
进度基准
项目进度计划
里程碑图：显示主要可交付成果和外部接口；
横道图（甘特图）：向管理层汇报进展；
项目进度网络图。
项目日历
项目成本管理
规划成本管理
成本管理计划：如何管理成本（HOW）。
估算成本
要点：估算成本会是对完成项目工作所需资源成本进行近似估算的过程。
输入
项目进度计划 —— 进度计划包括项目可用的团队和实物资源的类型、数量和可用时间长短。
工具与技术
类比估算：速度快，不准；
参数估算：基础数据和参数模型，套公式，强调统计关系；
三点估算
PERT计划评审技术；
考虑风险和不确定；
默认使用贝塔分布：(最悲观+最乐观+最可能*4)/6；
三角分布：(最乐观+最可能+最悲观)/3。
自下而上估算：最准的一种方法，但是很慢；
备选方案分析；
储备分析
为“已知 — 未知”风险预留应急储备；
项目经理可以动用、减少或取消应急储备；
项目经理可以动用、减少或取消应急储备；
质量成本。
输出
成本估算
估算依据
制定预算
要点
汇总所有单个活动或工作包的估算成本，建立一个经批准的成本基准。
分支主题
输入
成本估算；
估算依据
协议：需要考虑将要或已经采购的产品、服务或成果的成本。
工具与技术
成本汇总
数据分析（储备分析）
建立项目管理储备的储备分析；
管理储备动用需要走变更流程；
动用的管理储备要纳入成本基准。
历史信息审核；
资金限制平衡：可能需要调整工作的进度计划，以平衡资金支出水平。
输出
成本基准：包括应急储备，但不包括管理储备；
项目资金需求：成本基准+管理储备。
2.2项目规定下（质量、资源、沟通、风险、采购）
2.2.24 制定项目管理计划
要点：“装订”所有的组成部分，形成一份综合的项目管理计划。
输入
项目章程
其他（规划）过程的输出
工具与技术
核对单
check list 可以避免遗漏。
会议
kick-off会议，规划的最后一件事情；
传达目标、获得团队的承诺、阐明相关方的角色和职责；
在会议获得相关方对项目管理计划的一致认可。
输出
项目管理计划
范围管理计划
需求管理计划
进度管理计划
成本管理计划
质量管理计划
资源管理计划
沟通管理计划
风险管理计划
采购管理计划
相关方参与计划
变更管理计划
配置管理计划
范围基准
进度基准
成本基准
绩效测量基准
生命周期描述
开发方法
需求管理计划
进度管理计划
成本管理计划
质量管理计划
资源管理计划
沟通管理计划
风险管理计划
采购管理计划
相关方参与计划
变更管理计划
配置管理计划
范围基准
进度基准
成本基准
绩效测量基准
生命周期描述
开发方法
注意没有质量基准这一说法
项目质量管理
规划质量管理
要点
识别项目及其可交付成果的质量要求和（或）标准，并书面描述将如何证明符合质量要求和（或）标准的过程。
核心概念
质量兼顾“项目管理”和“可交付成果”两个方面
质量和等级的区别
预防和检查、属性抽样和变量抽样、公差和控制界限
五种质量管理水平
新兴实践
客户满意
符合要求、适合使用
持续改进
以PDCA为基础，小改进的积累
P：Plan-计划
D：Do-做、实施
C：Check-确认（检查）
A：Action-措施（行动）
D：Do-做、实施
C：Check-确认（检查）
A：Action-措施（行动）
管理层的责任
85/15原则
与供应商的互利合作关系
总结：规划质量“定标准”
输入
组织过程资产
质量政策由高级管理层推崇
工具与技术
标杆对照
成本效益分析
一致性成本 （防止失败）
预防成本
培训、流程文档化，设备、正确的时间做事
评估成本
检查、测试、破坏性测试
非一致性（失败、缺陷）成本 （处理失败）
内部失败成本
返工、废品
外部失败成本
客户发现的，导致债务、保修、业务流失
质量成本
流程（过程）图
显示步骤和分支，帮助改进过程并识别可能出现质量缺陷或可以纳入质量检查的地方
传统7个工具
因果图
流程图
核查表
也叫计数表：理排列k 种事项，有效收集关于潜在质量问题有用数据
帕累托图
垂直条形图，用于识别造成大多数问题的少数重要原因
2/8 定率
直方图
显示频率和频次；
控制图
确认一个过程是否稳定，或者是否具有可预测的绩效
散点图
自变量和因变量；是否存在关联关系
输出
质量管理计划
质量政策
质量标准（国家标准/行业标准）
质量目标
质量方面的角色和职责
质量管理和控制活动
质量测量指标
项目资源管理
规划资源管理
要点
定义如何估算、获取、管理和利用团队以及实物资源的过程。
输入
项目章程
项目管理计划
项目文件
事业环境因素
组织过程资产
工具与技术
专家/名人理论
马斯洛：需求层次理论
人有五个层次的需求，从最低等级到最高等级依次是：生理需求、安全需求、社交需求、尊重需求、自我实现需求。通常，人们只有在较 低层次的需求得到满足后，才会追求较高层次的需求。
赫兹伯格：双因素理论
有两类因素(保健因素和激励因素)会决定人的行为
保健因素----是导致不满足感的因素，这些因素做得好不会提高激励，做得不好就会损害激励。
激励因素----是导致满足感的因素，能够真正起激励作用的。比如：成就感、责任感、得到任何和赞赏、挑战 性和兴趣、发展前途、个人成长等；相当于马斯洛需求层次理论的较高层次的需求 (尊重需求、自我实现需求)。
麦格雷戈： X 理论和Y 理论
X 理论认为只能用低层次的需求进行激励；
X 理 论 ----认为人是消极懒惰的，缺乏进取心，总是逃避责任(传统管理偏向此“人性本惰”论)
Y 理论认为人更应该受到高层次需求的激励。
Y 理论----认为人是积极的，愿意进步，愿意承担责任(现代管理偏向此“人性本善”论)
麦克利兰成就动机理论
个人不同程上的成就需要、权力需要、亲和需要、三种需要行为
管理风格
独裁型
决策快；容易出错
适用项目或阶段：低风险、范围清楚；规划阶段（尤其规划阶段的早期）、收尾阶段
适用人员：能力差、愿意服从
民主型
集体参与，能调动积极性，提高责任心；决策慢
适用项目或阶段：大多数项目；执行阶段
适用人员：能力强，有参与愿望
放任型
充分发挥员工创造力；容易失去控制
适用项目或阶段：高度创造性的项目（如科研）
适用人员：能力强，自觉性高
工具 数据表现
层级型：有助于明确高层级的角色和职责层级型
WBS：工作分解结构
OBS：组织分解结构
RBS：资源分解结构
矩阵型
责任分配矩阵（RAM）：高层次 RAM 可定义项目团队、小组或部门负责 WBS 中的哪部分工作，低层次 RAM 则可在各小组内为具体活动分配角色、职责和职权。
RACI矩阵 A只能有一个
R=Responsible (执行)
A=Accountable (负责)
C=Consult (咨询)
I=Inform (知情)
A=Accountable (负责)
C=Consult (咨询)
I=Inform (知情)
避免职责不清
文本型
角色描述
输出
资源管理计划
如何识别资源
如何获取资源
角色和职责
培训策略
认可计划
如何获取资源
角色和职责
培训策略
认可计划
团队章程
也叫：基本规则
作用：减少误解，提高生产力
由团队成员制定或参与制定，定期审查和更新
例子：会议礼仪
作用：减少误解，提高生产力
由团队成员制定或参与制定，定期审查和更新
例子：会议礼仪
估算活动资源
要点
输入
项目管理计划
资源管理计划
范围基准
项目文件
事业环境因素
组织过程资产
工具与技术
专家判断
自下而上估算
类比估算
数据分析
备选方案
项目管理信息系统
会议
输出
资源需求
估算依据
资源分解结构
项目文件更新
项目沟通管理
规划沟通管理
核心概念
PMP中的沟通仅仅指信息交换。
通过沟通活动（如会议和演讲），或以工件的方式（如电子邮件、社交媒体、项目报告或项目文档）等各种可能得方式来发送或者接受信息。
要点：基于每个干系人或干系人群体的信息需求制定恰当的沟通管理计划：量身定制、舔狗。
输入
干系人登记册；
工具与技术
沟通需求分析
分析沟通需求，确定项目干系人的信息需求，包括所需信息的类型和格式，以及信息对干系人的价值；
沟通渠道的计算：N*(N-1)/2;
沟通方法
推式沟通：发送方将信息发给特定的受众，只管发，不管是否接收到是否理解；
互动式沟通：实时多向爱那个的沟通，效果最好；
拉式沟通：接收方主动获取信息，信息量大，受众多的时候使用。
沟通风格评估
规划沟通活动时，用于评估沟通风格并识别偏好的沟通方法、形式和内容的技术。
常用于不支持项目的干系人。
输出
沟通管理计划
识别和满足干系人对项目信息要求的最好方法
干系人的沟通需求；
需要沟通的信息，包括语言、格式、内容、详细程度；
时限和频率；
授权保密信息发布的人员；
将要接受信息的人员或群体；
通用技术语表；
问题升级程序；
相关法律法规。
项目风险管理
规划风险管理
要点：定义如何实施项目风险管理活动的过程。
核心概念
一种不确定的事件或条件，一旦发生，就会对一个或多个项目目标造成积极或消极的影响；
积极和消极风险通常被称为机会和威胁；
风险的三要素：风险事件、概率、影响；
风险敞口=概率*影响；
已知-未知风险 ： 建立应急储备；
未知-未知风险 ：使用管理储备，需要走变更流程；
应该站在中立的角度：风险承受力>风险偏好 > 风险临界值；
输入
项目章程
相关方登记册。
工具与技术
相关方分析 — 通过相关方分析确定项目相关方的风险偏好。
输出
风险管理计划
风险类别 RBS；
技术
管理
商业
外部
组织
相关方的风险偏好；
概率和影响的定义；
概率和影响矩阵。
识别风险
要点
识别单个项目风险以及整体项目风险的来源，并记录分享特征的过程。
应鼓励所有项目相关方参与，团队的参与尤为重要；
识别风险是一个迭代的过程，迭代的频率和每次迭代所需的参与程度应在风险管理计划中做出规定。
输入
工具与技术
头脑风暴；
访谈；
核对单
从类似项目和其他信息来源积累的历史信息和知识来编制核对单；
确保不要用核对单来取代所需的风险识别工作；
注意考察未在核对单中列出的事项。
根本原因分析
问题放在鱼头的位置寻找威胁；
收益放在鱼头的位置寻找机会。
假设条件和制约因素分析
假设条件不成立带来的威胁；
制约因素放松带来的机会。
文件分析
SWOT分析
优势 Strength；
劣势 Weakness；
机会 Opportunity；
威胁 Threat。
提示单：RBS的底层作为提示清单。
输出
风险登记册
已识别的风险清单；
潜在的责任人；
潜在的应对。
风险报告
实施定性风险分析
要点
评估单个项目风险发生的概率和影响以及其他特征，对风险进行优先级排序；
确认每个风险的责任人。这个人负责后续的工作，包括制定和落实应对措施。
输入
风险登记册；
工具与技术
风险数据质量评估；
风险概率和影响评估
对已识别的每个风险都要进行概率和影响评估；
低概率和影响的风险将被列入风险登记册中的观察单，以供未来监控。
概率和影响矩阵。
输出
风险登记册更新。
实施定量风险分析
要点
量化整体项目风险敞口，并提供额外的定量风险信息，以支持风险应对计划。
并非所有风险都可以量化。
输入
风险登记册；
工具与技术
访谈；
不确定性表现方式；
模拟；
敏感性分析：龙卷风；
决策树分析。
输出
风险登记册更新。
规划风险应对
要点
制定应对整体项目风险和单个项目风险的适当方法。
风险应对措施必须能获得全体相关方的同意；由一名责任人具体负责（风险应对责任人）。
注意次生风险和残余风险；
输入
风险登记册；
工具与技术
威胁应对策略
上报；
规避：消除威胁或免受威胁影响
延长进度、改变策略、缩小范围、澄清需求、获取信息、改善沟通、取得专有技能。
转移：将应对威胁的责任转移给第三方
保险、使用履约保函、担保、保证书、外包。
减轻：采取措施降低威胁发生的概率和（或）影响
采用较简单的流程、进行更多测试、选用更可靠的卖方、原型开发、加入冗余部件。
接受：承认威胁的存在，但不主动采取措施
主动接受：建立应急储备；被动接受：仅监督。
机会应对策略
上报；
开拓：确保把我高优先级的机会
把组织中最有能力的资源分配给项目来缩短完成时间（牛人）。
采用全新或升级的技术来节约成本（牛技术）。
分享：将应对机会的责任转移给第三方，使其享有机会所带来的部分收益
建立合伙关系、合作团队、特殊公司、合资企业。
提高：提高机会出现的概率和（或）影响
增加普通资源缩短工期；
接受：承认机会的存在，但不主动采取措施
主动接受：建立应急储备；被动接受：仅监督。
应急应对计划：如果确信风险的发生会有充分的预警信号，就应该制定应急应对策略
应急计划；
弹回计划。
备选方案分析；
成本效益分析。
输出
风险登记册更新；
变更请求；
项目管理计划更新。
项目采购管理
规划采购管理
要点
新兴实践
网络摄像机
试用采购
项目经理不必成为采购管理法律法规领域的专家，但应对采购过程有足够了解。
采购中有任何争议，以合同为依据。
记录项目采购决策，明确采购方法，识别潜在卖方的过程
输入
组织过程资产
预先批准的卖方清单，可以简化招标所需的步骤，并缩短卖方甄选过程的时间
合同类型
总价类合同
范围明确，不允许重大范围变更。
固定总价合同 FFFP
大多数买方都喜欢这种合同。
总价加激励费用合同 FPIF
目标成本/估算成本、目标利润/目标费用、分摊比例；
要设置价格上限，卖方必须完成工作并且要承担高于上限的全部成本。
总价=实际成本+目标利润（目标费用）+（目标成本 - 实际成本）* 卖方应承担比例； 先算总价，和最高限价比较，在计算最终总价。
**实际利润=最终总价 - 实际成本**
**实际利润=最终总价 - 实际成本**
总价加经济价格调整合同 FPEPA
允许根据条件变化（如通货膨胀、某特殊商品成本增降等），以事先确定的方式对合同价格进行最终调整。 履约期将跨越几年、以不同的货币支付价款。
成本补偿类合同
有范围，但是有可能出现重大范围变更。
成本加固定费用合同 CPFF
成本加激励费用合同 CPIF
会出现利润的最高/最低限价
利润=目标利润（目标费用）+（目标成本 - 实际成本）* 卖方应承担比例； 先算利润，和利润上下限比，计算最终利润
实际总价= 最终利润 + 实际成本
实际总价= 最终利润 + 实际成本
成本加奖励费用合同 CPAF
买方报销一切合法成本，但只有在卖方满足合同规定的、某些笼统主观的绩效标准的情况下，才向卖方支付大部分费用完全由买方根据自己对卖方绩效的主观判断来决定奖励费用，并且通常不允许申诉。
成本实报实销
工料类合同
没有范围，创新项目；
时间紧任务重；
单价合同
七种常用的合同
子主题
工具与技术
自制或外购分析
哪个便宜用哪个；
供方选择分析
输出
采购计划
如何协调采购工作与项目的其他工作
采购中的风险管理事项
招标文件
应答格式要求
SOW
拟签订的合同条款
SOW
SOW应该详细描述拟采购的产品、服务或成果，以便潜在卖方确定是否有能力提供；
工作说明书可包括规格、数量、性能参数、履约期限、工作地点和其他需求；
在采购过程中，应根据需要对采购SOW进行修订和改进，直到成为所签协议的一部分。
独立成本估算
可自行准备独立估算，或聘用外部专业估算师做出成本估算，并将其作为评价卖方报价的对照基准；
若二者存在明细差异，则可能：采购SOW存在缺陷或模糊，或潜在卖方误解或未能完全响应采购SOW。
自制外购决策
供方选择标准
项目相关方管理
规划相关方参与
2.3项目执行
项目整合管理
2.3.5 指导与管理项目工作
要点
执行项目管理计划中确认的工作；
实施批准的变更请求。
输入
项目管理计划；
批准的变更请求。
工具与技术
PMIS系统。
输出
可交付成果
具有可核实性；
包括项目管理计划的组成部分；
一旦完成了第一个版本（图纸），修改就需要走变更流程；
工作绩效数据；
问题日志
三要素：问题、责任人、解决期限；
问题日志随着新问题的出现和老问题的解决动态更新；
变更请求。
项目质量管理
管理质量
要点：把组织的质量政策用于项目，并将质量管理计划转化为可执行的质量活动的过程；
总结：管理质量“管过程”，也叫实施质量保证（QA）；
输入
质量测量指标；
质量控制测量结果：根据结果反思过程。
工具与技术
核对单；
质量审计
1.识别 2.分享 3.协助 4.积累 5.确认；
内审或外审；
事先安排或随机进行。
根本原因分析RCA：识别问题的根本原因，杜绝问题的再次发生；
过程分析：识别过程改进的机会，识别非增值活动；
鱼骨图
查根本原因或主要原因；
追溯问题的来源；
五个why、why-why分析；
直方图：显示频率和频次；
帕累托图
查主要原因；
二八定律；
有重点地采取措施。
散点图
自变量和因变量；
是否存在关联关系。
质量改进方法
PDCA；
六西格玛。
DFX：面向X的设计，优化设计的特定方面；
问题解决：1.定义 2.识别 3.方案 4.选择 5.执行 6.验证；
输出
质量报告
变更请求
项目整合管理
实施整体变更控制
要点
贯穿始终，项目经理承担最终责任；
任何干系人都可以提出变更，甚至可以口头提；
可以先了解变更的内容或者变更的原因是什么；
1.记录 2.评估 3.提交 4.更新 5.通知
输入
项目管理计划；
变更请求。
工具与技术
变更控制工具。
输出
批准的变更请求；
项目文件更新；
项目管理计划更新。
项目资源管理
获取资源
要点
获取项目所需的团队成员、设施、设备、材料、用品和其他资源的过程。
项目经理应进行有效谈判，并影响那些能为项目提供所需资源的人员。
如无法获得所需资源，项目经理可能不得不使用替代资源（也许能力较低，需要培训）。
输入
项目管理计划
项目文件
事业环境因素
组织过程资产
工具与技术
预分派（事先分配好的）
竞标承诺；
章程指定；
专有技能。
多标准决策分析；
谈判（协商）
跟职能经理谈判；
跟其他项目管理团队谈判获得特殊稀缺资源；
跟外部组织谈判获得特殊稀缺资源。
虚拟团队
云队友；
项目团队可分布在不同地理区域；可将在家办公的、行动不便者或残疾人纳入团队。
需要特别重视“沟通”。
输出
实物资源分配单；
项目团队派工单；
资源日历
何时用；
可用多久。
创建团队
要点
要点：提高工作能力，促进团队成员互动，改善团队整体氛围，以提高项目绩效的过程。
塔克曼模型
形成阶段：相互认识，相互独立，不一定开诚布公；
震荡阶段：冲突、 矛盾、不同的观点和意见；
规范阶段：开始协同工作、开始相互信任；
成熟阶段：组织有序、相互依靠、平稳高效；
解散阶段：释放人员，解散团队。
输入
项目管理计划
项目文件
事业环境因素
组织过程资产
工具与技术
集中办公：增进沟通，增强集体感；
认可与奖励：带来激励的作用；注意无形的奖励；全生命周期给予奖励；
培训：提高能力，减少差异；
个人和团队评估：有利于增加团队成员间的理解、信任、承诺和沟通。
输出
团队绩效评价
个人能力提高；
团队能力提高；
团队凝聚力加强；
团队离职率下降。
团队管理
要点
要点：跟踪团队成员工作表现，提供反馈，解决问题并管理团队变更，以优化项目绩效的过程。管理冲突，解决问题。
输入
团队章程 — 为团队如何决策、举行会议和解决冲突提供指南。
工具与技术
冲突管理
冲突管理的顺序
团队成员自行解决；
团队成员自行解决；
正式的程序，包括惩戒措施。
冲突管理五种方法
撤退/回避：退出冲突，推迟解决，推给他人解决；
强迫/命令：推一方观点，解决紧急问题；
合作/解决问题：综合考虑不同的观点和意见，合作的态度和开放式对话，引导各方达成共识和承诺；
缓和/包容：缓和关系，不解决问题，考虑一致性而非差异；
妥协/调解：一定程度的满意，部分解决问题。
情商：通过情商来识别、评估及控制项目团队成员的情绪，预测他们的行动，理解他们的焦虑，帮助解决他们的问题，从而减缓紧张，增进合作。
输出
变更请求
项目计划管理更新
项目文件更新
事业环境因素更新
项目沟通管理
管理沟通
要点
要点：促进项目团队与相关方之间的有效信息流动。
输入
工作绩效报告；
问题日志；
变更日志；
质量报告。
工具与技术
项目报告发布。
输出
项目沟通记录。
项目风险管理
实施风险应对
要点
一个字“干”：只有风险责任人以必要的努力去实施商定的应对措施，项目的整体风险敞口和单个威胁及机会才能得到主动管理。
输入
工具与技术
输出
项目采购管理
实施采购
要点
要点：获取卖方应答、选择卖方并授予合同的过程；
输入
采购文档
招标文件；
采购工作说明书；
独立成本估算；
供方选择标准。
卖方建议书。
工具与技术
招 广告；
投 招标人会议；
评 建议书评估；
授 授予合同前进行采购谈判。
输出
选定的卖方；
协议。
项目相关方管理
管理相关方参与
与相关方进行沟通协作，以满足其需要与期望，处理问题，并促进相关方合理参与的过程。
1.引导参与，获得支持;
2.谈判沟通，管理期望;
3.处理风险，预测问题;
4.澄清和解决问题。
2.4项目监控
监控项目工作
要点
整个工作绩效信息，形成工作绩效报告。
输入
工作绩效信息；
进度预测；
成本预测
工具与技术
备选方案分析；
成本效益分析；
挣值分析；
根本原因分析 RCA；
趋势分析；
偏差分析。
输出
工作绩效报告。
实施整体变更控制
要点
贯穿始终，项目经理承担最终责任；
任何干系人都可以提出变更，甚至可以口头提；
可以先了解变更的内容或者变更的原因是什么；
1.记录 2.评估 3.提交 4.更新 5.通知
输入
项目管理计划；
变更请求。
工具与技术
变更控制工具。
输出
批准的变更请求；
项目文件更新；
项目管理计划更新。
范围管理
控制范围
要点
定义：监控项目和产品范围状态，管理范围基准变更，防止范围蔓延（Scope Creep）的过程。
目标：确保所有变更均通过正式流程审批，并更新范围基准。
目标：确保所有变更均通过正式流程审批，并更新范围基准。
输入
范围基准（Scope Baseline）：包括范围说明书、WBS和WBS词典。
工作绩效数据：如任务完成度、变更请求记录。
需求跟踪矩阵（RTM）：关联需求与可交付成果的完成状态。
工具与技术
偏差分析
发现需求工作量超计划15%
变更控制委员会（CCB）
客户新增“多语言支持”需求的评审
趋势分析
根据历史数据预警项目可能延期2周
输出
批准的变更请求：如新增功能模块或调整交付顺序。
更新的范围基准：修订后的WBS和范围说明书。
经验教训登记册：记录范围失控的根因（如需求不明确）。
进度管理
控制进度
要点
监督项目进度，管理进度基准的变更
输入
工具与技术
数据分析
挣值分析：将进度绩效测量指标与进度基准比较
绩效审查：根据进度基准，测量、对比和分析进度绩效，如实际开始和完成日期、已完成百分比及当前工作的剩余持续时间。
趋势分析：检查项目绩效随时间变化情况，以确定绩效是在改善还是在恶化。
偏差分析：关注实际开始和完成日期与计划的偏离，实际持续时间与计划的差异，浮动时间的偏差。
假设情景分析：基于项目分享管理过程的输入，对各种不同情景进行评估，促进符合基准。
输出
成本管理
控制成本
要点
监督项目状态，以更新项目成本和管理成本基准变更
输入
项目管理计划
项目绩效数据
工具与技术
挣值分析：BAC、PV、EV、AC
BAC：完工预算/成本基准（不考虑管理储备，修改需走变更流程）；
BAC=完工时的PV的总和；
BAC=EV 就表名项目已经完工；
PV：计划价值-到目前为止计划做多少；
PV（别称BCWS）=计划工作量 x 预算单价
EV：挣值-到目前为止已经做了多少；
EV（别称BCWP）=实际工作量 x 预算单价
AC：实际成本-到目前为止实际做了多少；
AC（别称ACWP）= 实际工作量 x 实际单价
偏差分析：SV、CV、SPI、CPI
SV：进度偏差 **SV=EV-PV**
>0
当前进度提前
=0
当前时度符合
<0
当前进度滞后
CV：成本偏差 ** CV=EV-AC**
>0
当前成本节约
=0
当前成本符合预算
<0
当前成本超支
SPI：进度绩效指数 **SPI=EV/PV**
>1
当前进度提前
=1
当前进度符合
<1
当前时度滞后
CPI：成本绩效指数 ** CPI=EV/AC**
>1
当前成本节约
=1
当前成本符合预算
<1
当前成本超支
趋势分析：EAC、ETC
ETC：完工尚需估算
ETC=（BAC-EV）/绩效
EAC（完工预算）：完工预期的总成本
EAC=AC + ETC
EAC=AC+（BAC-EV）/1 ------非典型（剩余工作按照计划的绩效继续）
EAC=AC+（BAC-EV）/CPI ------典型（剩余工作按照当前的绩效继续）
EAC=AC+（BAC-EV）/（CPI x SPI） ------特殊绩效（剩余工作同时受CPI和SPI的影响）
子主题
EAC=AC+自下而上重新估算的ETC
公式记忆法
BAC - EV ------剩余工作的预算价值
EAC=AC+（BAC-EV）/绩效
EAC=AC+（BAC-EV）/CPI
EAC=AC+（BAC-EV）/(EV/AC)
子主题
例子
子主题
完工尚需绩效指数：TCPI
剩余工作的预算价值/剩余预算
TCPI=（BAC-EV）/（BAC-AC） ------若BAC可行情况下；
TCPI=（BAC-EV）/（EAC-AC） ------若BAC不可行的情况下，用EAC代替；
公式记忆法
CPI=EV/AC，TCPI前面多了个T，后面分子分母分别多一个BAC，TCPI=（BAC-EV）/（BAC-AC）
TCPI：剩余工作每用一块钱需要干多少事； 这个值越小越好
TCPI>1：很难完成
TCPI=1：正好完成
TCPI<1：很容易完成
了解：完工偏差 VAC = BAC-EAC
储备分析
剩余的风险和剩余的储备是否匹配
财务概念
现值:PV = FV/（1+r）^n
子主题
PV：现值；FV：投资的终止、将来的值；r：折现率；n：年数
未来的钱在现在的价值
净现值 NPV
投资方案所产生的现金净流量以资金成本为贴现率折现后与原始投资额现值的差额 （时间段内报酬现值的总和减去原始投资额）
子主题
NPV>0 ------接受该项目；
NPV<0 ------放弃该项目。
PV: 现值； FV: 投资的终值，将来的值；r: 折现率； n: 年数
如果在有多个备选方案的互斥选择决策中，由于净现值已考虑了货币的时间价值，所以应选择 净现值是正值中最大者。
内部收益率 IRR ------净现值等于零时的折现率。代表了项目抗风险（通货膨胀等）能力的大小，越大越好。
投资回收期 PP
自项目的投建之日起，用项目所得的净收益偿还原始投资所需的年限。 （不考虑货币时间价值，越短越好——PMP只考静态回收期）
PP = 投资成本/净现金流（收益）；越短越好。
投资回报率 ROI ------年平均利润/投资总额 x 100% 越大越好
效益成本比 BCR ------项目投资与效益之间关系的比率
收益/投资
BCR>1：接受该项目；BCR<1：放弃该项目；越大越好
输出
输出
输出
工作绩效信息
变更请求
质量管理
控制质量
要点：核实项目可交付成果和工作已经达到主要干系人的质量要求。
总结：控制质量“查结果”，QC；
输入
质量测量指标；
可交付成果；
批准的变更请求。
工具与技术
核查表：计数表；
合理排列k 种事项，有效收集关于潜在质量问题有用数据
核对单；
统计抽样；
检查；
控制图
确认一个过程是否稳定，或者是否具有可预测的绩效
失控的两种情况；
某个点超出控制限 ，或者连续7个点落在上方或者下方时，认为失控
控制界限和规格线。
输出
质量控制测量结果；
核实的可交付成果；
变更请求。
资源管理
控制资源
要点
输入
项目管理计划
项目文件
工作绩效数据
协议
组织过程资产
工具与技术
数据分析
问题解决
人际关系与团队技能
项目管理信息系统
输出
工作绩效
变更请求
项目管理计划更新
项目文件更新
沟通管理
监督沟通
要点
输入
工具与技术
输出
风险管理
监督风险
要点
要点：在整个项目期间，监督商定的风险应对计划的实施、跟踪已识别风险、识别和分析新风险，以及评估风险管理有效性的过程。
输入
风险登记册；
工具与技术
储备分析；
风险审计：评估风险管理过程的有效性；
会议：风险审查会议可以识别出新的单个项目风险（包括次生风险），重新评估当前风险，关闭已过时的风险，总结经验教训。
输出
风险登记册更新。
采购管理
控制采购
要点
管理采购关系、监督合同绩效，实施必要的变更和纠偏，以及关闭合同的过程。
输入
协议；
批准的变更请求：合同的变更也需要走流程。
工具与技术
索赔管理
谈判；
ADR；
决策记录
起诉。
采购绩效审查：审查供应商的过程。
检查：检查供应商的可交付成果。
采购审计
对采购过程的结构化审查；
总结经验教训，有利于未来的采购。
输出
采购关闭。
相关方管理
监督相关方参与
2.5结整项目或阶段（收尾）
收尾步骤
1. 获得验收
可以开展干系人满意度调查；
2. 移交；
3. 总结经验教训；
4. 更新组织过程资产；
5. 归档；
6. 释放资源
释放之前可以开庆功会。
输入
项目章程
成功过标准；
退出标准。
验收的可交付成果；
组织过程资产
项目或阶段的收尾指南或要求。
工具与技术
会议
输出
最终的产品、服务或成果移交；
最终报告；
组织过程资产更新
项目或阶段收尾文件。
3敏捷
敏捷概述
生命周期
预测型生命周期
范围明确、有厚实的经验基础、计划驱动，也叫瀑布型；
混合型生命周期
可以实现预测向敏捷的过渡；
可以在风险不大，具有中低程度不确定性的项目汇总尝试
敏捷（适应型）生命周期
快速应对变化，以较小的增量，快速迭代，每次增量都注重价值。
MVP
定义：最小可行产品，符合产品预期的最小功能集合。在MVP的基础上继续快速迭代，直到产品稳定。
作用
快速试错
快速获取市场反馈
典型场景
不知道市场是否欢迎？
不知道是不是客户想要的？
时间比较紧或者预算有限的情况下需要发布产品。
敏捷宣言和原则
敏捷宣言
个体以及互动胜过过程和工具
可用的软件胜过完整的文档
可用的软件胜过完整的文档
响应变化胜过遵循计划
敏捷十二原则
1. 我们最重要的目标，是通过及早和持续不断地交付有价值的软件使客户满意。
及早
持续不断
价值驱动
客户满意
持续不断
价值驱动
客户满意
2. 欣然面对需求变化，即使在开发后期也一样，为了客户的竞争优势，敏捷过程掌控变化。
拥抱变更
提高客户竞争优势
提高客户竞争优势
3. 经常地交付可工作的软件，相隔几个星期或一两个月，倾向于较短的周期。
频繁交付
短周期
短周期
4. 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
业务和开发相互合作
每天如此
每天如此
5. 激发个人的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
提供环境
支持团队
对团队辅以信任
支持团队
对团队辅以信任
6. 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
面对面沟通效果最好
也可使用虚拟沟通
鱼缸窗口
远程结对
也可使用虚拟沟通
鱼缸窗口
远程结对
7. 可工作的软件是进度的首要度量标准。
根据可工作的软件度量
8. 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
可持续开发
步调稳定
步调稳定
9. 坚持不地追求技术卓越和良好设计，敏捷能力由此增强。
重构
10. 以简洁为本，它是极力减少不必要工作量的艺术。
简洁
专注目标
专注目标
11. 最好的架构，需求和设计出自自组织团队。
自组织团队
12. 团队定期地反思如何提高成效，并依此调整自身的行为表现
定期回顾
不断改进
不断改进
敏捷实践
Scrum
三个角色
产品负责人 PO
是负责管理产品待办事项列表 PB的唯一责任人
清晰描述产品待办事项列表 ProductBacklog（PB）
对列表项进行优先级排序
确保PB透明清晰
确保开发团队对PB有足够深的了解
团队可以参与上述工作，但是责任人还是PO
改变PB的优先级都需要经过产品负责人
常见考点
需求不明确，可以与PO和干系人（客户）澄清
PO是某个业务专家，但一般不会由Scrum Master兼任
PO决定接受或拒绝每次Sprint完成的增量
开发团队
自组织创建并得到授权
自组织
自主进行任务的估算、自主决定任务的分配、自行决定任务具体怎么执行
跨职能
团队拥有创建产品的全部技能，T型人才一专多能
有利于协作、交叉培训和结对
去中心化
不认可任何头衔、不管承担什么工作，都能叫开发人员，没有对个层级也不认可子团队（比如测试、架构等等）
相对稳定
一般3~9人，比较稳定，建议全职
主动学习
愿意接受挑战，主动要求成长
一般不包括PO和Scrum Master，除非他们也参与执行Sprint待办事项中的工作
常见考点
自行决定任务的分配
自行决定用什么方式完成任务
负责所有估算工作
强调团队协作
Scrum Master
服务型领导（仆人式领导）
服务于产品负责人
确保团队理解目标
找到有效管理PB的技巧
确保产品负责人了解如何安排PB
帮助理解并实践敏捷性
服务于团队
作为教练在自组织和跨职能方面给予指导
移除开发团队工作中的障碍
在Scrum还未完全采纳和理解的组织环境中，作为教练指导开发团队
服务于组织
作为教练指导组织采纳Scrum
帮助干系人理解并实施Scrum
引发提升团队生产率的改变
增强组织中Scrum应用的有效性
常见考点
仆人式领导提供协作和支持，而不会去命令和控制
不会去分配任务，不会去下达指示
当PO、团队或者其他干系人（如客户）不了解敏捷时要提供培训，服务于各方
当团队遇到障碍，应该帮助团队扫清障碍
三个工件
产品待办事项列表 PB
涵盖产品的已知需求
包括所有的特性、功能、需求、增强和修复
按照优先级排序、优先级越高则越详细
优先级较高的，可以交给开发团队去开发的用户故事应该符合就绪的定义 DOR（Definition of Ready）
由产品负责人 PO 负责
Sprint待办列表
为当前Sprint选出的产品待办事项
至少包括一项在前次回顾会议中确认的高优先级的改进
增量
一个Sprint完成的所有待办事项的总和，以及之前所有 Sprint 所产生的增量的价值总和
必须达到“完成”的定义标准 DOD（Definition of Done）
无论产品负责人是否发布，增量必须可用
五个事件
Sprint
长度固定（一般2~4周）
包括：Sprint计划会议、每日Scrum站会、开发工作、Sprint评审会、Sprint回顾会议
Sprint期间的注意点
不能做出有害Sprint目标的改变
Sprint期间理论上不变更
不能降低质量
产品负责人和团队之间可以对要做的事情加以澄清
未完成的待办事项都会放回 PB 中，重新估算和排序
只有产品负责人有权取消Sprint，但是由于Sprint都短，取消的意义不大
Sprint计划会议 （P）
计划Sprint要做的工作，整个Scrum团队共同完成
有时间盒限定：2周的Sprint，一般4小时；对于一个月的Sprint，最长8小时
Scrum Master确保会议举行，每个参会者都要理解会议的目的并遵守时间盒的规则
会议回答两个问题
Sprint要交付的增量包括什么
如何完成交付增量所需的工作
在计划会议中确定Sprint目标
产品负责人帮助解释所选的产品待办事项
开发团队自己决定选择产品待办事项列表的数量
开发团队决定如何完成选定的产品待办事项
开发团队可以邀请其他成员参加会议以获取相关的知识或建议
每日Scrum会议（站会）（D）
借助站会检视完成Sprint目标的进度，检视Sprint待办列表的进度
时间盒限定为15分钟的事件，每天举行
会议的作用
增进沟通，同步信息
减少其他会议
发现需要移除的障碍
提高开发团队认知程度
会议内容
昨天，我为帮助开发团队达成Sprint目标做了什么？
今天，我为帮助开发团队达成Sprint目标准备做什么？
是否有任何障碍在阻碍我或开发团队达成Sprint目标？
注意点
会上不讨论问题，会后可以进行更详细的讨论。
Scrum Master确保开发团队每日站会如期举行，但开发团队自己负责召开会议。
每日Scrum站会是开发团队的内部会议。
如果有开发团队之外的人出席会议，Scrum Master必须确保他们不会干扰会议进行。
如果有多个敏捷团队为一个项目工作，需要召开 SOS会议（Scrums of Scrum）。
同步更新信息发射源（更新信息发射源中的看板、燃尽图/燃起图、累积累流图、障碍板等等）。
Sprint评审会议（C）
在SPrint快结束时举行，用以检视所交付的产品增量，并按需调整PB。
有时间盒限定：2周的 Sprint，一般2小时；对于一个月的Sprint，最长4小时。
整个Scrum团队和干系人参加
评审内容
团队演示完成的工作；
PO 说明哪些已完成，哪些没有完成；
参会的所有人就下一步工作进行探讨；
评审接下来要做的最有价值的东西的改变。
评审会议的结果是一份修订后的产品待办事项列表，阐明很可能进入下一个 Sprint 的产品待办事项。
Sprint回顾会议（A）
在评审会议之后，下个Sprint之前开；
团队检视自身，并创建下一个Sprint改进计划的机会；
有时间盒限定：2周的Sprint，一般1~2小时；对于一个月的Sprint，最长3小时；
Scrum团队应该明确接下来的Sprint中需要实施的改进。
产品待办事项列表梳理会
澄清或细化用户故事，审查优先级等工作，一般不超过团队产能的10%的时间。
五大价值观
勇气
有勇气做出承诺，履行承诺，接受别人的尊重。
承诺
愿意对目标做出承诺。
专注
把你的心思都用到你承诺的工作上去。
开放
Scrum把项目中的一切开放给每个人。
尊重
每个人都有他独特的背景和经验。
看版系统
可视化管控
拉动式
消除瓶颈
极限编程
测试驱动开发 TDD
类似的还有验收测试驱动开发 ATDD，行为驱动开发 BDD。
重构 解决技术债务
结对编程
代码集体所有
持续集成
敏捷中各个知识领域
整合管理
团队自行决定计划及其组件的整合方式（自组织）。
项目经理负责营造一个合作型的决策氛围。
团队如果是T型人才有助于合作并解决知识孤岛。
项目章程
为什么要做这个项目。
谁会从中受益，如何受益。
达到什么条件意味着项目完成。
将怎么合作。
范围管理
先为整个项目确定一个高层级的愿景；
多次迭代开发可交付成果；
每次迭代开始定义详细范围
Sprint计划会议
Sprint Backlog
干系人持续参与
有目的地构建和审查原型 增量
每次迭代都会确认范围和控制范围
Sprint评审会议
专注Sprint目标，不能做出有害于Sprint目标的改变
进度管理
实践
具有未完成的进度计划 Scrum
按需进度计划 看板
WIP（在制品）限制
消除瓶颈
敏捷发布规划
产品愿景、产品路线图（高层级）
发布计划（高层级） 每个产品版本需要多少次跌代
迭代计划 Sprint中的详细用户故事
控制进度
燃尽图
燃起图
成本管理
轻量级方法生成高层级预测
详细的估算适用于采用准时制的规划
质量管理
完成的定义 DOD
测试驱动开发、行为驱动开发、验收测试驱动开发
持续集成
Sprint回顾会议
代码集体所有
全员责任
资源管理
集中办公
T型人才
协作型团队
自组织任务分配
交叉培训
团队章程
团队价值观
工作协议
DOR
DOD
时间盒
WIP
基本规则
团队规范
沟通管理
透明、高效
信息扩散器（看板、燃尽图、燃起图、累积流图、障碍板）
面对面
虚拟沟通
鱼缸窗口
远程结对
多个敏捷团队沟通
Scrums of Scrum（SOS会议）
追逐太阳
风险管理
经常审查增量，加快知识分享。
在迭代规划的时候考虑分享，在迭代期间识别、分析和管理风险。
根据风险敞口的理解加深，重新排列优先级。
采购管理
客户协作高于合同谈判
灵活的协议
多层结构 主协议和补充文件
关注用户故事而非整个项目的预算
动态范围方案
提前取消方案
资助团队而非范围
干系人管理
频繁参与
高效透明的沟通
常见的干系人管理
总结：执行层面的工作自己决定
收藏
0 条评论
下一页
