PMP-项目管理核心内容汇总
2023-10-30 18:16:23 0 举报AI智能生成
登录查看完整内容
项目管理PMP-核心内容整理汇总（基于光环PMP课程）。包括对课程内容的提炼，总结，以及重点的标记。
作者其他创作
大纲/内容
项目管理
考试重点 & 工作重点
工作重点
图例
概念：为了实现同一个战略目标而组合在一起管理的项目、项目集、子项目组合和运营工作
强调价值判断：根据战略目标判断什么事情价值最高
最重要的：高占有高增长
明星
传统优势项目，能够带来稳定的现金流，但已经进入瓶颈期
金牛
保持团队的稳定，人员的稳定（虽然无法带来价值）
瘦狗
销售增长呈现爆发，虽然现在无足轻重，但未来可能会成为爆款
问题
波士顿矩阵- 横轴：市占率- 纵轴：销售增长率
项目组合(Portfolio)
成果交付
项目集(Program)
互相依赖，互相共享资源
把互相之间有内部逻辑关系的项目进行统筹管理
蚂蚁金服旗下的各种APP打包一起管理：支付宝、余额宝（存钱）、蚂蚁小贷（借钱）
项目集管理
一个项目组合：包含项目和项目集，他们之间不一定有逻辑关系，但战略目标一致
不同项目组合：服务不同的战略目标，会指定不同的优先级
例：腾讯同时开发多个吃鸡游戏项目，但都是为同一个战略目标：抢占吃鸡游戏市场 但项目之间可能有竞争关系，且项目是由不同的部门开发的
项目组合
项目集 vs 项目组合
商业价值的实现
项目与运营不是完全独立，而是相辅相成的
运营阶段收集反馈，会转变为项目新需求，来推动项目
项目 vs 运营
运营
子主题
概述
政府、行业协会、管理层
来源
遵守
用途
被动接受
方式
事业环境因素EEFs（客观存在）
历史项目团队及项目相关部门
使用
主动参与，更新维护
组织过程资产OPA（主动产生）
组织运行环境
示例：某公司的项目管理信息系统属于哪种？答案：事业环境因素，因为无论做哪个项目，都必须要强制使用这个系统
各个部门各司其职
不为项目绩效负责，项目难以推动（只有总经理可以做决策）
特点
客户有需求无法及时相应和满足。例如：医院
影响
职能型
以项目为单位，每个项目里包含各个职能的人：开发，测试、做预算
沟通高效，有明确的责任人
优点
人力成本高：因为每个项目都需要配齐所有人，在某些时间里造成人力资源浪费
驱动力弱：大家都不愿意项目结束，团队成员没有安全感，没有有归属感
不利于个人成长：一个项目内相同职能的只有一个人，缺乏同类型人员的沟通
缺点
大型长期项目：房地产开发，工程行业
适用领域
项目型
从每个职能部门抽调人手组成项目团队，并任命项目经理
职能型*项目型
架构
有负责人
能够快速处理客户需求
较高的沟通效率
不会造成人力资源浪费：项目结束后可以回到原职能部门等待安排新的工作
员工没有明确的领导，不知道听谁的
职能经理：维护培养资源池，支持各个项目。负责派哪个人去哪个项目
场景：公司以项目为导向的业务为主
强矩阵：项目经理>职能经理
职能经理：掌握预算、资源
项目经理：协调资源
场景：运营为导向的业务模式。持续运营为主，只有一些临时的项目
弱矩阵：项目经理<职能经理
主要类型
矩阵型
组织结构类型
项目管理者在不同组织的角色1. 强矩阵+项目型：项目经理占主导
定规矩，指定总的规章制度
项目治理框架是为项目相关方提供管理项目的结构、过程、角色、职责、终责和决策模型。
治理
针对具体的事情
管理
治理：提前确定项目汇报机制、沟通原则、决策方式
管理：进度管理、成本管理
项目治理 vs 项目管理
治理 vs 管理
复杂性≠不确定性
维持状态的能力
迅速恢复的能力
通过适应来更好地应对不确定性的能力
项目韧性：当遭遇风险时
拥抱变化
i.e. 文字、数据、表格
易于总结、易于表达、易于归纳
显性知识
i.e. 经验、洞察力
无法编撰、难于表达
隐形知识
产生（Produce）
积累（Stockpile）
交流（Communication）
应用（Application）
持续不断的PSCA循环以达到认知升级的效果
听：5%（留存率）
阅读：10%
视听：20%
主动演示：30%
讨论互动：50%
实践：75%
教授给他人：90%
如何有效得到认知升级 - 学习金字塔
被动学习
主动学习
认知升级
管理项目知识
持续学习
如何驾驭？
项目的复杂性
中性词：好事->机遇；坏事->威胁
未经保护的风险
风险敞口
含义
取决于干系人的偏好和承受力
风险临界值
项目经理职责：识别各个干系人（发起人，老板）的风险临界值，再做进一步的项目计划
干系人的风险态度
1. 提前启动并持续进行风险识别
2. 评估风险阈值，确定管理策略
概率
3. 风险定性分析，确定优先级
评分和分级
应对风险所要预备的时间、成本、资源
4. 风险定量分析，设计止损机制和储备
5. 研究风险触发机理，设置预警机制
买保险
6. 平衡威胁和机遇，积极配置风险组合
plan B
7. 规划风险应对方法，控制风险
8. 跟踪风险，动态调整应对方案
9. 评估应对措施的有效性，防范次生风险
主动管理风险
突发的风险，黑天鹅事件
变异性风险
例如对于最前沿技术不了解而带来的风险
未知领域带来的风险
模糊性风险
原则：各司其职
项目风险：项目经理管理；一个战略下面的项目（项目组合）：由项目组合经理去管
整合式风险管理
分类1
风险可识别，但概率、影响无法评估
已知-未知风险
风险本身无法识别，或未达成共识的风险（我认为是，其他人不认同）
未知-未知风险
未知风险
已知 vs 未知风险（认知角度）
项目管理团队可以产生影响：例如工期估不准可以请专家指导
内部
无法施加干预（但可以在事前规避/预防）：通货膨胀风险，采用美元结算以进行规避
外部
内部 vs 外部风险
保险覆盖的风险
可保险
保险不能覆盖的风险
商业风险
商业 vs 可保险风险
分类2
风险分解结构（RBS）- 可以和WBS，资源分解结构表对应起来
互相平等，互相启发，集思广益
收集整理idea，从中识别风险
头脑风暴
避免专家之间互相影响
咨询专家，并投票（多数专家服从少数专家）1. 单独访问，单独整理汇总。2. 对于大多数人都认可的风险，那么进行记录确定。3. 对于意见不一的风险，进行第二轮访谈
德尔菲法
向上追溯，直到找到根本原因
根本原因分析
钱、人、技术各个方面进行检查
核对单分析
列出所有假设原因，两两比较，保留可能性最大的，直到找到最主要原因
假设分析
盘点项目流程，判断风险
系统流程图
i.e. 库存和IQC管理系统流程图
注意专家的偏见：可以使用德尔菲法解决
注重专家的直觉
专家判断
先枚举，再一层一层放宽来增加机会
已确定，客观存在i.e. 只给6个人，预算只有50万，数据保密
制约因素
先假设，再一层一层收紧来暴露风险
不确定，经验推断i.e. 已有可行的技术方案，有成熟的产品组件 ，不会有其他突发工作，客户不会该需求
假设条件
假设条件&制约因素分析
进阶版：战略管理 - 应对策略判断
基础版S&W：内部因素O&T：外部因素S&O：优势W&T：劣势
SWOT分析
识别方法
例题：项目经理识别到可能影响项目进度计划的风险后：第一步：更新风险登记册第二步：风险评估->制定风险应对计划等
提示清单（Prompt List）- RBS（风险分解结构）
对于单个项目风险
战略框架（分析框架）
对于整体项目风险
举例：邻近性*可监测性*冲击值
可选维度：紧迫性、邻近性、潜伏期、可管理性、可控性、可监测性、连通性、战略影响力、密切度
层级图（气泡图）- 三个维度分析
对于风险间的逻辑关系
风险的管理&记录
风险
1. Finding：识别2. Analysis：评估阈值-定性分析-定量分析-原因分析3. Action：对冲风险-设置planB4. Tracking：持续跟踪-持续评估策略有效性
行业规范：行业监管部门的政策规范
质量：国家/行业/企业标准
安全/健康：对安全、健康的要求
环境：对环境保护的要求
Step1: 确认合规要求（要熟悉行业法规）
Step2: 分析不合规后果，潜在威胁
Step3: 确定必要方法和行动保障不会出现不合规的情况
审计：过程合规性的审查（该走的流程没走，该签字的没签）
Step4: 持续衡量项目合规程度/合规与否：审计、回顾、改进
合规
合规是红线，不容破坏如果规则不合理，应该积极建议公司改进
商业论证、效益管理计划：项目前期收集制定
商业文件
包括：业务需要、假设条件、制约因素、对客户需要和高层级需求、需要交付的新产品、服务或成果- 在90个工作日完成
项目章程(总则）
包括：范围/进度/成本管理计划... ...
举例：进度管理计划- 包括：用什么工具编制进度计划，用什么方法优化进度，进度单位- 不包括：进度的具体信息和数据
定义规则，不包含项目的具体信息和数据
规则程序
范围
i.e. 不能超过3个月，否则延期
进度
i.e 不能超过3M预算
成本
按严格程度排序：企业>行业>国家
质量
项目基准(baseline)
项目管理计划（规则&目标）
包括：范围说明书、进度计划、成本估算
举例：项目进度计划，包含项目工期
实施的具体信息和数据
实施计划
假设日志、问题日志、项目沟通记录、经验教训登记册
资料文件
项目文件(执行过程产生)
管理计划和项目文件
i.e. 软件开发项目中：原型评审、单元测试、集成测试、验收评审、版本发布
非常重要的事件或者节点
时间节点稳定，不会轻易变动
特征
分解计划，制定阶段性目标
控制：保证每个里程碑如期完成
责任：容易明确每个里程碑对应的责任人
沟通：方便客户/高层管理者的沟通
报告：体现对整个项目进度的把控
意义
时间：制定完章程后
召集人：项目发起人
发布章程（明确目标，达成共识）
确认项目经理
目标
下一步是项目规划（编制项目计划）、方案评审-- 包含：识别项目风险，创建工作分解结构（WBS）
承接
项目启动（Initiating）
时间：计划编制完成后（项目规划结束后/完成审批后），实施计划前
召集人：项目经理
项目负责人
各个相关方
参与方
如果不能参会，需要推迟会议
明确项目目标
明确分工（获得团队对项目的承诺）
明确责任（阐明相关方角色和责任）
内容
下一步是项目规划
项目开工（Kick-off）
两个重要会议
里程碑计划
做项目前，识别项目可能产生的利益和价值
识别：创造什么价值（What）
确保效益目标和战略的一致性
项目经理、团队、发起人的责任分别是什么
确定效益管理责任
时间表
规划实现效益目标的时间
例如商业论证中的常用财务测量指标- 投资回报率 ROI- 投资回收期 PBP- 净现值 NPV- 内部收益率 IRR- 效益成本比率 BCR
测量指标&测量方法
确定效益的评估指标
识别风险和应对方案
制定效益管理计划
计划：如何创造价值（How）
持续跟踪和评价项目价值
跟踪&评价
评估
无形：比如通过这个项目，可以提升企业知名度（本身不挣钱），增加企业未来赚钱的能力
维度（经济&社会&环境）*存在形式（有形&无形）
效益目标
项目价值
政策有没有改变，竞对对我们的竞争态势有无变化？
调查环境的变化
评估影响和优先级
持续审视和评估影响
提出变更建议
项目环境的持续评估(环境变化对项目的影响)
A1. 领导力和价值观
A2. 目标和战略
A3. 项目团队与合作伙伴的合作关系
A. 人员（团队）和目标
B1. 项目过程管理和资源管理
B2. 其他关键流程和资源管理
B. 过程及资源
过程是否合规、合理，对资源利用效率是否足够好
C1. 客户满意度
C2. 项目团队满意度
C3. 其他干系人满意度
C4. 项目结果及对环境的影响
C. 成果
3个主领域&9个子领域
领域
20个评估标准&107个要素标准
标准
大量的案例，过程记录，证明文件
案例
卓越项目管理模型
重点评估项目价值
前期
重点评估项目是否合规、项目预期的验收成果是否合格，是否能交付
中期
目标的视线程度
过程的合理性和规范性
实施过程
财务指标和经济性
效益
经济、社会、环境
可持续性：项目不仅在验收时，而且要在验收后均保证质量
可持续性&可重复性
持续性
是否能实现最初设定的期望- 6个方面
后期
不同阶段的评价
项目评价
卓越项目管理模型- 各方满意和团队成长是最重要的两个评估领域
对外：与外部买方/卖方交接
例如客户临时增加需求，付款出现问题
对外产生冲突的基本都产生在合同收尾阶段
合同收尾
对内：与公司内部交接（贯穿项目始终）
归档并上报项目文档记录、经验教训、知识等，交给PMO
项目经理
Step1：整理、甄别、归纳、提炼
组织过程资产是提炼后的内容，包含部分项目文件。- 例如项目文件中的经验教训登记册，并不都属于组织过程资产，只有共性、再次发生概率大的部分参会放进去
Step2：形成组织过程资产：PMO提炼后，有共性 & 对未来项目有价值的内容
Step3：及时分享给所有人，学习、观摩、交流
PMO
责任人
例如没有按照公司流程制度提交经验教训，文档记录，或没有及时提交
容易出现的问题
行政收尾
项目收尾&组织过程资产（2-31 & 4-31节）
环境
整合各个方面的人才
资源整合者（Integrator）
建立一套合理的沟通机制（针对不同部门的人）
信息沟通者（Communicator）
氛围创造者（Climate Builder）
决策制定者（Decision Maker）
团队领导者（Team Leader）
角色
只有领导没有管理：只剩下鼓励和激发，没有秩序，状态不易保持
只有管理没有领导：紧张的上下关系，缺乏内动力（没有远期目标和方向）
管理 vs 领导
服务一线员工，提供支持，员工才能全心全意为客户服务（星巴克，海底捞）
服务型
强调集体，强调组织。通过变革不断提升组织整体的能力
变革型
其他：放任型，交易性（赏罚分明），魅力型，交互性（交易+变革+魅力的均衡型）
风格
信任
多指导，多表扬
激发
创建协作的环境
以身作则
共启愿景
主动从外部获取创新方法，寻求改进机会的尝试和冒险，从实践中学习
挑战现状
建立信任和增进关系来促进合作，增强自主意识和发展他人的能力
使众人行
表彰他人的卓越表现来认可贡献，创造集体主义精神，庆祝胜利
激励人心
卓越领导者的行为习惯
有胜任力的：持续学习
前瞻性：扎实的知识积累，关注细节，相信专家的建议
诚实>有胜任力的>能激发人的>有前瞻性的>聪明的>心胸宽广
品质
信任，授权
有能力的下属
针对下属的态度，采取不同的措施来领导
指导型：指示/教授 + 监督
D1：没能力*没意愿
教练型：传授 + 督促
D2：没能力*有意愿
支持型：鼓励 + 支持
D3：有能力*没意愿
授权型：信任 + 授权 + 观察
D4：有能力*有意愿
能力*意愿
情境领导力
建立信任、积极聆听、共启愿景、激发动力、表达欣赏、管理进步、促进行动、启发创造
团队成员心目中领导力的8个指标
领导力评估（3-33）
领导力
目标：要技术开发人员，确保人数够，按时到位，技术合格
对象：职能经理
目标：让对方的精锐人员支持项目
对象：分包商/供应商
谈判
项目经理角色和职责
工作性质和项目经理类似，帮助项目经理编制计划、控制偏差、协调管理等工作
项目管理团队人员并不一定专职做项目管理，可能是一些兼职人员：开发帮项目经理计算工期
项目管理团队（项目团队子集）
项目管理团队 + 做具体业务的人（开发、产品）
项目团队
项目团队 vs 项目管理团队
永远选择优秀的人- 业绩好，价值观正确
好的团队成员
发展方向
Level 1：定调子（整体方向的设定）
如何搭建公司的组织管理框架，管理的制度流程
Level 2：搭台子（团队及组织环境的规划）
任务怎么安排
Level 3：写谱子（工作过程和进度的监控和管理）
具体干的活
Level 4：唱曲子（团队任务的执行）
权利矩阵
自治理型团队：海尔全员创业，各个小微组织自行决定
自组织团队
类型划分
价值观
开会的纪律：哪些需要开会，多长时间开
沟通指南
举手表决还是项目经理一个人拍板
决策标准和过程
风险描述
团队章程(章程的内容)
描述：召集团队. 项目初期团队士气较高
指导为主：直接了当，明确指令
管理风格：指导型
形成
描述：分配工作后，会出现不满的意见，此时士气最低
支持+指导：(引导、斡旋、调解、计划、督导)
管理风格：教练型
震荡(磨合)
描述：逐渐开始配合
支持为主（帮助、参与、促进）
管理风格：支持型
规范
描述：非常默契的阶段。士气最高
支持、指导力度低（进一步放权：信任、授权）
管理风格：授权型
表现
遣散
团队建设&项目经理的管理风格
图：塔克曼阶梯理论指标特征：1. 绩效（工作产出）持续上升2. 士气在震荡阶段最低，而后快速上升领导团队策略：初期->指导为主中期->指导降低，支持为主末期->支持、指导均弱例外情况1. 阶段反复： - 例如客户新增需求，导致从第三阶段又到了第二阶段 - 团队有新成员加入，或有人员替换，可能需要从第一阶段重新开始2. 阶段跨越：项目直接从第三阶段开始（没有磨合）：新项目，老团队
团队规则
创建公平环境
带领团队持续学习
锐意进取，设置更有挑战、更新的目标
阳光、积极心态
文化与价值观
尊重与信任
鼓舞和表扬每一个进步，和对团队的每一个贡献
有效的激励
领导团队- 促进团队成长
促进团队磨合，增进了解
灵感源泉、创新动力
暴露问题，降低风险
及时认识问题，及时优化决策
加速决策，改进管理
冲突的好处
项目经理需要及时判断是否为良性的冲突- 良性：对事不对人（不需要过多干涉）- 恶性：及时制止
强决策（决策效率高），体验差- 上下级关系，通过命令加以统一- 一赢一输
紧急&重要情况下使用，此时以大局为重
场景
强迫命令
强决策，体验好- 双赢的解决方法。解决的很彻底- 影响最持久，效果最好- 双赢
不紧急&重要- 寻找双方诉求并不矛盾的点，是否可以皆大欢喜
合作/解决
两个维度均适中- 双方讨价还价，各让一步- 双输
紧急&不重要
妥协/调解
弱决策，体验差- 搁置争议，后面再解决- 双输
不紧急&不重要
撤退/回避
弱决策，体验好- 冲突一方主动让步- 一赢一输
缓和/包容
解决方法
区别：合作/解决：双方真实需求不冲突，可以达到各取所需的结果妥协/调解：双方利益有一定程度的损伤
分析产生误解的原因
引导各方达成都能接受的目标
制定精致的任务书，大家进行签名
达成阶段性的目标，一起吃饭
及时表扬团队成员
集中办公（项目团队成员能够处于同一物理环境）
建立war room
项目启动会与开工会
里程碑（项目阶段目标达成时）、项目例会
任命和授权
各种庆祝活动
定期团建和表彰
时机
创造必要的仪式感
凝聚共识
冲突管理
办公成本低，人才来源广泛，灵活性与自由度高
优势
信任度差，沟通低效，工作氛围差，激励与约束弱
劣势
vs 实体团队
成员参与项目的方式，交付时间，交付标准
清晰的规则
特别是开发，要把交接的流程定的非常清晰
标准的流程
任务要分的更细
具体的任务
合适的写作平台
合适的工具
线上投票等决策机制
民主的机制
加强沟通
积极的互动
时间、资源储备都要留足（资源方面要有backup，以免团队成员掉链子）
充足的储备
及时的复盘
参与方案(如何做好虚拟团队)
虚拟团队(临工经济)
清晰明确沟通顺畅及时回顾
照顾别人的感受
解读对方的情感和意图
正能量
善于维护亲近的关系，也能保持独立自我
深刻理解“意图与结果”的差异，根据对方反馈调整自己
朋友圈广，接纳度高
习惯鼓励和赞美
高情商的特征
感知他人情感的能力
关注他人情感的意愿
影响他人情感的能力
掌控自我情感的能力
评估情商
尊重差异
给大家有意义的愿景和有挑战的目标
平等民主的氛围
充分的尊重和信任
团队归属感和有效指引
不断认可和有效激励
面向体验
如何提升情商
基本关注点：进度、成本、质量
了解他们的需求和目标
支持团队成员的成长
经常复盘，给成员建议
参与和反馈
解决和消除影响发展的障碍
参与决策，不能一言堂
进阶关注点
每个人都能知道自己和哪些工作，有什么样的关系- 类似RAM：责任分配矩阵
作用
R：负责
如果有问题，谁来拍板负责
A：问责
有谁来提供解决方案和建议
C：咨询
告知
I：通知
RACI矩阵
支持团队绩效
团队成员
多采用领域专家进行培训
领导、客户、供应商
提供适当的培训
团队绩效的提升
改善&提升团队绩效&有效性（回顾/复盘会（Sprint））
Method
完成一个阶段/一个迭代
When
针对人，而不是项目（事情）本身
Target
团队协作是否高效？沟通是否顺畅？哪些需要提高？
How
团队绩效评价
挣值分析：执行的绩效与项目计划是否吻合
针对事（项目），例如进度是否延误，成果在质量上是否合格
项目绩效评价
1. 互相尊重，彼此欣赏2. 开诚布公，荣辱与共3. 持续学习，挑战现状4. 优势互补，成就对方
是否满足以下4个方面
团队成长评估
团队
直接支持项目：供应商、分包商、公司各个职能部门
参与者
不参与（影响者/受影响者）
维度1：直接/间接
受益者
受损者
维度2：利益
PMO、项目管理办公室、职能经理、团队成员
内部（和项目经理最近）
供应商、外包商、政府、媒体
本地
供应链、物流、仓储、协会、组织
国内
国际客户、合作伙伴
国际
维度3：关系远近
投资人、客户
供应商、分包商
职能部门（职能经理）
项目团队成员
维度4：职能
干系人分析维度（识别干系人）
无(0)，弱(1)，中(2)，强(3)，极强(4)
影响力
I-启动，P-规划，E-执行，C-收尾
影响阶段
-2: 会极力破坏这个项目，无论是否征求意见-1: 会反对，但如果强推也没有办法强制阻止
抵制(-2)，反对(-1)，中立(0)，支持(1)，推动(2)
态度
干系人评估（打分）
支持者：直接谈行动
反对者：直接谈后果
中立者：谈利弊（不做会有哪些坏处，做了有什么好处）
未做决定者：主要谈好处
未获信息者：主动谈信息（主动说明项目情况）
Tiger：充分合作
深-支持
Snake：积极争取
深-不支持
Monkey：密切观察
浅-支持
Ant：保持关注
浅-不支持
影响力 X 态度
密切管理，了解他们的体验、态度和意见
第一象限：权力大、利益密切
尽量满足他们的需求- 由于对于他们利益相关度低，需求较少，尽量避免受到他们的阻挠
第二象限：权力大、利益不密切
定期监督，保持关注，不要忽视他们的存在
第三象限：权力小、利益不密切
及时知会，积极主动保持沟通，争取理解和支持
第四象限：权力小、利益密切
权力利益矩阵（分析工具）
Step1：干系人分类，哪些反对，哪些支持
Step2：整合资源，让支持者帮助项目经理说服反对者
行动
策略
维基百科的创建
小米系统的迭代更新：粉丝提出系统改进建议
互相竞争，互相提升
京东 + 天猫
共创模式
干系人管理
例：IT信息化管理系统的开发项目- 客户总经理：关心项目初期和交付阶段，但对于中间的细节不关心- 财务职能经理：可能会额外增加他的工作量
创建干系人登记册
1. 盘点各个干系人目前的态度和期望态度2. 决定该采取何种的措施已达到期望的目标态度
目标/用途
不知晓：对项目和潜在影响不知晓
抵制：知晓项目和潜在影响，抵制变革
中立：知晓项目，既不支持，也不反对
支持：知晓项目和潜在影响，支持变革
领导：知晓项目和潜在影响，积极致力于保证项目成功
信息1：对项目的态度分级
C：当前状态
D：期望状态
信息2：每个干系人目前的态度是什么，期望的态度是什么
维度
控制干系人的参与程度（参与程度评估矩阵）
交付成果、需求相应、工作效率、专业程度、冲突处理、沟通协调
干系人关心的6大维度
干系人满意度评估（3-33节）
与干系人协作
干系人的影响方向
绿色：凸显性低蓝色：凸显性中红色：凸显性高
凸显模型 - 干系人的评价（权力*紧迫性*合法性）
蓝色：这一类干系人具备的特点
灰色：触发条件。若干系人得到灰色条件，则会变为蓝色，此时干系人评级发生改变
尽量避免干系人向更高的凸显层级触发，避免节外生枝
管理目标
干系人管理(根据干系人评价分级)
干系人的参与度（4-18节）
干系人(Stakeholders)
没有明确的项目经理岗位
敏捷场景强调“自组织”，即去中心化（没有领导），鼓励是人人都是项目经理- 共同讨论，表决决策
不是团队领导
不做决策
不负责工作结果
不负责
警察：维护团队规则和秩序
不允许额外需求出现如果有新需求，需要对接PO进行评估
保安：保护开发团队，不受外界干扰
保姆：为团队提供支持和服务
教练：带领大家认识敏捷场景的规则和方法
警察：维持团队规则和秩序
负责
类似的角色：敏捷专家
\"项目经理\"
PO：收集整理产品需求，维护需求待办事项列表（backlog）开发团队
例如：8小时工作时间，应该只安排6小时工作量
控制团队工作时长
最合适的规模：7±2
控制团队规模
团队管理
合适的工作时长和规模能够带来最高的生产力
敏捷场景
人
需求识别、可行性研究、商业分析
阶段1：概念
解决方案、规划设计、预算编制
阶段2：规划
开发/施工、需求实现、执行与控制
阶段3：实施
交付验收、合同支付、总结经验- 总结经验教训，所有变更控制的文档和记录，形成组织过程资产
阶段4：收尾
组成
每个项目不一定都要经历每个阶段
化整为零，拆分大的目标位小的阶段目标，方便控制，项目成本，质量，目标更容易实现
目的
示例：工程行业
阶段划分&阶段关口
客户对交付物进行验收和确认
Step1：最终验收
关闭和客户合同，和供应商合同
Step2：关闭合同
完成财务结算（和甲方完成收款，和分包商、供应商完成付款）和决算（公司内部对项目的投资，收益率报，回报率的计算）
Step3：财务收尾
调查相关方满意度，有何建议，以后的合作如何改进
Step4：相关方满意度
文档、数据、登记册、日志进行归档。包括项目开发的每一种计划，以及项目中的模板
Step5：归档工作
总结经验教训，更新组织过程资产
Step6：经验教训
Step7：庆祝会
释放项目资源，解散团队
Step8：解散团队
流程
注意先后顺序
见“环境”-“项目收尾&组织过程资产”，2-31节
合同收尾 vs 行政收尾
结束项目和阶段（项目收尾，4-31节）
阶段
5个过程组：启动、规划、执行、监控、收尾
49个过程
每个项目，每个阶段不一定要经历每个过程
定义了项目的每个阶段都要执行的步骤（标准套路）
没有严格的承接关系。存在明显的相互作用，在时间方面有overlap- i.e. 执行过程组贯穿始终- 规划过程可能影响执行过程，反之亦然
过程组&过程
一个完整的生命周期（时间维度上的划分）、不管每个项目都要经历
项目执行的方式，在每个阶段都需要执行一遍
过程
区别
以上学为例：- 每个人都要经历：小学、初中、高中、大学这四个阶段- 每个阶段都要经历学习的4个过程：听课、看书、写作业、考试以技术开发为例：- 阶段像是一个for 循环，每循环一次代表不同的阶段- 过程像是一个通用函数，在每个循环里都需要调用一遍
过程的输入、工具技术、输出
阶段（生命周期）的划分，不一定要保留每个阶段
开发模式的选择：敏捷、增量、迭代
裁剪的对象 (What)
项目的进度，范围，成本，资源
质量和风险之间的相互制约
公司的制度、考核
项目环境
严格还是包容？前者不能茅台大的风险
组织文化
干系人的需求
考虑的因素
裁剪
阶段 vs 过程
代价最大，商誉和口碑受损
Level 1：用户发现缺陷
i.e. 普通球迷只关心结果（谁赢了）
结果合格
归因分析，找到质量差的原因，并加以改进
自己有质量检查和纠正的办法
Level 2：QC (质量控制)- 结果检查和纠正
i.e. 专业教练关心球员是否把教练的战术部署，战略规划执行到位
过程合规
例如：通过制定标准，来从根源上避免误差
通过控制生产过程，来控制质量
Level 3：QA (质量保证)-过程保证
例如，在设计时充分考虑：好加工，好装配，好搬运，好修理等
家具规格统一，例如不同的柜门以45cm的倍数设计，方便运输
融入用户参与：模块化设计，用户使用简单工具可以完成组装，避免高昂的组装成本
宜家：遵循模数化设计
在规划设计阶段就融入质量管理
Level 4：DfX-设计优化（Design for X）
聚焦客户
持续改进
全员参与
任何质量问题都应该有渠道，有方法被及时发现，及时被报告，及时被解决
有效沟通
只有保证过程合规，结果才有望实现质量合格
过程为中心
基于事实的决策
各专业各部门不能各自为战，应该互相进行有效的沟通配合
集成系统
企业应该建立一套系统的质量管理方法，来指导项目管理的实践
战略性与系统方法
Level 5：TQM-全面质量管理
质量管理- 金字塔分级
1. QA指向过程，QC指向结果。QC可以理解为质量检查 -> 针对结果的检查2. 所有的审计都是指过程合规。例如这里的“质量审计”，以及其他的财务审计，风险审计，项目审计等
各个部门，各自为营，有各自的流程。用户需求很难及时高效被解决
段到段
所有的工作都是从客户需求出发
所有的努力都是为了给客户创造价值
客户需求端 - 客户价值端
流程要实现端到端，而不仅限于某个部门
市场管理 - 理解客户需求
集成产品开发 - 实现客户需要的功能/产品
客户关系管理 - 对客户做出承诺
集成供应链 - 交付最终的产品/服务
客户服务管理 - 保护和客户的关系
最终实现客户价值
核心流程客户需求->客户价值
为核心流程提供支撑服务（中台）
支撑流程
端到端
聚焦于价值&驱动变革
为项目经理提供类似项目的资源：进度计划，预算计划模板
模板支持
例如，对于研发中的小批量采购的零部件，可以直接采购，而不用走招标流程
发起优化流程的动作- 当一个流程对公司很多项目都造成了阻碍
流程优化
PMO负责界定各个项目的优先级，进而合理地分配资源
资源协调
PMO事先定义好项目的决策机制：决策层级，决策步骤等
决策机制
支持类
服务支持
跟踪每个项目的偏差：成本是否超支等
跟踪预警
例如，不能简单以利润作为评价指标- 有些金牛项目天然利润很高，还有些是不以赚钱为目标，为了公司战略发展的项目
负责建立项目的评价机制
负责对多个项目的评价
绩效评价
监督类
管理监督
职责
模板、工具的支持，培训、顾问的服务
支持型
不仅支持服务，还提管控要求
控制型
完全控制，直接领导
指令型
类型
传统行业：工程建设行业
场景1
IT行业：瀑布模型
每个阶段按顺序排列，无法改变顺序
每个阶段都需要签字确认，确认后无法更改，才能进入下个阶段
场景2
1. 需求分析2. 方案设计3. 代码开发4. 测试5. 运维
预测型
按照版本迭代的方式进行开发，每个版本经历一个完整的项目循环-- 需求->设计->开发->测试
反复求精，从模糊到清晰，从简陋到精细
迭代型
逐块构建，逐块交付- 每次交付一部分完整的功能
增量型
对未来不确定性有更好的适应能力
对项目中的各种变更，新的需求态度友好
一个需求的变更可能会导致大量的返工
成本优势不明显
不适用的行业：硬件开发，工程项目
适应型(敏捷开发)
不同的项目阶段，采用不同的开发方法
主要思路
产品预研阶段：敏捷开发，根据客户反馈快速更新方案
产品开发阶段：瀑布开发
例1：不同的开发阶段
软件（操作系统）子项目：敏捷开发
硬件子项目：瀑布开发
例2：不同的产品模块
混合型
项目的生命周期
1. 彼此是连续的，可以随时进行相互转化。2. 每个项目都可以在连续区间内找到一个点，根据项目背景实现最佳平衡3. 无论哪种生命周期，都需要计划，计划贯穿其中div data-t=\"flow\" data-processon-v=\
对比&总结
1. 项目生命周期只是产品生命周期的一小部分，只参与产品开发2. 开发和运营独立
传统
首先开发MVP，接受客户反馈/市场验证，通过运营不断迭代更新产品
开发和运营同时存在
产品需要有快速转型升级等能力
产品需要持续运营
敏捷
项目 vs 产品
生命周期划分(4-15至17&92)
适当开放隐秘区，以获得更多盲目区的信息，扩大开放区
乔哈里窗（4-19节）
闭环的沟通模型：接收方（听众）及时给与反馈，能明显提升沟通效率，提高沟通漏斗的转化率
沟通完成后，最好需要让接收方再反馈一遍沟通内容或者需求内容e.g. 我不知道刚才有没有讲清楚，你是怎么理解的？
及时反馈（4-20节）
单位时间里，沟通的核心信息不能太密集
信息过载
对沟通内容有足够的知识储备
缺少知识
不懂专业/技术术语
文化差异
寻找适合交流的环境
分散注意力的环境因素
避免成见，客观沟通
有害的态度
情绪
沟通渠道过多
多表扬，少指责
选择性的认知
因素
不同干系人对项目目标的理解不同
人力、设备、材料等资源的竞争
人员之间的冲突
对变化的抵制（新技术，新流程）
本质原因
简化语言（简化表达）
视觉辅助手段
积极倾听，不要轻易打断对方
有效的反馈：双向沟通，实现闭环的沟通漏斗
情绪控制
提升沟通技巧（4-23）
影响沟通的障碍（4-22节）
双向闭环。i.e. 面对面沟通
效率高，但规模受限
交互式
单向（被动接收信息）。i.e. 邮件信息方式推送信息
批量发送，范围广，但效果不佳
推式（Push）
单向（主动获取信息）。i.e. 文章订阅，在线视频，需要主动浏览
适合信息多，受众广的情况，但效果不佳
拉式（Pull）
沟通方式
有效的沟通
项目经理在信息传递的过程中：- 需要检查确认接收人有相应权限- 若接收人没有权限，可能要对信息做加密处理
谁需要（哪些干系人/相关方）什么信息- 是否有权限？
Who&What
e.g. 每天发还是每周周例会之前发即可
什么时候需要这些信息
信息应该储存在什么地方
Where
应该以什么形式储存
如何检索这些信息
是否需要考虑时差、语言、跨文化等因素
Other
沟通管理（规划）- 需要考虑的因素
Correct Grammer & Spelling正确的语法和拼写
Concise Expression & Elimination of Excess Words简洁的表述和无多余字
Clear Purpose & ExpressionDirected to the needs of the Readers清楚的目的和表述（基于表达对象的需求）
Coherent Logitcal Flow of Ideas连贯的思维逻辑
整片文字中，段落之间应该由承前启后的衔接关系，头尾要呼应
Controlling Flow of Words & Ideas受控的语句和想法承接
书面沟通的5C原则
沟通路径个数： 其中，n代表人数
沟通路径（4-21节）
会议要切题
准备并发布会议议程，包括会议目标
严格控制时间：按照计划时间开始，计划时间结束
汇报者，或需要发表意见的人
决策者
责任人：对会议决定承担责任
确保适当参与者受邀并出席
明确完成指标
明确完成时间限制
明确负责人
记录所有的行动（或决议）
会议管理
实现规定好，对于回忆中的问题和冲突，要怎么统一决定？谁来做决策
沟通
项目管理信息系统（PMIS）配置管理软件
使用自动化的工具
横道图、网络图、看板、燃尽图
可视化管理工具
知识的收集、整理、传达和分享
项目知识管理
前期商业论证 + 后期运营（获取用户反馈，持续改进）
工作向两端延伸
增加项目经理的职责
例如在不同阶段采取敏捷和瀑布的方法管理项目
Scrum（敏捷）、精益、看板混合使用
混合型的方法
发展趋势
搭团队，分工
资源
摆平冲突、矛盾、各方妥协以达成都接受的方案
平衡竞争性需求（需求整合）
收益、风险的整合
研究各种备选方法（项目的方法和路径）
49个过程取舍，如何裁剪与搭配？
过程裁剪
进度、成本、质量之间的平衡和取舍
知识领域之间的关系
整合什么？
整合管理
客户
供应商
例如，有更好的技术方案
己方团队
谁会提出变更？
常设：项目整个生命周期都有
团队成员可能会变
未固定：各方组成，均参与决策
由项目发起人组成的一个常设，但未固定的正式团体
负责影响基准的变更
拒绝后不能再提出同样的变更请求
CCB是变更的最高决策机构
变更控制委员会-CCB(Change Control Board)
谁能决策变更？
见1-2流程图
变更流程 & 变更原因
有助于保护历史绩效的严肃性
对基准的变更，仅对今后的情况有效，不影响以往的绩效
准则
团队成员发现项目偏差：工期不够，质量不符合要求等
项目经理负责纠偏决策：是否要进行变更
偏差的监控与修正(4-94节)
防范，纠正，缺陷补救（亡羊补牢）
变更的应对措施
整体变更控制
不同类型项目的范围管理区别
需求管理计划：用户想要的
范围管理计划：为了实现需要，项目要做的工作- 范围来源于需求，但不等于需求，因为有些需求并不能满足
需求 vs 范围
收集需求
访谈
针对某一个主题进行讨论：例如信息安全主题
焦点小组 (Focus Group)
问卷调查 (Questionnaire)
通过学习标杆产品来提升自己的产品
标杆对照 (benchmarking)
和客户一起解决问题
联合应用设计或开发（JAD）
需求的识别
例如：屏幕相关（全面屏、曲面屏），摄像（美颜，超广角）
需求的整理归类
亲和图
进一步的专业分析。需求描述翻译（质量展开）为专业的技术指标
维度1：原始的用户需求表达
维度2：转换后的工程性能指标
维度3：竞品对比
维度4：需求优先级
维度5：冲突标记（标记冲突的需求）
+维度5：标记冲突的需求。例如电池容量&待机时间长和超薄冲突
+维度4：优先级排序
+维度3：竞品比较
维度1*2
用户原始需求 -> 设计语言
Step1：产品规划矩阵
转化为技术工程师理解的语言- 例如超广角->16毫米镜头
设计语言 -> 零件特性
Step2：零件规划矩阵
转化为生产部门理解的语言- 例如16毫米镜头->厚度不超过3mm
零件特性-> 工艺要求
Step3：工艺规划矩阵
转化为工人、技术员理解的语言- 例如厚度不超过3mm->控制误差在0.1%以内
工艺要求-> 生产要求
Step4：质量规划矩阵
创建步骤
质量功能展开（QFD）(Quality Function Deployment)
需求收集的工具
一致同意、大多数同意、相对多数同意
投票
独裁
方案层
准则层
目标层
多标准决策 - MCDA(Multi-Criteria Decision Analysis)
分类
详细说明
完成情况跟踪- 需求被确认、更改、实现都需要进行标记
要素
确认的需求都应该翻译为用户故事写在backlog里
敏捷开发
确认的需求应该写在配置文件里。例如最终版本包含哪些功能点，都应该是该产品的配置
经典瀑布式开发
需求的转化
需求文件与需求跟踪矩阵
工具
需求决策
目的：收集用户需求
收集完成后，可以使用亲和图对用户故事进行归类
需求描述
工具：用户故事卡片（User Story Card）
Given（在什么样的情境或条件下）
What（做了什么操作，采取了什么行动）
Then（得到了什么结果）
验收标准
用户故事
第一个版本（最小可发布版本MMR）要实现哪些功能？后续各个版本要补充哪些功能？
目的：确定用户故事开发的优先级
业务流程（时间线）
商业价值
用户故事地图
系统交互图
先做一个产品或功能的原型，以此和客户进行需求的确认
原型法
例如：可视化剧本和演员沟通
故事版
需求的呈现和表达
关系:渐进明细的过程
i.e. 章程：高层级项目描述、边界定义以及主要可交付成果项目范围说明书：项目可交付成果（与章程的这一条相对应）
项目章程 --> 项目范围说明书
项目范围说明书
可交付成果Deliverables
子项目Subproject
财务口径的最细粒度，用户统计和分析项目成本，管理预算
一般和团队对应，例如开发团队的工作对应一个控制账户
控制账户Control Account
WBS的最低层次单元，也是项目经理管理到的最低层次单元- 例如：支付系统的开发
到项目经理
到团队- 例如支付系统开发中的系统设计、产品开发、测试
活动Activity
到人（由活动继续拆分得到）- 例如支付系统代码开发 -> 接口开发 -> 微信支付接口、支付宝接口
任务Task
拆解
并不是WBS的组成部分
工作包Work Package
与工作包的区别：同一层级，但不是立即要去做，处于规划中（还不确定要多少人天等）等到合适的时候，才能去准确的评估
规划包Planning Package
组成部分
WBS是三大基准的来源：项目范围（三大基准之首）、进度、成本
进度基准、成本基准依据于范围基准
基准的来源
项目子计划（进度、成本、质量、沟通）都依赖于WBS来制定
计划的基础
结构化层次化展现了项目全貌
工作的展现
WBS里面没有的工作，就不在项目范围，新增需求需要进行项目范围变更
控制的依据
团队成员对工作由清晰和统一的认识
团队的指南
WBS的价值
工作分解结构WBS(work breakdown structure)
目录式分解WBS- 1：子项目 --> 1.1：控制账户 --> 1.1.1：工作包- 每个工作包有唯一编码
1. 针对每个工作包，呈现详细的要求和信息2. 一个工作包有这样的一个表
隶属于哪个控制账户
控制包的编码
控制报的负责人
工作包的交付成果、质量要求、成本
交付日期
关键信息
WBS词典
范围基准(Baseline of Scope)
RAM - Responsibility Assignment Marix-和WBS配合使用，将工作包落实到人的工具(每个工作谁来负责，每个相关人的角色是什么）
负责：每个工作包必须要有负责人，且唯一
辅助：参与者
通知：知会工作进展和结果
审批：工作是不是能够通过验收，需要做验收拍板
承包：有谁负责把它外包给外包商或协作团队
责任定义
RAM责任分配矩阵
每完成一部分工作，需要及时进行质量控制检查/及时和客户确认（是否合格，是否满足客户要求）- 只有每一项工作均能完成范围确认，才能最终完成项目验收（不要统一堆到项目验收再全部确认）
确认范围vs质量控制
乙方主动增加的需求
维护和客户的关系
主动进行的升级（为了保证各个功能的配置一致，在同一个水平线上）
为什么会出现镀金？
镀金 (主动)
甲方要求增加的需求
爬行 (被动)
要有规范的项目变更流程
如何避免
范围蔓延
共同点：均是范围发生了改变，且没有经过变更整体控制程序
范围 & 需求管理（4-32至43节）
PDM: Precedence Diagramming Method
前面工作结束，后面才能开始示例：淘宝购物
FS: Finish-Start
示例：摊煎饼AB顺序不能颠倒，但A开始后，B就可以开始做
SS: Start-Start
示例：拍电影A结束后，B才能结束
FF: Finish-Finish
这里的start指的是B任务
示例1：系统升级新系统上线工作后，老系统才能关闭示例2：交接班。下一位同事来之前（开始之前），上个人不能走
SF: Start-Finish
逻辑关系
SS与FF逻辑本质上是一样的，但根据某个工作的侧重点不同，需要选择一种主要的逻辑关系- 例如：拍摄和剪辑之间，剪辑的人更多关心拍摄什么时候结束，这样才能决定剪辑什么时候结束，
内部依赖
例如政策性的限制
外部依赖
选择性依赖
工作B必须依赖于工作A完成后才能开始
强制性依赖
依赖关系
下一个工作往后推N天
意义：给项目带来弹性
滞后量
压缩工期
提前量
滞后量 (Lag)&提前量 (Lead)
紧前关系绘图法(PDM)
活动历时（固定不变） = 结束 - 开始总浮动时间 = 最晚 - 最早
活动表格
Step2: 向后推导 - 最晚开始、结束；关键路径4. G工作没有浮动时间，因此最晚时间 = 最早时间5. G工作最晚在8开始，因此，它的紧前工作E、F在最晚8结束即可6. 最晚 - 最早 = 1，因此浮动时间是17. 多个紧后工作选最小。即C不能晚于6结束，否则会影响F工作
关键路径：总浮动时间最小的工作所组成的路径（红色路径）
示例
浮动时间<0的情况此时需要优化工期（增加人力等方式）
浮动时间>0的情况，总工期宽松，有比较多的浮动时间
总浮动时间最小的工作所组成的路径
第4点：假如D工作需要4天，那么C、D都在关键路径上
第5点：假如D工作延误（所需时长增加），那么会导致关键路径转至D工作上
1.关键路径决定了项目的总工期2.关键路径所需要的时间最长3.关键路径上的浮动时间最少4.一个项目关键路径只能有一条5.活动延误可能导致关键路径变化6.关键路径上活动的工期可以压缩
关键路径特征
关键路径法-CPM(Critical Path Method)
注：G项目的最晚结束时间（10），可以根据每项工作推导得到，也可能是领导强制规定
规划工期时，每项工作均采用三点法（50%概率）估算工作工期和总工期
对于计划总工期和估算工期的时间差，作为项目缓冲，供项目经理进行支配
主要思想
以三点法估算时，每项工作按时完成概率为50%，但紧后工作D能够按计划开始的概率仅为15%
多个紧前工作汇聚时，会造成汇聚后的今后工作能够按计划开始的概率大大降低
原因
给非关键路径上的工作给缓冲时间
主动增加缓冲 - 接驳缓冲
剩余缓冲统一放在最后，作为项目缓冲池
解决
路径汇聚风险
关键链法-CCM(Critical Chain Method)
计划性：分解为阶段性目标
控制性：强制约束，控制各阶段目标实现
沟通工具：与管理层、干系人良好/高效沟通
分清责任：明确规定项目各方的责任义务
里程碑计划(粗粒度)
简明、生动通俗、实用
细粒度的任务安排
帮助项目经理判断任务风险（延误风险）
信息
无法帮助识别关键路径和关键路径上的活动- 非关键路径上的活动都有浮动时间
横道图（甘特图）(细粒度)
活动在节点上
能够反映4种逻辑关系
比较复杂
单代号网络图-AON(Activity on Node)
任务表示在路径上- 例如可以用\"3-4\"表示C任务
虚线：虚工作，不代表实际工作，仅表示逻辑关系- 例如C工作实际要在A、H完成后才能开始。
清晰
仅可以表示FS逻辑关系
双代号网络图-AOA(Activity on Array)
兼具网络图和横道图的优点- 网络图：逻辑关系清晰- 横道图：时间关系清晰
双代号网络图 X 时序
用于优化工期、成本、资源
波浪线：浮动时间，例如E工作在9天的范围内，任意2天完成即可
时标网络图
蓝线：当前日期
红线：实际进度
进度前锋线图
清晰展示哪些工作落后，哪些工作提前
网络图
进度计划（4-47节）
提前开始下一个工期- FS 改为 FS-N
增加风险- 增加了后续工作返工的风险（如果前项工作出现问题）
代价
快速跟进Fast Tracking
增加资源，直接缩短工期
成本的增加
赶工Crashing
进度压缩
只有应用在关键路径上，才能有效压缩项目工期
处理某时间段人员overload（资源过载）的问题
解决的问题
延长工期
资源平衡
解决方案
问题：苏同学overload（1天要干16小时）
解决资源数量波动的问题，避免资源浪费（拆东墙补西墙）- 不会影响工期
例1
将B工作向后挪动，先干A工作，再干B工作
例2：A、B均处于非关键路径，且分别需要3个人。由于C工期长于A、B，因此AB的人员可以缩减为一共3个人
如果关键路径面临无法按时完成的风险，那么可以适当分配非关键路径上的资源到关键路径
做法
资源平滑
资源优化（4-59）
进度管理
直接：材料成本，人力成本（项目推进就要花钱）
间接：房租，水电等一直会支出的成本
直接vs间接
黑色曲线最低点为最优工期
固定成本：投入的固定资产 (i.e. 设备)的成本
可变成本：材料费用，人工费用
固定vs可变(盈亏平衡分析)
机会成本
项目已经投入的成本
沉默成本
机会成本vs 沉默成本
在项目设计阶段，就要考虑整个项目过程中所涉及的成本- 有时候项目材料的节省，很可能会导致项目后期成本的增加- 例如：鸟巢取消了顶盖涉及，虽然节约了施工成本，但造成后期运营维护成本增加（无法全天候使用），可能无法收回投资
全生命周期成本（理念）
成本的分类
精确度等级
目的：避免项目资金链断裂
用法：项目资金支出计划（花的钱）与资金到位承诺（收的钱）做对比，调整工期和资源投入
资金限制平衡
工作包成本 = 活动成本 + 活动应急储备成本控制账户成本 = 工作包成本 + 工作包应急储备成本
成本基准（=项目成本=完工预算) + 管理储备 = 项目预算- 项目成本 ≠ 项目预算- 项目结束时，累计的成本基准就是完工预算
管理储备是高层为了应对项目经理无法识别的风险所做的储备- 只用于应对“未知-未知风险”
应急储备：项目经理负责，应对“已知-未知风险”
项目预算的组成
自下而上进行成本汇总
成本的估算和预算
成本管理(4-55至4-58)
等级高不一定质量高
等级vs质量
精确度高 -> 方差小（多次射击，命中在一个很小的范围）准确度高 -> 偏差小（多次射击，都能命中，但各个命中距离比较大）
精确度vs准确度
等级与质量精确度与准确度
- 质量是设计出来的
质量管理的观念
主动预防
场景：预防性质
预防成本：打造高质量产品付出的成本- 员工培训、设备维护
评估成本：评估质量付出的成本- 测试、检查
为了防止最后的产品质量不合格，提前做一些工作
一致性成本
被动修改
场景：纠正性质
内部失败成本：项目中己方发现的质量问题- 返工，报废
外部失败成本：客户发现的质量问题- 返修，召回
预防失败，最终还是出现了质量问题
非一致性成本
质量成本（COQ）
发展趋势(4-61至63)
先拆分大的类别，每个大的类别下再细拆
适用场景：根本原因分析
鱼骨图(因果图)
1. 基本符合正态分布
2. 数据全部在规格以内（全部在上&下规则线内）
3. 均值和上下规格先均值一致（处于正中间）
4. 上下规则线的设置，应位于均值的4倍标准差的位置
适用场景：质量检查结果分布分析，并满足以下要求
偏态分布：技术、习惯原因造成，为异常生产情况
锯齿分布：分组不当，或测试方法和读数有问题
孤岛分布：工人不熟练或交接班失误造成
陡壁分布：由剔除不合格品、外品或超差返修后造成
双峰分布：由两种不同的分布混合在一起检查的结果
平峰分布：由缓慢变化的因素起主导作用的结果
类型分析
双侧无余量型：实际样本的质量数据接近上下限，如果工序稍有变化，则很容易出现质量问题
余量过富裕型：质量要求太严格，应适当放宽工序能力指数，以降低成本
平均值偏离型：平均值过于偏左。为了降低不良率，应该调整工序中心使之接近规格中心
不好的直方图
直方图
适用场景：质量问题相关性分析
变量相关性分析发现质量问题
散点图
适用场景：重点（主要）原因识别
对质量问题进行记录和统计数量
Step1：汇总计数表 (检查表)
Step2：按照出现次数进行倒序排序，判断从主要质量因素
帕累托图(2-8原理)
A、B占到了总故障的80%，为主要原因
散点图帕累托图
适用场景：寻找异常情况
1. 当产品的质量数据连续7点位于均值一侧
2. 连续7点呈单调上升或下降的趋势
3. 当数据出现在控制线之外（虽然在规格线之内）
问题判断准则
如果出现任意一种情况，则需要停工找原因- 规格线：4倍标准差- 控制线：3倍标准差
控制图(7点法则)
适用场景：解析产生缺陷的原因，进一步找到改进方法
MAN(人)
Machine (机器设备)
Material (材料)
Method (方法/工艺)
Environment (环境)
问题分析维度(数据分层法：4M1E)
层别法
管理&分析方法与工具
总结：1. 鱼骨追原因2. 检查集数据 - 检查表用于收集统计异常记录，并归类3. 直访显分布4. 控制找异常5. 帕累托重点 - （2-8原则）6. 散点看相关7. 层别做解析
识别过程低效或质量低劣的原因建议或采取相应措施解决这些原因
确认项目可交付成果及工作满足主要相关方的既定需求，满足验收要求
把可能出现质量问题的点，总结成清单，一个一个核对
核对单（check list）
统计抽样
过程决策程序图-PDPC(Process Decision Program Chart)
质量控制
质量管理
对于某个工作包，自己干还是找供应商干
概念
决策的因素
自制外购分析
甲方先找设计方做设计方案根据设计方案招标施工方施工方在进行具体的施工建造
传统模式
甲方承担了大部分工作，需要做大量的协调工作
设计-招标-建造模式（DBB）Design-Bid-Build
设计、采购、建造 (Engineer-Procurement-Construction) 打包在一起，交给一个总承包方- 总承包方进行统一协调，减小成本，减小沟通成本
甲方只需对接总承包方即可
总承包-EPC
甲方一定是政府
案例：北京机场高速建设- 投资款、建设、50年的运营权都由乙方负责，政府不出钱，50年后收回运营权
BOT- 建设&运营&移交(Build Operation Transfer)
投资、建设由乙方负责，建设完成后政府付款，交付给政府
BT- Build Transfer
政府和企业合资建设，成立合资公司，由甲乙方关系变为合伙人方式
PPPPublic Private Partnership
特许经营
交付方式
总包合同（总价包死）
固定总价合同 (FFP)Firm Fixed Price
1. 成本按预算控制
2. 另加约定费用作为利润- 激励费是事先约定好，可以明确算出来的
3. 如成本超支或节约，按约定比例分担（一般甲方大头）
4. 设定甲方额外支付的上限（天花板价格）
总价 + 激励费 (FPIF)Fixed Price + Incentive Fee
若原材料由于物价波动产生变化，甲方承担物价变动带来的费用- 物价上涨，甲方额外多支出- 物价下降，甲方额外收回一部分费用
卖方履约期跨越几年时间
以不同货币支付货款
适用场景
总价 + 经济价格调整 (FP-EPA)Fixed Price-Economic Price Adjustment
总价类合同
举例：预算成本300万，费用100万，天花板价格450万如成本超支或节约，按80:20分担或分享。如果实际成本400万甲方应给乙方结算多少合同款 ?300 + 100 +(400-300) * 80% = 480；此时超过天花板价格，因此仅支付450
乙方实报实销，花多少甲方都得认
基本特征
成本实报实销 + 额外给固定的费用（作为乙方利润）
成本+固定费 (CPFF)Cost Plus Fixed Fee
上例中：如果是CPIF合同，则支付480
与FPIF的区别：没有天花板价格限制
成本+激励费 (CPIF)Cost Plus Incentive Fee
成本实报实销 + 甲方根据乙方表现给与奖励（甲方给多少乙方拿多少，乙方无法申诉）
成本+奖励费 (CPAF)Cost Plus Award Fee
成本补偿类
按照人工、材料参加报价，乙方用多少，甲方付多少
工料合同
采购合同
甲方出具，关于需要乙方具体做什么的说明- 比较细、比较实
工作说明书-SOW
工作的范围、性质- 比较虚
工作大纲-TORTerms of Reference
选择合格的分包商
目的：让对方提供一些能做这件事的基本信息
信息邀请书-RFIRequest for Information
对方提供信息 + 报价
报价邀请书-RFQRequest for Quotation
对方提供信息 + 报价 + 计划方案
建议邀请书-RFPRequest for Proposal
招标文件
采购文件
负责人：项目经理撰写vs 范围说明书- 范围说明书是对当前这个项目要做事情的描述- 采购-工作说明书，只是关于这个项目其中一部分需要分包商来完成的工作的说明
负责人：采购部门负责
维度：成本、资质、技术/质量、来源
采购过程中，实现确定依据
供方选择分析
描述清楚外部的这部分工具，具体想要做什么- 顾问类，咨询类的，准备好TOR
Step 1：准备SOW或TOR
请第三方造价咨询公司进行估价：标底价
拦标价：在标底价的基础上加上一定的比例。任何投标方报价高于这个价格则默认废弃
独立估算
Step 2：独立估算，确定标底价
包括供方选择分析，编制招标文件
Step 3：确定选择供方的方案
Step 4：发布招标公告
筛选合格的卖方，确定卖方清单
Step 5：卖方资格预审
主要作用只是声明甲方招标过程的合法、合规和有效（澄清招标文件）- 确认甲方给各方的招标文件和资料都是一致的，清楚的- 对于文件和资料问题，负责给投标人答疑- 投标人已经是合格的卖方
Step 6：召开投标人会议
投标人准备标书，完成后，组织专家评标：- 建议书技术评估- 建议书成本评估
Step 7：组织专家评标，确定哪一方中标
澄清合同内容，对合同的条款一一梳理确认，确保双方对合同的理解保持一致，避免理解歧义- 条款包括：责任、变更的权限、使用的条款和法律、技术和商务要求、所有权、合同融资、技术解决方案、总体进度计划、付款以及价格等
中标价格，交付期限，质量验收标准，工作范围
不涉及的内容
Step 8：与中标方采购谈判
Step 9：签订采购合同
采购流程
甲乙双方谈判解决
请第三方评判
替代争议解决方法-ADR(Alternative Dispute Resolution)
仲裁
诉讼
争议解决(4-76)
检查在采购执行的过程中，和采购管理计划中定义的规则流程是否一致- 先有采购管理计划- 不关心采购结果
合规性检查
采购审计
关系维护 * 完成度
成功完成
完成度高，关系差- 甲乙双方经常有分歧，互相博弈，合作的不愉快
变更补偿
完成度低，关系差
仲裁诉讼
完成度低，关系好- i.e. 乙方能力不足以完成整个项目。在某一阶段协商终止
协商终止
采购的结束方式
定义清晰完整的项目需求
对技术规范负责：是不是符合技术标准和规范
技术经理
采购文件：采购合同是否合法合规
采购经理
责任
采购管理(4-69至77)
给风险排序：哪些是重要的，哪些是次要的。并不会真正计算风险带来的损失
定义风险的概率和影响
Step1：统一标准
1. 创建风险概率和影响矩阵（程度 X 概率）
风险高的部分（深灰色区域），单独归入风险短名单- 要做出详细的应对计划：谁负责，怎么解决？
持续监控
其他部分，归入风险观察清单
2. 归类
Step2：评估风险影响
定性分析
成本高，无法对所有风险都进行定量分析
针对特别重要的特定风险，准确评估影响
完成项目目标的概率 vs 项目预算(成本) 或 风险程度
蒙特卡罗法(Simulation)
其次，画图观察斜率，斜率越大则敏感性越高，最后整理成金字塔图
案例：各影响因素 vs 净现值- 首先列出各个影响因素每变化N%，目标值是多少
风险 (影响)因素 vs 最终结果的改变程度（因素每变化1%，会对结果产生N%的变化）
敏感性分析
思路：分开分析不同的决策，以及每个决策在未来不同机会条件下产生的期望价值
不同的方案以及对应的成本
决策节点
不同概率的机会下，产生的收益
机会节点
决策树
注：预期货币价值（EMV），就是期望收益
思路：通过相同的符号对风险/机会归类，并画出逻辑关系（线条的粗细表示逻辑关系的强弱）
影响图
方法
定量分析
Plan B：基本可以保持和原计划相同的效果
应急计划
根据当时环境，临时做出的解决方法，不一定会对最终指标效果产生影响
权变措施
保底方案：应急计划、权变措施失效，为了避免项目完全失败而采取的计划- 对原计划能达成的效果有较大损失，只能保留基本功能
弹回计划
措施分类
示例：奥运会火炬点燃，原计划由李宁采用空中飞人方式点燃，熊倪作为替补。如果以上两者都不行，则由姚明通过传统方式直接点燃- 李宁：原计划- 熊倪：应急计划（Plan B）- 姚明：弹回计划（保底方案）
主流程：原计划->应急计划->权变措施->弹回计划- 权变措施优先级大于弹回计划
应急计划 & 权变措施 & 弹回计划
都需要走整体变更控制程序
自动权变：紧急情况下，无需请示汇报，直接做出决策- 未知-未知的紧急风险才可以使用
措施的使用流程
已知风险：能够识别出来，并且也知道发生的概率，项目原计划已经考虑到了- 团队成员负责，因为通过WBS已经分为了不同的工作包和活动，已经明确了每部分工作的负责人
已知-未知风险：可识别（在风险清单里），但不知道什么时候，多大概率会发生
风险 vs 资源
应对措施&流程（4-82&83节）
i.e. 快捷连锁酒店，砍掉健身房、餐厅等成本高的部分，规避这几个部分产生的亏损风险
规避
降低风险发生的概率，或者减轻风险的影响- i.e 预防流感，打流感疫苗
减轻
买保险、找外包
转移
负面风险（威胁）
开拓
提高
个人搞不定，和他人进行合作，找投资人
分享
正面风险（机会）
应对策略
都适用的策略：1. 接受2. 上报
风险承受力 * 管理程序 (灵活、僵化)
同一个风险，发生在项目的不同阶段所带来的损失完全不同
风险（影响概率 & 损失量）vs 项目生命周期
影响策略选择的因素
风险：可能发生，但还没有发生
此时必须要面对和解决
问题：已发生
问题 vs 风险
例如：同一款APP，在安卓上发生闪退，但在IOS上正常- 安卓端：已经是问题，要立即解决- IOS端：是风险
什么样的问题应该在什么层级解决- 哪些问题团队自己解决，哪些问题需要上报给领导- 严重到什么程度就应该要上报
定义/确认问题上报路径和上报门槛
针对问题的准备工作
管理问题(4-87节)
风险管理(4-78至87)
交付物应该包含哪些功能，哪些组件
定义
产品的功能、组件、文档
项目的基准、计划、文件
组织过程资产：知识、经验、教训
包含的内容
包含的内容事先定义清楚，不能有缺失
完整性
产出和既定的配置一致
一致性
交付完整的内容，并且每个功能和组件满足配置计划中的质量要求
可控性
每个版本有独立完整的存档，方便出现问题时回滚至上个版本
追溯性
各个历史版本完整，可用，可追溯
版本管理
改变原来的配置，包括- 标识、控制、报告变更
变更管理
过程标准、合规：什么时候上线，什么时候做review
过程管理
文档完整、一致、及时更新
文档管理
配置管理
开发状态
代码管理：代码怎么写，怎么上传，避免多人工作不会互相冲突，覆盖
汇流管理
入门级-版本控制
项目级
Harvest
企业级
常用管理软件
案例：软件开发项目的配置管理
上周开发完成了5个功能点
成果是什么
上周使用了6个人*天
成本是什么
工作绩效数据
描述/跟踪现状
i.e. 上周完成的工作，和原计划相比，偏差是多少
在执行阶段客观产生的数据，经加工处理后，对管理、绩效产生指导作用的信息
受众：团队内部人员
结合成本、功能等多方面因素，在多种方案中选最优：例如在APP、小程序等
备选方案分析(Plan B)
按照目前项目进度，最终我们会delay多少？
趋势分析
现状与原计划的偏差：进度、成本等
偏差分析
分析方法
工作绩效信息
对比，计算偏差（现状vs计划）
绩效信息进行进一步分析、统计，提炼出逻辑性更强、具有明确解决方案的报告
受众：外部（客户，高层管理者，CCB-变更控制委员会）
普通：周报、月报
专项：变更控制报告、采购报告、挣值分析报告
包含
工作绩效报告
汇报进展 & 提交变更 & 辅助决策
数据&信息&报告管理(项目经理应该管什么)
流程： 数据 --(加工整理)--> 信息 --(统计分析)--> 报告示例： 开发中遇到了一个风险，技术难度过高无法短时间内解决 --> 原计划工期可能要拖延（工作绩效信息） --> 分析风险对项目产生的影响，制定出解决方案 例如：解决该难题需要延期一个月 --> 形成变更控制报告，向上汇报（CCB & 高层管理者）
帮助判断，用哪种开发方式来应对当前的项目
技术（确定性） * 需求（明确性）
预测型开发方式：按既定计划行事即可
1. 简单项目
技术成熟但需求不明确
混合型开发方式- 例如：预研阶段-敏捷；正式阶段-瀑布
2. 复杂烧脑项目
需求清晰但技术不确定- 案例：无人驾驶（技术不成熟）
混合型开发方式
3. 复杂棘手项目
不要接手
4. 混乱
敏捷型开发方式
5. 混沌
STACEY矩阵
帮助判断一个项目是否适合使用敏捷开发
3个大维度 -> 9个小维度， 分别打分
敏捷适用性评估
例如：项目A：开发一款小程序-> 敏捷方法项目B：开发一款商场的自动智能咖啡机-> 混合方法
选取合适的开发方式(4-91节)
Knowledge Transfer：教会客户怎么用
产品说明书
培训、演示
隐性知识
知识转移
类比估算
参数估算
三点估算
自下而上
资源估算
个体和互动 > 流程和工具- 更注重人与人的交流
工作的软件 > 详尽的文档
客户合作 > 合同谈判
响应变化 > 遵循变化
宣言(第一层)
更容易、更便捷的适应项目变化（不仅仅是快）
持续不断 & 及早进行有价值的交付使客户满意
有价值的交付
善于掌控变化：即使在开发后期也能欣然面对需求变化- 和客户更多地进行合作而不是谈判- 当发现新情况或需要改变现状时，可以及时变更敏捷计划
目的(成就客户)
业务与开发相互合作：客户<->业务<->开发-业务应该起到沟通桥梁的作用：及时澄清需求，及时传达客户反馈
相互合作
激发个体斗志；提供所需的环境和支持，信任团队，信任队友
激发和信任
一起办公，尽量以面对面形式进行沟通
面对面
合作
极力减少不必要的工作量- 例如很多文档都是不必要的
简洁
最好的架构、需求和设计出自组织团队
协商、表决来解决问题
自发性根据项目需要来工作：我需要，或者有人依赖我，那我就来工作
不是一开始就出现，而是一个团队不断发展，渐渐达成自组织
及时规范的以会议形式回顾总结：前期的不足和下一个冲刺中需要的改进- 从错误中吸取教训，不重蹈覆辙
短的，频率高的复盘
回顾总结
在较短的周期，经常性的进行交付：及时确认交付物是否满足客户需求
短周期
交付物是进度的首要度量标准- 交付物必须可以直接使用、好用- 使用“完成” 或 “未完成”来判断任务状态。已完成的要及时提交交付物- 百分比形式交付意义不大，都是未完成
可工作的交付物
持续开发、持续集成、持续发布
自动化测试、自动化部署
可持续开发
有新的不用旧的：鼓励采用新技术、新方法
技术卓越良好设计
开发
12原则(第二层)
实践方法：强调精益创业、设计思维
实践：产品管理的角度应该有精益思想
产品视角
实践方法：推动Scrum冲刺和极限编程- 冲刺（Sprint）：短而快
实践：掌握Scrum框架、看板敏捷管理实践
研发视角
实践方法：尝试SAFe、LeSS等规模化敏捷方法
实践：版本火车DevOps
规模化视角
敏捷领导力、敏捷中台... ...
其他
敏捷实践(第三层)
敏捷生态圈(敏捷实施框架)
敏捷价值观 -> 敏捷原则 -> 敏捷实践 -> 敏捷生态
最重要
管理层的变革意愿
公司对员工认知、审核、评估上是否愿意做出变革
敏捷强调个体和互动，管理职能要分散在每个团队中- 如果是集中的，则不好推动敏捷变革
项目、项目集、项目组合管理职能是集中还是分散的
敏捷对于控制短期的目标非常有效- 长期目标还是要使用瀑布型
专注于短期预算和指标而不是长期目标
不具备，则需要敏捷培训
人才管理成熟度和能力
评估敏捷变革可行性- 敏捷变革友好型特征- 指南6.1.2 变革就绪情况 P73
分散的项目组织可能会有很多阻碍工作进展的挑战- 敏捷12原则中：面对面交谈是最好的沟通方式
地理
高度职能型组织，不容易实施敏捷（各部门之间壁垒严重）
职能结构
是否可以缩小项目可交付成果来激励部门之间更频繁的交流- 频繁的交流，可以带来组织内更快速的价值流动
项目可交付成果的大小
是否可以保证从各个部门抽调的人员，可以完全分配到项目上
项目人员的分配
涉及到很多供应商，当供应商退出合约后：- 带走项目知识- 限制持续灵活性和迭代速度
重采购型组织
组织结构对敏捷环境的影响- 指南6.7 组织结构 P83
客户合作高于合同协商- 强调如何合作共赢，而不是合同条款
原则
变化因素隔离到单独的文档中，集中进行修改，简化修改工作量
多层结构- 简化合同
传统项目根据重要节点来交付，但这些节点不一定具备价值
以价值驱动可交付成果来设置里程碑- 每个里程碑，分别可以交付哪些价值
强调价值交付
尽量拆小项目的可交付成果，更加有利于和客户合作
总价增量
整体预算限定在一个固定的数额，但允许客户纳入新的观点和创新，但此时需要替换掉原来的一些计划项
固定时间和材料
预算固定，项目范围可以动态调整
动态范围方案
共担财务风险，早交付给奖励，晚交付交罚金
累进的时间和材料
如果在某个阶段，已经交付了足够的价值，如果客户不再需要剩余范围/价值，那么不必支付这部分费用
提前取消方案
供应商将人员派驻到项目团队中（融合成一个新的自组织团队）：资助团队而不是资助项目范围
团队扩充
要点
如何与供应商共赢？- 指南 6.3 采购与合同 P77
所有的项目都应该在合适的时间，为合适的客户提供合适的价值
价值驱动型
为了实现价值，PMO可能需要强制执行某些解决方案或方法
面相创新型
除项目管理外，要熟悉其他的技能
多学科型
提供敏捷场景的模板：用户故事、测试案例、累计流图
模板
提供敏捷工具
帮助小组了解敏捷开发概念
培训
制定和实施标准
协调敏捷培训、教练和导师。帮助员工尽快过渡到敏捷思维模式
通过培训和指导发展人才
通过不同项目交流协调敏捷团队
多项目管理
通过收集项目进度信息，获取、存储、回顾成果
促进组织学习
提供产品负责人培训、指导验收测试、评估方法，提供系统反馈
宣扬主题专家（SME）对项目的重要性
管理相关方
较传统PMO增加的一个职责- 传统项目中，该项由项目经理承担
负责招聘、评估敏捷实践者（例如敏捷教练）
招聘、筛选和评估项目领导
培训敏捷实践者（提供导师和教练）
执行专业化项目任务
敏捷PMO- 指南 6.6 敏捷和项目管理办公室 P81
仆人式领导
总原则
由团队中心转变为给团队和管理人员提供服务- 因为敏捷是去中心化的
促进团队合作，保持与相关方的需求一致
鼓励将责任分配给团队成员- 要求团队成员承担更多地责任
实践：提供指导、鼓励、帮助，为团队提供支持
实践：通过项目管理技术来帮助团队
促进团队成员成长
促进
实践：教育相关方，使其了解为何以及如何实施敏捷
实践：组织架构对团队产生障碍，就要项目经理出面沟通解决
实践：为团队与外部团队合作提供支持，起到桥梁作用
消除组织障碍
帮助他人成功
为他人贡献铺路
项目经理的角色- 指南 4.2
全职工作
小于10人团队
专门人员
拥有全职能能力，可以独立完成项目，应对频繁的开发和交付
通才：提升灵活性，胜任多个岗位
专家：提供专门技能
通才+专家组成
跨职能团队成员
高效沟通，致力于相互合作
知识共享，降低学习成本
集中办公 或能够解决不同办公地点带来的挑战
成员彼此依赖、互相认同，有利于实现交付
简化团队成本
方便知识资本的保留和发展
稳定的工作环境
成功的敏捷团队- 指南 4.3.1 敏捷团队 P39
产品负责人-PO
Scrum Master、项目团队领导、团队教练等
团队促进者
常见角色- 指南 4.3.2 敏捷中的角色 P40
例如：可持续的开发速度
团队价值观
定义“工作就绪”- DOR
定义“工作完成”- DOD
工作协议
约束团队成员的行为：例如会议上每个人都需要发言，不能超过5分钟
基本规则
例如：会议不能迟到
团队规范
敏捷团队章程- 指南 5.1 项目章程和团队章程 P49
对于超出团队章程的情况，SM可以和团队一起决定处理方案
实施敏捷(创建敏捷环境)
在团队内部，代表着客户方（甲方）
客户代表
产品负责人是所有需求的收口
定义所有产品功能
vs. 传统项目- 日期和内容是和技术团队讨论决定的，更多基于技术团队的能力，而非市场需求，可能会导致发布不合理
决定发布内容和日期
工作内容
vs. 传统项目- 传统项目中由项目经理决定
对开发功能排定优先级- 合理调整产品功能和迭代顺序
认同或拒绝迭代的交付
决策
vs. 传统项目- 传统项目很难找到一个明确的负责人
对产品的ROI (投入产出)负责
确保开发团队知道产品待办事项列表、回答业务需求方面的问题
讲清楚、弄明白需求的内容
产品负责人-PO (Product Owner)
决定了做什么，不做什么，什么时候做，做完后的验收
关注冗长的过程，识别阻碍因素，并联系相关部门解决这些阻碍
确保团队胜任工作，保持高效率
保证仪式，组织日常会议
鼓励言论自由；团队有问题，优先内部讨论解决
帮助团队排除障碍&保护团队不受外界影响，保持专注
更新冲刺并发布燃尽图或燃起图
不衡量团队成员个人表现：敏捷团队是自我管理团队
支持和保障工作（仆人式领导）
教练的职责- 促进者：领导团队完成Scrum的实践，体现Scrum的价值- 仆人式服务：保护团队，帮助团队
当团队表示有意见，不合适的时候，会导致生产力出现问题
生产关系
对生产工具进行补充维护和推广- SM 主动涉猎、认知一些先进的实践 (行业应用)，并理解这些实践对团队的帮助，引入这些先进的实践
生产工具
提高生产力
早期，与项目经理相对一致：制定规则、管理期望、管理相关方、制定沟通策略等
项目执行后：SM不做决策（信任团队自己做决策，去中心化决策 - 自组织）
vs 项目经理
服务式领导-SM (Scrum Master)
开发+ 测试 + support人员组成
自主选择（自组织）：自己选择自己愿意做的事情（自领状态）- 传统项目中，一般是WBS工作拆解下来后，分派工作
成员是通才/多面手：每个成员都能够做每个方面的工作（例如开发人员应该具备测试的能力）
全职能
100%专职成员，一个萝卜一个坑。没有结对编程的情况- 冲刺计划开始前，团队就应该和职能经理确认好资源，以免冲刺中资源变化
团队成员在一个迭代内尽量稳定
全职
识别出来问题来源于外部团队，需要拉着外部团队一起解决，而不是自己团队内部抱怨
外部团队问题（考试用到）
去中心化决策
决策在团队内
职能水平上没有划分：技术经理的角色不存在（即不会出现一个人指派任务让另一个人做）
平级
开发团队(Dev Team / Developer)
3种角色
不允许有任何的需求不进入产品待办事项列表
所有需求：业务需求，技术需求，NFR (非功能性需求，例如安全性，性能)等
在某个Sprint结束时，所有未完成的需求，都要重新返回到产品待办事项列表，PO重新评估优先级，而不能直接安排在下一个冲刺中
每个Sprint开始前，都需要修正优先级排序
每一项需求 (待完成的工作)都将对客户产生价值
排了优先级的需求池
负责创建&维护：需求、优先级
Product Owner
负责人
产品愿景（电梯演讲-Elevator Pitch）：出现在用户故事之前- 为了满足（目标客户）的需求（XXX）- 这个（产品名称）是一个（产品类别）类型的产品- 他可以（关键优点和使用理由）- 而不像（同类竞品），我们的产品具有（差异化的特点）
用户故事（user story）：表述需求的工具- 作为一个用户角色（XXX），我想要XXX，以便获得XXX- 详见“过程”-> “需求的呈现与表达”
条目以用户故事的形式呈现
只有进入迭代的需求需要尽量详细- 产品待办事项列表中每个需求不是都要非常详细
Detailed：适当的详细程度
PO只负责估算（大体估算），产品待办事项列表中具体要做多少，是开发团队决定的- 放多少-PO负责；做多少-团队决定
Estimated：估算的资源使用量
需求是涌现的。例如完成了一个版本交给客户后，客户会根据实际情况涌现出很多新的需求
Emergent：涌现的
Prioritized：排了优先级的
满足DEEP原则
Scrum团队进行产品待办事项列表梳理活动：向PO讲清楚每个需求和各需求之间的关系
Action
产品待办事项列表（Product Backlog）
- 仅对当前的Sprint有用- 一个Sprint中只做在迭代待办事项列表中的任务
用户故事：PO创建，来源于产品待办事项列表
任务：团队协商、共创出来的- 团队成员主动领取任务（不是用户故事）- 团队成员可以添加、删除、更改Sprint Backlog中的任务（不是故事）- 具体做多少，由团队自己决定（基于PO讲清楚需求的价值、内容和必要性），因此，敏捷中工作不是项目经理安排的，而是团队自己承诺的- 任务需要估计工作量，并每天更新剩余工作量（燃尽图）
用户故事 + 具体任务
任务可以变更故事不可变更
结构
迭代代办事项列表（Sprint Backlog）
某个Sprint的交付物 (可以发布的产品组成部分)- 集成至以往的迭代成果中，形成增量式交付
交付的用户故事必须符合验收条件（必须达到Scrum团队定义的质量标准）
增量成果必须可用（随时上线使用）- 不是一定会发布，PO决定是否发布（交付和上线）这个故事
要求
产品增量（Product Increment）
例题：你是一个适应型项目的项目经理，正试图了解实际进度，估计完成可发布产品所需的时间。为了实现这个目标，你会使用什么调度技术?- A：有待办事项列表的迭代调度 ×- B：敏捷发布计划 √- 解析：题目中提到可发布产品所需的时间。迭代调度（迭代计划）与发布计划不是强绑定的，迭代计划中的所有产出不一定都要发布
3种工件(工具)
1. 每个Sprint: 2-4周2. 每日站会（Daily Scrum Meeting）贯穿始终
冲刺(迭代)，是Scrum的核心
标准：在这个时间内，可以构建出一组可用/可发布的产品增量
长度应保持一致
1-4周
固定时间、固定活动，有明确的预期
优势：- 专注、增加创造力- 固定时间内可以实现可预期的价值（时间价值、效率高）- 可用时间多（只有4个固定会）
双周版本
时间箱
计划会 -> 站会 -> 下个Sprint的产品需求梳理会 -> 评审会 -> 回顾会
一个迭代中，不推荐做变化：每个人的职能尽量不变。要变也要再下个迭代中
规则
Sprint
PO拿着Product Backlog和团队讨论
重新梳理用户故事和优先级
为Sprint计划会做准备，梳理需求
整个Scrum团队：PO，SM，Dev团队
邀请利益相关者来参与和评审
明确验收标准（对于每个用户故事）
增、删、改、查、拆解用户故事
使用相对估算：通过一个benchmark (例如一个轻量级的用户故事)，工作量大概是几倍- 即使用目标故事与基准故事进行对比
估算规模（需要的时间）
原则：基于价值来分析优先级（交付成本、延迟成本、ROI）
Must、Should、Could、Won't- 详见“需求管理”
莫斯科法则
基于客户兴奋点/满意度来排序（客户满意度*客户需求实现度）- 详见“需求管理”
Kano模型
给需求打分，根据得分判断优先级- 罗列需求对应的收获和制约因素- 分析影响范围和大小- 关注：做了带来的收益、风险、问题，不做的损失- 打分综合判断优先级
权重分析模型
排序故事的优先级
可以包括技术相关的讨论
识别风险、依赖和技术架构
多个迭代待办事项列表组成了发布计划（敏捷中的计划）- 敏捷中的计划是以故事为单位的（故事层），体现要发布哪些故事，每个故事在哪个迭代中出现
Initial版本的Sprint Backlog
针对整个项目的燃尽图：横轴是每个Sprint，纵轴工作量是跨迭代的，例如：特性维度- 普通燃尽图的横轴是天：第1、2、3天，纵轴是一个迭代内的剩余工作量
发布燃尽图
条形燃尽图
1. 纵轴：总任务量2. 不同颜色代表不同泳道，不同类型的任务（随着时间的推移，原始任务会不断地分配到不同的泳道中） - 最左侧蓝色泳道: 待完成的任务池；最右侧深紫色泳道：已完成的任务3. WIP：某一天正在进行的任务 Avg. Lead Time: 前置时间，代表完成\"WIP\"这部分任务所需要的时间 Avg. Delivery Rate: 斜率代表完成速率4. 利特尔法则（Little's Law & Cumulative Flow） Delivery Rate = WIP / Lead Time
累计流量图
发布计划完成情况
产出
产品梳理会(待办事项梳理会)
PO与团队一起从产品待办事项列表中选取用户故事
选取用户故事，确定迭代目标
验收标准：具体的指标
完成的定义：必须要完成哪些测试，必须部署到什么样的环境
明确完成的定义-DOD- 做到什么样就是完成了
可行性判断 - 用于任何不确定的地方（风险，技术、商业模式）- 对于高度不确定/从未做过的工作，需要短暂停止项目工作，先探明可行方案，不能贸然开始冲刺
探测/刺探技术（Spike）
选故事 (确认做什么 - 做承诺)
创建迭代待办事项列表
依据之一：团队速率（固定时间内团队完成任务的规模）- 团队速率不是越快越好，而是越稳定越好- 使用相对估算：不能跨团队比较，但是可以跨迭代比较（使用统一的benchmark）
团队拆分和确认任务，给出工作量估算
拆任务（确认怎么做）
制定迭代计划
整个Scrum团队共同完成
主持：Sprint Master
范围(Who)
限时会议。2周的迭代：2小时选择故事，2小时估算分配（每个任务大概花多长时间）
时长
由SM负责完成
这个Sprint的燃尽图
Sprint计划会（Plan）
昨天做了什么
今天准备做什么
存在什么样的困难
目标：回答三个问题
不是为了解决问题，而是暴露问题- 用来做每日承诺，不是讨论会，不是状态更新会，不是汇报会（为了完成Sprint目标）
团队成员自组织，互相承诺- 如果时间紧张，SM可以不参加
整个Scrum团队都必须参加
范围 (Who)
每天开，15分钟
燃起图
每日Sprint站立会（Do - 执行）
检视交付的产品增量
产品验收评审
开发团队通过Demo演示进行 - To PO或客户
产品负责人选择接受或拒绝，决定是否发布产品增量
和外部交互的会议
按需调整产品代办事项列表（Product Backlog）
不需要汇报进度。目的是获取反馈促进合作
保证和利益相关方的步调一致相当于传统项目中的“范围确认”
Scrum团队 + 客户
Sprint临近尾声
可交付的产品软件（产品增量）
业务方根据实际产品增量，可能会提出新的想法和需求
修订后的产品待办事项列表
Sprint评审会 (验收会)（Check - 检查）
相当于传统项目中的审计（针对过程的审计）
回顾总结，识别改进项，在下个Sprint实施
整个Scrum团队（没有客户）-闭门会
技术细节：例如代码review
执行过程中的所有活动：活动有没有意义
回顾范围
制定出next action list
Sprint回顾（复盘）会（Action - 改进）
5种活动5个会议
持续质量改进- 5个会议 + 1个Sprint迭代本身- 5个会议包含PDCA循环的四个会议和一个产品梳理会Sprint工作流程见流程图1-1.Scrum工作流程
用于做很多过去不敢做，不管承诺的事情
勇气
不鼓励一对一交流的形式。信息应及时传递给全团队
开放
短周期内，团队专注于一件事情上
专注
承诺
相信个人都是积极向上的，有职业操守，尊重想法和决定
尊重
5种价值观(团队遵循的核心理念)
Scrum框架（4-3节）
1. 敏捷 = 传统 + 需求理解 + 产品运营2. 金字塔结构（由宏观到微观）：第一层：公司愿景 -> 商业战略第二层 (产品管理)：产品愿景 -> 产品战略 -> 发布计划第三层：迭代计划 -> 每日计划
项目边界（敏捷 vs 传统）
描述对产品的目标，希望达到的效果
总思路
为了（目标客户）他们的（需求和机会）
这个（产品名称）是一个（产品类型）它可以（关键有点和使用理由）
产品简介
而不像（同类竞争者）我们的产品（差异说明）
差异化(对比优势)
张贴在显眼的位置
项目过程中不断声明产品愿景：团队成员实时知道为什么要做这个产品
使用场景
产品愿景(电梯演讲)
收集用户信息
了解用户需求
基本信心
喜欢/不喜欢
对产品的期待
对产品的痛点
用户画像
促进开发人员对用户需求的理解
作为XXX（用户角色）我想要XXX（结果）以便XXX（原因/价值）
示例：作为一个网络购物者，我想要支持小额免密码支付功能以便在我点击支付时能够快速完成订单的支付
正面：用户故事
在（场景或条件）下做了（操作/行动）得到了（结果）
反面：验收标准DoD(用户故事的实现效果)
确定关键用户
描述用户活动
活动分解为史诗
基于史诗编写用户故事
确定产品发布的版本
从用户地图中，拉取优先级较高的用户故事（例如某一个MVP下面的用户故事）
创建
每个迭代都要更新
更新时间点
用户故事不能太大，也不能太小。
Detail.适当的详细适度
用户故事的规模需要估算
Estimate.被估算的
完成顶层的用户故事后，下面的需要完成的用户故事内容自然涌现出来
Emergent.涌现的
用户故事的优先级需要满足排序标准。
Prioritize.排了优先级的
原则：DEEP
产品待办事项列表
产品待办事项列表的产生
用途：收集估算
收集
关键词
SM与团队和PO开会澄清用户故事，会后团队收集并提供个人用户故事估算。采用的是什么方法?A.计划扑克B. 宽带德尔菲法 --> √ (关键词：收集）
例题
宽带德尔菲
故事点相对估算：基于一个benchmark故事点，估算其他用户故事的故事点倍数
数字代表故事点数量1. 0 - 不需要任何工作量2. ？- 需求不理解，无法评估3. 100 - 工作量太大，需要细化
应用
计划扑克
规模大
亲和估算
T恤尺码估算
估算工具(用户故事的规模)
MoSCoW法则
卡诺模型
一个软件开发项目潜在的利益大于风险。在选择每次迭代的内容时，应该优先开发哪些功能?A.高价值和低风险功能C.高价值和高风险功能--> √
优先级 = （商业价值+风险）/成本- 成本：指成本或规模
相对量级
优先级排序工具
定义愿景：项目愿景/产品愿景， 介绍高层级目标
概要的需求，进度计划
使命，为达到敏捷的目标需要做的事
项目成功标准
敏捷项目章程
产品路线图
例题：你正在创建在公司部署一个新的ERP软件的时间表。公司决定选代开发新的ERP。ERP的第一个版本应该在四个月内推出，你知道另一个全公司范围操作系统升级的项目计划在三个月内推出。随着升级项目影响你的进度，你应该评估以下哪一项以确定在推出前的迭代次数?A.敏捷发布规划--> √B.产品路线图--> ×C.迭代待办事项列表
敏捷发布规划
敏捷价值路线图(价值流是什么？)
敏捷的产品管理
未完成工作不会产生任何价值
因此才会有WIP的规定：专注于当前的少量工作
完成工作比开始工作更重要
单团队敏捷实践
i.e. 后接工人完成工作后，发出信号，前序工人再继续工作
避免高在制品（WIP）数量累积的恶性循环
拉动（Pulled）式生产
任务放置在看板上进行跟踪管理
基于流程的思路- Scrum是基于迭代的思路
例如：设计、开发、测试、部署阶段的可视化
看板直观反映出问题/状态，团队成员更容易理解团队的决策
工作流程可视化 -> 决策可视化
目的：更加聚焦（局部优化/瓶颈处优化）
做法：每个泳道限制任务数量
限制在制品(WIP)数量
和Scrum不同，KanBan系统对数据和度量有要求
常用工具：累计流量图，包含WIP数量、Lead time、吞吐率
度量和管理流动
公开透明：清晰展示任务的流动和每个工序的流程规则
显示化流程规则
KanBan没有时间箱概念- 任然要开回顾会、评审会、计划会，但按需召开，不严格规定召开时间
每日展会的形式，从右至左检查看板工作项
建立反馈环路
保证从用户需求到创造用户价值的顺畅流动
在协作及实验中改进（持续改进）
现有团队成员就可以完成
不需要增加额外的角色
特点(核心实践)
总时间：任务卡片从贴上到完成
交付周期
处理时间：处理一个任务所需的时间，不包含开始前的等待时间
周期时间
等待时间：一个任务等待开始的时间
响应时间
衡量指标
交付周期/前置时间LT = 周期时间+响应时间(总交付时间/前置时间LT = 处理时间+等待时间)- 吞吐率 （单位时间完成的任务数） = WIP/前置时间
流动的是任务（从故事拆分下来）
任务板
更加健全的泳道
每个泳道都有限制WIP的数量
定位瓶颈：很容易发现瓶颈在哪个环节- 距离如果任务F开发完成，此时Test里仍然有2个任务，则无法移动，此时无法从ToDo中拿新的任务。此时需要协助Test，使其流动起来
学习成本低：不用知道每个具体任务是什么，只关注整个流动是否健康
KanBan面板
关键词：任务状态，可视化工作流程，任务流动（何时、何地）
KanBan面板 vs 任务版
Step1：梳理工作流程
Step2：画出看板面板&放置工作任务
Step3：设置WIP限制
Step4：定义完成规则
当面移动标签
Step5：召开每日展会
累计流浪图（见“5种活动”-“产品梳理会”），斜率就是吞吐率
Step6：度量和管理流动
看板面板创建流程
KanBan体系
产品构想->商业计划->商业计划书（过于冗长）
背景
进行商业论证
市场渠道（获客通道）
收入来源：营收是从哪里来的
关键指标：如何衡量产品的成功与否？
竞争壁垒：产品护城河是什么？
核心模块（部分）
精益画布
背景：互联网背景下，需求快速变化，无法支持企业花很长时间来开发一个产品
MVP - 最小可行性产品(Minimum Viable Product)
尽早给出一个初始可用版本让客户先用起来，通过一步步迭代优化最终满足客户要求- 例如：客户要求开发一个汽车。那么可以从滑板车->自行车->摩托车->汽车
不断验证用户需求、市场需求
思路
化解项目风险（避免客户对最终做出来的产品不满意）
充分理解客户需求：促使客户不断提供更加有效的反馈和意见，快速迭代，保证最终交付物符合业务需求
始终/及早有产出交付给客户
不一定是一个真实的产品，试验品性质，不包含所有的功能
效率高：用最小代价（最小精力，最小投入）
优点/特点
介绍开发想法：理想的功能有哪些？可以怎样使用？适用场景？
产品介绍视频
仿真
获得宝贵的早期用户，同时验证市场需求
众筹
通过原型图来确认需求
i.e. 课程预售，满XX人报名开班，否则退款
预售
实现途径
MVP
MMR（Minimum Marketable Release）：最小可发布版本
验证真实产品是否满足用户需求（用户是否愿意买单）
真实可用的产品，用户可以真实付钱购买的版本
工具：莫斯科法则 (MoSCoW Laws)
必须要有的功能
MMR
精益画布 MVP&MMR
例题：一家沉浸于瀑布式项目管理中的PMO聘请了你，作为敏捷实践者，来指导组织向敏捷的转变。你意识到许多干系人都抵制变革。最佳行动方案是什么?A.提供培训来确保员工更加专业化C.寻求愿意支持这一事业的高层高管 --> √D.确保工作分解成孤岛
变革就绪：1.管理层的变革意愿2.员工认知的转变3.集中或分散项目管理职能4.专注于短期目标而非长期5.人才管理成熟度和能力
组织内部变革
固定内容（法律、法规等） + 灵活内容
多层结构
一个个故事进行交付
增加增量
管理给定能力：如果要加进来一个故事，必然要踢出去一个故事
固定的时间和材料
允许特定点的更改
允许动态范围
类似激励合同：按时完成给奖励，否则给处罚
若已完成的部分能够满足需求，那么可以取消项目，不用支付剩余费用
支持把供应商团队的人拉到自己团队来
支持全能型的供应商，由一个供应商处理所有工作
支持全方位供应商
敏捷合同管理
SAFe(Scaled-Agile Framework)
每1到3个团队配备1名SM
PO最多可以负责8个团队
LeSS(Large-Scaled Scrum)
SOS(Scrum of Scrum)
丽日
多团队合作
例题：PMO想要结合敏捷的最佳实践。项目经理担心团队不具备在混合环境中工作的能力。最佳行动方案是什么?A.授权团队自我组织和学习敏捷最佳实践B向项目管理办公室(PMO) 申请培训 --> √D审查敏捷最佳实践的经验教训知识库
价值驱动培训发展人才促进组织学习招聘项目领导
敏捷PMO
多团队协作与PMO
审计、财务、CCB、过程文档
仆人式领导促进合作
促进团队合作
敏捷的干系人管理
教育干系人
超越角色，即使失去成员也在所不惜
培训与发展团队
1. 一个组织正在从预测性项目管理过渡到敏捷。作为项目经理，合规报告需要提交给内部审计师。如何在混合环境中满足法规遵循报告的需要?A.与审计师合作来简化过程--> √ （消除组织障碍）B.任命一位团队成员完成合规性报告
2. 你是敏捷项目的经理。一个关键干系人是团队的主要干扰人，频繁地从团队中获取项目状况信息，提供建议、变更需求。对此，你应该做什么?B. 邀请利益相关者参与适当的规划或审查会议，要求他提供自已的观点--> √D. 直接告诉利益相关者在迭代周期中不要打扰团队
3. 敏捷教练一直在通过或超越他们当前的角色来培养和发展团队成员。帮助一些团队成员发展了他们的个人和专业技能，使他们觉得他们已经超越了自己的角色。最终，他们中的一些人离开了团队寻找新的机会。敏捷教练的方法正确吗?B.正确，敏捷领导者应该培养团队成员，即使这意味着失去他们--> √C.不正确，敏捷领导者可能会培养团队成员，但不会超越他们当前的角色
领导(管理型->仆人式)
切换任务时，效率损失20%-40%
3-9人的专职团队
孤岛：职能部门的分组
克服组织孤岛
通才型专家、T型
团队主动领取，估算，分配任务
集中办公、分布式团队
团队工作场所
团队(孤岛式->自组织)
敏捷实践(查遗补漏)
体现当前迭代的进度
燃尽图 = 燃起图
作用：监控项目进度
注：蓝线如果一直在黑线下方，则表示进度计划安排不合理，有造成资源浪费（不饱和）的风险
剩余工作 * 时间
判断工作完成速度，帮助规划下阶段的能力
本次迭代种完成的故事点总和
迭代速度
燃尽图(Burn-down Chart)
详见看板体系
看板(KanBan)
信息发射源- 在不干扰团队的情况下即时实现知识共享- 包含：看板、燃尽图、燃起图、障碍日志
见“5种活动”-“产品梳理会”
发布燃尽图、条形燃尽图、累计流量图
敏捷工具
Sprint内部的需求相对不变，变更尽量安排在后续的Sprint- 如果变更频繁（例如一周一次），那么Sprint可以改为1周
变更
团队阶段划分 & 管理，详见“团队”->“团队规则”
帮助团队>命令团队移除障碍>创建障碍保护团队>干扰团队
管理基于团队而不是任务（敏捷创建的是自组织团队）
服务型领导
例题：你是一个敏捷教练，领导着一个敏捷项目团队，你觉得有一个成员的效率比其他成员低。在这种情况下，你最合适的反馈方法是什么?A.允许项目团队成员在认为有必要时解决问题 √B.在即将到来的迭代回顾中，找出团队成员的低生产率 × - 帮助团队而不是代替团队。因此不是我来找，而应该是我帮助成员一起找C.从下一次迭代开始，为团队成员分配最简单的用户情景× - 错误1：任务不是我们分配的，而是团队成员自己决定承诺的 - 错误2：我们要帮助他，而不是创建阻碍
敏捷团队管理
同意，反对，弃权
大拇指投票法
5：完全有信心... ... 1：不可能实现
五指拳投票法
解决方法：投票
冲突
下一个冲刺当中，应该开始哪些新的做法
新做法
Start
之前做法不合适，不应该做
被禁止做法
Stop
哪些做法需要改进
改进做法
Change
好的做法继续做
优秀做法
Continue
回顾方法（SSCC）
迭代与回顾（每个冲刺）
冲突&迭代与回顾
冲刺周期（Sprint）较短，优先级高的新需求可以很快被满足
小步快跑
任何用户需求和团队创意，都会被及时记录下来并及时评估优先级
高效反馈
定下来2周一个冲刺，那么未来也是以该周期为一个周期
保持节奏
以创造用户价值为目标。以创造用户价值的变更都是欢迎的
价值交付
变更管理遵循的规则（4-29节）
指导需求的优先级管理，基于用户兴奋点、满意度设计
用户满意度
满意度
产品是否有这个功能 或 该功能的完善程度
具备程度
i.e. 手机通话、上网、拍照功能
必备属性（Must have）
i.e. 待机时间长
期望属性（Should have）
i.e. 折叠屏、无线充电
魅力属性（Nice to have）
i.e. 手机电路板层数
无差异属性（Does not matter）
i.e. 预装第三方软件
反向属性（Should not have）
属性(优先级从高到低)
Kano (卡诺)模型
必须做
Must have
迟早得做，但优先级不是最高
Should have
可以做，也可以不做
Could have
无论是否有能力做，都不应该做
Won't have
莫斯科法则(MoSCoW Laws)
例如：某银行客户端软件Must：注册/登录，查询余额，转账汇款Should：收支明细，指纹登录Could：投资理财，个人贷款Won't：手机充值，水电缴费
需求管理
按照箭头所示路径，逐步分解细化带边事项列表
分解和细化产品待办事项列表- 规模*详尽程度
进度管理(4-51节)
每日站会
Sprint计划/评审/回归
版本计划/评审/回归
产品路线图计划/评审/回归
投资组合计划/评审/回归
洋葱圈规划(Onion Plan)
发布规划
尽早拿到反馈，快速迭代
核心目的
减少代码冲突
流程化、规范化代码提交，对整个交付有一定把握
CI（Continuous Integration）
提交代码到代码库
CI server监听代码库的变更
CI server触发自动化构建
CI server触发自动化测试
通知相关方
工作流程
持续集成
Test Driven Development (测试驱动开发)
测试用例通过是开发的一个关键路径- 开发的真正目标是完成测试用例覆盖的内容，而不是完成需求文档
测试行为驱动开发行为- 先写测试用例，再写开发代码
TDD
概念：2个人在空间上、物理上（同一台电脑）同时做一个任务
老带新
为了满足开发团队成员全职能的要求
技能的复制
攻坚
结对编程
代码集体所有权
小型发布
实践
极限编程
根据项目规模和关键性来选择合适的方法
一种方法论家族
水晶
把Scrum的Task放在看板上，监控Task的开展状态（类似任务板）
Scrum到看板的过渡方法
Scrumban
目的是满足大型软件开发项目的特定需求
功能驱动开发-FDD
强调制约因素驱动交付
动态系统开发方法-DSDM
软件项目中，统一过程（UP）的分支。目的在于在7个主要因素之间执行更多的迭代周期，在正式交付前纳入相关反馈
敏捷统一过程-AgileUP
不是一个大型的Scrum团队
每个团队包含3-9人
团队间协调：每个团队代表与其他团队定期召开会议，通常一周2-3次
两个或多个Scrum团队使用的技术
类似每日站会
每日例会
Scrum of Scrums(多团队敏捷实践)
专注于项目组合、项目集、团队层
大规模敏捷框架
SAFe
扩展Scrum方法为共同目标，来组织多个开发团队。
仍然要求多个团队使用同一个产品待办事项列表- 仍保留更多的传统Scrum元素
大规模敏捷开发
LeSS
团队级扩充至整体性组织层面，延展Scrum方法和理念
企业Scrum
整合多种敏捷最佳实践的过程决策框架
规范敏捷-DA
其他敏捷实践
项目经理的顶头上司
管理的是项目储备
高级管理层
包含范围、进度、成本三个部分
项目管理的基准baseline
影响基准的变更只能由CCB来决策（提供书面报告）
只有项目经理和CCB能够决策变更
变更控制委员会（Change Control Board）
各方代表组成的一个小组：甲方、乙方项目经理、外包商
CCB
财务、法务、采购、行政、人事等
职能经理
甲方或内部项目中的老板
出钱的人
发起人
项目经理负责制定粗粒度计划，最细到工作包
执行团队会细化工作包，细到活动：每个活动都需要评估成本（人*天）
项目计划是自上而下分解，再自下而上汇总（成本汇总等）得到
项目团队制定项目计划
Step 1：项目经理拆分项目计划至工作包Step 2：执行团队分解工作包至活动，并评估活动的成本、时间等Step 3：反馈给项目经理，逐级往上汇总得到项目计划
项目干系人
重要角色
事先识别出每一步怎么做
计划
识别出可能遇到的风险做出风险的应对计划指定明确的负责人
风险管理
未雨绸缪
持续实时监控项目
监控
监控过程中出现的偏差进行及时纠正
及时纠正
防微杜渐
项目经理最重要的职责是把专业的事情交给专业的人干，而不是自己
最专业的资源整合在一起
采购管理
资源集成
只做范围内的事情。可做可不做的，原则上不做
达不到和超出都不行。超出可能意味着多花资源和时间，意味着成本可能会超出
达到合同规定的验收标准即可
恰到好处
遵循项目的49个过程
项目变化优先考虑走整体变更控制程序：增加/变更需求，项目突发意外
制度
循规蹈矩
目标不变
锲而不舍
变更 - 变更日志
需求 - 需求登记册
变更后 - 经验教训登记册
组织过程资产
积微成著
参与
公开透明
保证项目过程公开透明
诚信
共赢
同舟共济
即使是发起人，也无权对项目人员安排私自做调整
项目经理的权利：团队成员的工作分配
授权
平等
各司其职
项目管理价值观和方法论
发起人是章程的发布者和责任人
章程->发起人
基准的变更，只能是CCB表决变更
基准->CCB
各个项目的优先级是PMO决定的
优先级->PMO
如果有变更，在执行新计划前，必须通知相关干系人
通知->干系人
高级管理层掌握管理储备
管理储备->高级管理层
变更发起后，下一步一定是评估影响
变更->评估影响
更新项目计划和项目文件
更新->计划/文件
经验教训登记册，问题日志
记录->问题/经验教训
审计过程是否合规。规则存在于管理计划，包括流程和做法
审计->过程合规（管理计划）
监控过程组：寻找和及时发现偏差
偏差->监控过程
固定搭配
考试要点
收藏
0 条评论
回复 删除
下一页
