项目管理PMP
2023-03-15 08:38:39 8 举报AI智能生成
登录查看完整内容
项目管理PMP思维导图，包含预测和敏捷
作者其他创作
大纲/内容
临时：有时间限制
独特：每个项目都有不一样的地方
渐进明细：过程中逐渐清晰
项目
长期持续
内容重复
VS. 运营
项目集：项目相互有影响、有关联
项目组合：项目目标一致，存在优先级
组织级项目管理
VS.
预测型（瀑布型）：需求明确，变化少，计划详细
迭代型：需求逐渐清晰，交付频率低
增量型：需求稳定，多次交付
敏捷型（适应型）：需求不明确、变化多，多次交付
项目生命周期
需求评估：包括业务目标、问题和机会，同时提出处理建议
高层级战略
运营假设条件和制约因素
商业论证（经济可行性分析报告）
概述性文件（与“里程碑”类似）项目是否值得做，考虑成本效益
项目实现效益的方式和时间
应制定的效益衡量机制
内容
VS. 为把握商业机遇制定的方案（即“机会应对方案”应记录在风险登记册中）
目标效益
战略一致性
实现效益的时限
效益责任人
衡量指标
假设
风险
要素
关键词：产品可否投入运营、产品能否产生经济效益/价值
效益管理计划
商业文件
输出：项目章程
项目管理基本要素
员工能力、质量标准均属于事业环境因素
事业环境因素：客观存在，无法改变，项目不可控，有利有弊
项目治理框架：立项标准、评审流程等
组织过程资产：经验教训，可增减，有帮助
影响要素
弱矩阵（偏职能）
平衡矩阵（默认类型）
强矩阵（偏项目）
矩阵型
职能型
项目型
组织结构
支持型
控制型
指令型
项目管理办公室（PMO）
项目运行环境
责任
尊重
公正
诚实
职业道德
过程：技术项目管理
人员：领导力
业务环境：战略和商务管理
PMI人才三角
沟通
管理关系
处理冲突
技能
项目经理：组织委派、领导团队、实现项目目标
职能经理：管理和监督某职能领域或业务部门
项目经理 VS. 职能经理
项目经理角色
圣人
商业论证：是否可做
效益管理计划：何时见效
确保项目章程、项目管理计划与效益管理计划在整个项目周期内始终保持一致
协议
事业环境因素
组织过程资产
输入
某领域，具体问题，专业意见（信息单一）
专家判断
头脑风暴（大胆假设）：创意，“新”点子（不同想法）
亲和图：归类
德尔菲技术：匿名专家，多轮投票，达成共识
名义小组（小心求证）：投票、排序
焦点小组：聚焦一点，讨论，记录
获取有效用户样本，采访样本以收集数据
访谈：一对一（一对多），私密，深入了解
数据收集
三步曲
冲突管理：调和并达成一致
引导：跨职能开会，引导达成一致
会议管理
人际关系与团队技能
与问题第一人讨论最有效
会议
工具与技术
批准项目：明确与组织战略目标之间的联系，确立项目地位，展示组织承诺
授权项目经理：使用组织资源
作用
高层级需求
描述、边界、成果、风险、总体里程碑进度计划
可测量的成功标准（≠验收标准），退出标准
审批要求
财务资源
关键相关方名单
发起人或可以批准项目章程的人员名单及职权
项目经理职权
发起人提供支持（资金&资源）只有发起人才可以推动项目进程
粗略
项目经理与发起机构合作完成
编制
项目发起人/项目启动者
审核
项目章程（≠合同）
假设条件
制约因素（限制信息，例如法规）
假设日志
输出
来自低层级活动和任务
先确认必要性，再制定和提交审批
制定项目章程
项目章程
其他过程的输出
头脑风暴
焦点小组
核对单
访谈
冲突管理
引导
规划阶段的输出
执行阶段的条件和说明
成功保证
范围管理计划
需求管理计划
进度管理计划
成本管理计划
质量管理计划
资源管理计划
沟通管理计划
风险管理计划
采购管理计划
相关方管理计划
子管理计划
范围基准
进度基准
成本基准
变更管理计划
配置管理计划
绩效测量基准
开发方法
管理审查
其他组件
项目经理和团队
制定
重要相关方一致确认
批准
基准变更：实施整体变更控制流程
非基准变更：项目经理确认
修改
项目管理计划
启动结束，规划开始
发布项目章程
任命项目经理
会议目的
项目启动大会（Initiating Meeting）
执行之后，才需要提变更
规划结束，执行开始
传达项目目标
获得团队承诺
阐明相关方角色职责
展示计划如何满足相关方需求和期望
多阶段项目：每个阶段都要举行
跨国项目：分时区安排虚拟会议
项目开工会议（Kick-off Meeting）
改期：关键相关方无法参加（时间尚早）
如期：部分相关方无法参加（临时缺席）→ 会前要承诺，会后发报告
会议是否如期举行
开工会议 VS. 启动大会
制定项目管理计划
任何组件
变更日志
经验教训登记册
里程碑清单
项目沟通记录
项目进度计划
需求跟踪矩阵
风险登记册
风险报告
项目文件
执行已经批准的变更
批准的变更请求
项目管理信息系统PMIS
执行首次输出的可交付成功，但并不是直接交付需要经过控制质量和确认范围，最后验收后交付
可交付成果
工作绩效数据
问题日志
缺陷补救（结果，质量）
纠正措施（过程，绩效）
预防措施（未来绩效）
更新
变更请求
风险应对措施属于预防措施
项目管理计划更新（任何组件）
活动清单
需求文件
相关方登记册
项目文件更新
组织过程资产更新
记录问题
分析原因
制定方案
实施方案
监控执行
问题处理流程
期间持续更新
监控执行过程
指导与管理项目工作
所有组件
项目团队派工单
资源分解结构
供方选择标准
共享数据库
隐形知识→显性知识
知识管理
显性知识→经验教训登记册
信息管理
作用：避免同类事件再发生
随时更新
环境要求：开发信任的环境
经验教训登记册更新
项目管理计划更新
显性知识：图片、文字、文件等具体知识
隐性知识：信念、洞察力、经验等
知识分类
管理项目知识
估算依据
成本预测
质量报告
进度预测
工作绩效信息
选择解决偏差的方案
备选方案分析：两个以上方案
确定最节约成本的纠正措施
成本效益分析（估算备选方案）：比较成本与预期的效益
挣值分析：实际进度和成本绩效与绩效基准比较
发现问题-分析原因-规划措施
根本原因分析：识别问题主要原因或根本原因
确定偏差是否处于临界值
偏差分析：目标绩效与实际绩效之间的差异
判断绩效在改善还是恶化
趋势分析：基于以往绩效，预测后期可能出现的问题
数据分析
决策
工作绩效报告
工作绩效数据：原始测量结果
工作绩效信息：绩效数据与计划比较后得到
工作绩效报告：整合绩效信息并编制报告，用于制定策略
工作绩效数据 VS. 工作绩效信息 VS. 工作绩效报告
与基准比较
分析比较信息
编制报告
先查阅文件，再决定应对措施
问题出现
监控项目工作
监控目的：定期审查项目状态和计划，避免出现缺陷问题
从开始执行到验收结束
任何时间、任何相关方都可以提交书面请求
识别配置项
记录并报告配置状态
进行配置项核实与审计
配置管理活动
外部提变更：先提交项目经理后分析
内部提变更：先分析后由项目经理提交CCB
识别变更
涉及基准：CCB审批
不涉及基准：项目经理审批
记录变更
更新变更日志
通知相关方
实施变更
不批准
做出变更决定
跟踪变更
变更管理活动
变更控制工具
备选方案分析
成本效益分析
投票
独裁型决策制定
多标准决策分析
更新需要更新的文件，而不是更新变更请求
变更审批人员：CCB、发起人、职能经理（职能型公司）
验收之后发现质量问题，一定要走变更流程
实施整体变更控制
质量控制测量结果
批准的产品规范
交货数据
工作绩效文件
验收的可交付成果
商业论证
采购文档
最终产品、服务或成果移交
最终报告
运营和支持文件
项目或阶段收尾文件
经验教训知识库
1、移交成果
2、财务收尾
3、满意度调查
4、更新经验教训登记册
5、组织过程资产更新
6、最终报告
7、文件归档
8、庆功会
9、解散团队
收尾流程
变更截止时间：验收之后，除非质量问题或该做的没做，其他均不再变更
合同收尾（对外）：只针对合同，只进行一次
行政收尾（对内）：每个项目的阶段都要进行
合同收尾 VS. 行政收尾
需要与发起人审查问题，并报告相关部门
非项目内部问题，团队召开审查会议无法解决问题
收尾之后发现高层级问题
阶段结束，发现产品失去价值，需要进行审查，确认是否需要终止项目
阶段关口
产品验收：产品开发工作全部完成的验收
确认范围：可交付成功的验收
产品验收 VS. 确认范围
提前终止：需要调查提前终止的原因
项目搁置：分析当前情况，总结经验教训，进行收尾，遣散资源
需要根据公司项目收尾流程安排具体工作
结束项目或阶段
文件分析
回归分析
趋势分析
偏差分析
项目整合管理
项目生命周期描述
定义范围：制定范围说明书
创建WBS：根据详细的范围说明书创建工作分解结构
控制范围：如何审批维护范围基准
确认范围：如何验收
如何管理范围
如何规划、跟踪和报告各种需求活动
需求优先级排序
测量指标及理由
哪些需求属性被列入跟踪矩阵
需求管理计划（商业分析计划）
如何管理需求
产品范围（WHAT）
项目范围（HOW）
产品范围 VS. 项目范围
更新产品添加成分的标准，属于需求变化
规划范围管理
相关方参与计划
专家判断：某领域，具体问题，专业意见（信息单一）
头脑风暴：畅所欲言（信息多样）
提前设置问题，收集数据有限
问卷调查：受众多，位置分散，快速，大规模信息收集
标杆对照：借鉴，与竞品比较
一致同意
大多数原则
相对多数原则
投票：归类，排序，集体决策
独裁：一人决定，高效
多标准决策分析：多个选项，评分占比
思维导图：共性&差异
数据表现
系统交互图：人与系统
原型法：建模获得对需求的早期反馈
数据建模
摸着石头过河
观察：难以说明或不清晰，通过旁观参与
交谈：沟通
观察和交谈
联合应用设计或开发JAD：软件开发
质量功能展开QFD：制造行业
用户故事：敏捷
业务解决方案：相关方需求
技术解决方案：如何实现需求
分类
Specific：具体的
Measurable：可衡量的
Attainable：可达到的
Relevant：相关的
Time-bound：截止期限
项目要实现的需求才符合SMART原则
需求文件：所有单一需求
验收之后发生的需求变更：需要查看需求文件
前期收集需求：预测型
每个阶段重复收集需求：敏捷型
判断项目类型
作用：避免达不到客户要求
需求跟踪矩阵：产品需求与可交付成果的对应表格
范围说明书：不包含需求，只包含可交付成果
VS. 范围说明书
收集需求
需求文件（选取最终需求）
备选方案分析（需要考虑投入产出比）
产品分解
需求分析
系统分析
系统工程
价值分析
价值工程
产品分析
客户需要的→项目要做的
产品范围描述
验收标准
项目的除外责任（建议作为另一个项目的范围）
项目边界基准
项目范围说明书
需求和可交付成果连在一起验收通过但客户不满意
内容有重叠
详细程度不同
项目范围说明书（渐进明细） VS. 项目章程（粗略）
在哪儿可以找到可交付成果
可交付成果不满足客户需求，拒绝验收
客户对可交付成果的多个功能不满足：需要分阶段验收
定义范围
自上而下（粗略估算）：逐层细化
自下而上（详细估算）：归并低层组件
近期-详细（工作包）
远期-粗略（规划包）
滚动式规划：当前无法分解，达成一致后细化
分解
8-80原则（1天-2周）
100%原则（分解要完整）
细分项目范围
全部工作范围层级分解
没有WBS，容易出现范围蔓延
WBS：边界清单
WBS词典：展开明细
子项目
里程碑
控制账户：项目经理管理，用于测量绩效
规划包：内容已知，进度未知
工作包
活动
任务
项目逐级细化架构
WBS不包含具体活动
创建WBS
验收可交付成功的参考文件
控制质量的输出
满足质量要求
用于验收
核实的可交付成果
可交付成果是否符合验收标准
检查
客户或发起人签字确认的成果
未通过验收的可交付成果，需要提出变更
需求-工作-产品
控制质量
确认范围
确认范围 VS. 控制质量
可以同时开始和存在：控制质量一般更早
客户提出新需求
执行中的范围蔓延
验收未达到预期
变更流程：了解-分析-提申请
在整个项目期间，保持对范围基准的维护
镀金：团队内部自行添加内容
范围蔓延：团队外部要求添加内容
范围蔓延
同意变更：补走流程
不同意变更：删除相关内容
没有走变更流程
关键字：新功能、遗漏功能、遗漏需求等
需求多、无法全部实现、无多余预算：需要相关方确认最终范围
控制范围
项目范围管理
确定进度模型
项目进度模型维护
准确度
计量单位
组织程序链接
进度计划的发布和迭代长度
绩效测量规则
控制临界值
报告格式
建立准则，明确活动
进度管理计划：如何管理进度
进度计划：详细进度模型
进度管理计划 VS. 进度计划
规划进度管理
滚动式规划
活动标识
工作范围详述
活动清单：进度活动
清单排序
多重属性
活动之间的关系
活动属性
重要时点和事件
持续时间为0
里程碑：关键节点
关口：区域内判断是否可继续
里程碑 VS. 关口
可交付成果→具体行动
定义活动
SF开始到结束
SS开始到开始
FS结束到开始
FF结束到结束
紧前关系绘图法PDM
如何按照正确的顺序执行任务
强制性依赖关系：客观限制存在
选择性依赖关系：可选择的
外部依赖关系：项目团队不可控（技术依赖）
内部依赖关系：项目团队可控（组织依赖）
确定和整合依赖关系
提前量：紧后活动提前开始时间量（紧前活动未结束）
滞后量：紧后活动延后开始时间量（紧前活动已结束）
提前量和滞后量
项目信息管理系统PMIS
路径汇聚：多个紧前活动
路径分支：多个紧后活动
综合分析活动逻辑依赖关系
路径的活动越多，风险越大
项目进度网络图
排列活动顺序
项目范围管理计划
资源日历：人员排班表
资源需求
先估算资源，再估算时间
专家判断：凭借经验
类比估算：类似项目（总量）
参数估算：历史数据，参数模型
三角分布
贝塔分布
三点估算：不确定性和风险
最乐观、最悲观、最可能
自下而上估算：WBS（耗时长、准确、详细）
应急储备：已知-未知
管理储备：未知-未知
储备分析
需要走变更
持续时间估算
工作范围
资源数量
资源类型
资源日历
收益递减规律
技术进步
员工激励
考虑因素
估算活动持续时间
分析活动之间依赖关系
进度网络分析（总体分析）
进度网络图
关键路径计算：最长路径
总浮动时间：耽误多久不影响总进度
自由浮动时间：耽误多久不影响紧后工作
关键路径法：紧前紧后
最晚开始-最早开始
最晚结束-最早结束
计算
资源平衡：改变关键路径
资源平滑：不影响关键路径
资源优化
资源负荷
非关键路径
假设情景分析
模拟：蒙特卡洛
建模
提前量与滞后量
赶工（增加资源）：有预算，风险小
快速跟进（任务并行）：返工风险大（后期成本可能增加）
进度压缩
没提预算有限，选赶工
项目信息管理系统
敏捷发布规划
进度数据
项目日历
里程碑进度计划
横道图（甘特图）
概括性进度计划
详细进度计划
进度模型
规划阶段，可以按要求调整进度计划
进度基准不变，进度有延迟的时候，浮动时间是负数
制定进度计划
监督项目进度，维护进度基准
人员因素
工具设备因素
方法技术因素
资金因素
环境因素
分析偏差原因
关键路径：通过储备分析，判断应急储备是否充足
非关键路径：耽误的时间小于总浮动时间，不影响进度
通过责任分配矩阵，分析资源是否在关键路径上
造成偏差的是否为关键活动
偏差是否大于总浮动时间
偏差是否大于自由浮动时间
分析偏差影响
赶工
快速跟进
追赶进度需要考虑进度储备，与项目类型无关
分步骤提交
调整进度计划
控制进度的做法
评估不同活动、不同时间表的依赖关系
确定关键路径
预估项目总完成时间
审查并持续监控进度计划
进度分析
确保任务按计划进行
控制进度
挣值分析
迭代燃尽图
绩效审查
关键路径法
项目管理信息系统
项目进度管理
计量单位
精确度
组织程度链接
其他细节
固定成本
变动成本
直接成本
间接成本
沉没成本：以往发生，无法挽回
机会成本：放弃另一样的最大价值
边际成本：每个单位的成本增量（与运营相关）
成本类型
是否随产量变化
是否项目专用
价值相关
规划成本管理
类比估算
参数估算
三点估算
自下而上估算
成本估算
用于新项目
粗量级估算（初步估算）：-25%~75%
确定性估算（基于WBS）：-5%~10%
估算等级
质量成本
完成项目工作可能需要的成本（项目主体）
应急储备
管理储备
估算成本
成本汇总
历史信息审核
资金限制平衡
融资
不包含管理储备
按时间段分配、增量投入
项目资金需求
制定预算
计划价值PV
挣值EV：已完成工作的预算价值
实际成本AC
进度偏差SV
成本偏差CV
进度绩效指数SPI
用来测量已完成工作的成本效率
成本绩效指数CPI
分析当前：计算-判断状态-确定如何改进
完工尚需估算ETC
完工预算BAC
实际成本AC+（完工预算BAC-挣值EV）
完工预算BAC/成本绩效指数CPI
完工估算EAC
按照基本概念，预测未来
完工尚需绩效指数TCPI
把成本与范围进行对应，以监控项目整体状态
控制成本的做法
需要寻找代替指标，作为汇报前期进度绩效
无需进行成本分配
不产生成本的部分如何处理
即成本偏差为0
符合预算
控制成本
项目成本管理
客观存在，必须遵守
可裁剪，被未来有帮助
标杆对照：借鉴
预防成本
评估成本
一致性成本
质检过程中的报废属于一致性成本
内部失败成本
外部失败成本
不一致成本
返工属于非一致性成本
质量成本COQ
流程图：步骤顺序
逻辑数据模型
矩阵图：标识关系强弱
思维导图
测试与检查的规划
质量管理计划（定方法）
质量测量标准（定标准）
质量：成果满足程度
等级：用途相同但特性不同
管理质量：过程改进
质量保证：结果合格
预防：保证过程不出错
检查：保证错误不落在客户手中
精确：结果聚合（聚合）
准确：测量值接近实际值（分散）
属性抽样：一致性的结果
变量抽样：一致性的程度
质量管理内涵
质量低是问题，等级低不是问题
全面质量管理（全员、全过程、全方位）：强调全员参与和遵循质量保证
质量保证需要同时满足
是否合格
具体数值（合格程度）
零缺陷，预防胜于检查
关注质量文化
规划设计
纠正过程
给客户前检查
让客户发现缺陷
五种质量管理水平的有效性
项目管理
项目可交付成果
规划质量管理
质量测量指标
核对单：防止漏项，需要检查打勾
过程分析
亲和图
因果图（鱼骨图、石川图）：分解问题原因
帕累托图：少数原因造成多数错误（排序）
质量分布图：展示缺陷数量
直方图
散点图：一对一或一对多变量之间的关系
针对过程，避免返工
审计
面向X的设计
更新问题日志
问题解决
定义问题-识别根本原因-生成解决方案-选择最佳方案-执行解决方案-验证方案有效性
质量改进方法
测试与评估文件
质量审计不合规，需要对照质量管理计划找原因不一定是计划本身的问题
管理质量
与计划比较，看结果找偏差，发现问题
审查质量管理计划是否存在问题
更新有问题的部分，减少变更的增加
质量问题导致返工，继续导致新的质量问题（变更）
核查表：收集数据（计数表）
统计抽样
问卷调查
根本原因分析
针对结果
某环节有没有问题，用于软件行业
测试/产品评估
因果图
确定过程是否稳定
连续7个点在平均线同侧
有一个点超出控制界限
失控
不代表不合格
控制图
散点图
项目质量管理
工作分解结构WBS（事）
组织分解结构OBS（岗）
资源分解结构RBS（人）
层级性：高层级角色
执行
负责
知情
咨询
RACI矩阵
矩阵型（责任分配矩阵RAM）：记录详细职责，权责分明
文本型：详细描述团队成员职责
需求层次理论
XY理论
双因素理论
期望理论
成就动机理论
五种激励理论
组织理论
角色与职责（角色-职权-职责-能力）
团队管理计划
实物资源管理计划
识别潜在团队
团队价值观
团队共识
工作指南
团队章程
人力资源&非人力资源
目的：确保全体成员理解自身角色和职责
根据成员技能分配工作，选择“资源分解结构”
团队由内外部人员构成，选择“RACI”
团队内部出现问题，先沟通再决策
项目需要明确责任归属（包括客户）
项目组织图：团队内部成员及其报告关系
规划资源管理
自上而下估算
项目日历：项目哪天有活动
资源日历：谁哪天可用
估算活动资源
职能经理（协商）
其他项目团队
外部组织或供应商：确认内部无资源再采购
谈判
愿景层面达成一致
竞标过程中的承诺
项目要求
完成资源管理计划之前已经指定
预分派（事先确定资源）
优点：能使用更多技术成熟资源、降低成本
缺点：沟通、时差、监控难
解决在不同地点工作的沟通问题
虚拟团队
记录非人力资源的资源信息
物质资源分配单
记录团队成员的角色和职责
资源何时可用、可用多久
事业环境因素更新
资源被项目集经理调走，已超出项目经理权限，需要上报发起人解决
获取资源
优点：高效沟通、便于管理
缺点：可能增加成本
集中办公
共享门户、音频/视频会议、电子邮件/聊天软件
沟通技术
任务分解-进度跟踪
看板平台-文档管理
集成办公工具
视而不见
撤退/回避
推迟、转移、等待
求同存异
缓和/包容
强调一致，不强调差异
利用职权
强制/命令
立即决策
各让一步
妥协/调节
考虑双方建议，让双方在一定程度上接受
意气相投
合作/解决问题
长期、有效
影响力
生理需求
安全需求
社会需求
尊重需求
自我实现需求
马斯洛需求层次理论
低层次需求
高层次需求
保健因素：做好无益，做坏有害
激励因素：做好有益，做坏无害
赫兹伯格的双因素理论
X理论：人性本懒
Y理论：人性本勤
麦克雷戈的X理论和Y理论
蓝领
白领
成就需要
亲和需要
权力需要
麦克利兰的成就动机理论
不同需要下，给予的激励不同
激励力量 = 期望值（期望概率）X 效价（目标价值）
弗洛姆的期望理论
激励
团队建设（非正式沟通）：提升团队士气，促进协作
认可与奖励
能力不足，项目经理负责培训
培训
提高团队成员能力的全部活动
个人和团队评估
项目经理有责任关心绩效不足的成员帮助其分析问题并完成成长
团队绩效评价
刚认识，比较独立，需要明确团队成员角色和职责
形成阶段
指导式
如果态度不能合作和开放，可能产生冲突
震荡阶段
教练式
尝试解决问题，协同工作，学习互信
规范阶段
参与式
有序运作，高效工作，互相依赖
成熟阶段
授权式
完成工作，离开项目
解散阶段
结束
团队建设五阶段
跳过、停滞、退回
时间紧、任务重：边学边做
多个资源参加陌生活动需要培训
只有一名资源具备特殊技能，可以选择结对
一开始就确定如何监控项目进度和沟通进度
验证团队成员是否在多个团队中，以及能否为本团队投入足够时间
新团队
需要PMO沟通解决
团队成员被安排到其他项目
前进、停滞、退回、跳过
建设团队
制定决策
情商
领导力
内部分享成功、被鼓励、获得他人认可
鼓励团队新成员
士气低迷：以往经验或反馈HR协助
没有动力：激发斗志，开发情商
性格内向：提前做准备
个人问题
需要项目经理进行正确引导
子团队：先让子团队领导及子团队内部解决
会议期间：重申规则
语言障碍：需要其他资源辅助解决
冲突
与直接负责人沟通问题原因
团队绩效
促进团队协作，整合团队工作，创建高效团队
管理团队
关注实物资源
控制资源
项目资源管理
相关方登记册和相关方参与计划中的相关信息及沟通需求
CC=N*(N-1)/2
潜在沟通渠道或途径数量
组织结构图
组织与相关方职责、关系及相互依赖，开发方法
项目涉及学科、部门、专业，有多少人在什么地点参与项目
内部/外部信息需要
法律要求
沟通需求分析
信息需求的紧迫性
技术的可用性
易用性
项目环境
信息的敏感性和保密性
发送方（编码）→ 接收方（解码）
确认已收到
接收方（编码）→ 发送方（解码）
反馈/响应
沟通模型
信息交换（双向共识）
交互式沟通
需要接收方被动接受（1推多）
推式沟通
需要接收方主动获取（多找1）
拉式沟通
沟通方法
沟通风格评估
政治意识
文化意识
相关方参与度评估矩阵
5W1H：让正确的信息在正确的时间通过正确的方式传递给正确的人达到正确的效果
正式 VS. 非正式
书面 VS. 口头
内部 VS. 外部
官方 VS. 非官方
向上、向下、横向
层级
相关方沟通需求内容和方式都不一样
远程沟通：先分析需求，再制定沟通计划
相关方与信息不关联：沟通管理计划
未识别相关方：相关方参与计划
沟通管理计划 VS. 相关方参与计划
规划沟通管理
沟通问题与第一人直接沟通
不同国家的相关方，沟通源于文化差异
促成团队与相关方之间的有效信息传递
管理沟通
沟通胜任力
反馈
非言语
演示
沟通技能
针对每种相关方来调整项目信息发布的层次、形式和细节
项目报告
积极倾听
人际交往
观察/交谈
优化沟通流程
实施整体变更控制流程
更新沟通管理计划的目的
注意区分
由于沟通产生的意见不一致，先审查沟通管理计划
监督沟通
项目沟通管理
高层级的项目描述和边界
高层级的需求和风险
相关方分析
风险管理战略
方法论
角色与职责
资金
时间安排（时间和频率）
正面风险：机会（影响待提高）
负面风险：威胁（影响待降低）
风险敞口（影响不大）
残余风险：应对之后留下来的（同一个风险）
次生风险：应对之后新产生的（产生新风险）
风险类别
风险管理目标：提高正面，减低负面
风险追逐型：喜欢冒险
风险中立型：无偏好
风险厌恶型：保守，回避
相关方风险偏好
影响（时间、质量、成本）：X轴
概率：Y轴
风险概率和影响定义
客观进行定性分析的参照
风险的影响
排列单个风险相对优先级
概率和影响矩阵
修订的相关方承受力
跟踪
风险管理计划（如何实施风险管理活动）
风险分解结构RBS（对单个风险分类）
风险：未来可能发生
问题：现在已经发生
风险 VS. 问题
规划风险管理
记录已识别单个风险的详细信息
整体项目风险的信息
已识别单个风险的概述信息
整体风险的报告，渐进式工作
单个及整体风险来源和特征
参考以前项目文档
对相关人员进行访谈
相似项目
识别风险
收紧假设条件：识别威胁
放宽制约因素：创造机会
假设条件与制约因素分析
对项目的优势、劣势、机会、威胁进行逐个检查，拓宽识别风险的范围
SWOT分析
战略层面
TECOP（技术、环境、商业、运营、政治）
PESTLE（政治、经济、社会、技术、法律、环境）
VUCA（易变性、不确定性、复杂性、模糊性）
提示清单
风险分解结构RBS
可能引发单个风险及可作为整体风险来源的风险类别的预设清单
风险数据质量评估
风险概率和影响评估
其他风险参数评估
评价关于单个风险的数据准确性和可靠性开展定性风险分析的基础
风险分类
气泡图（三维）
层级型
实施定性风险分析
不确定性表现方式
模拟
敏感性分析
决策树分析
影响图
蒙特卡洛分析（真实概率）：单个风险和其他不确定性
龙卷风图：最大潜在影响（按影响大小排序）
预期货币价值EMV（最优路径）：概率x利润（选绝对值最大的）
实施定量风险分析
不在范围内或超出项目经理权限
上报
转移给第三方
转移
组织无法应对风险：需要转移给第三方
改变计划，完全消除威胁
规避
降低概率或影响
减轻
减少进度延后的威胁=减轻风险：使用更多资源或设置安全时间
被动或主动接受
接受
威胁应对策略
分配给第三方
分享
确保机会实现，分配最有能力资源
开拓
提高机会发生的概率，提升积极影响
提高
乐意利用但不主动追求
机会应对策略
事先制定的应对计划
应急计划
备用的应对计划
弹回计划
未识别风险，临时措施
权变措施
只针对威胁，使用管理储备
应急应对策略
可针对威胁或机会
整体项目风险应对策略
机会（事业环境因素）：上报高层，再行动
风险研讨会：仅讨论如何应对风险，不涉及高层级的事项
无法通过具体措施应对风险，还可以建立应急储备“接受”风险
规划风险应对
识别到的：查阅风险登记册
未识别到的：查阅风险管理计划（识别、分析、规划应对）
风险发生
执行既定的风险应对措施
新技术属于积极风险
实施风险应对措施，不需要审批
风险涉及多个项目，需要上报高层，再进行处理
实施风险应对
技术绩效分析
估算应急储备，用以避免进度延误
了解储备情况
评估风险管理有效性
项目经理负责确保审计的有效执行
风险审计
已过时风险需要关闭
不断对风险进行再识别、再分析、再评估是否出现新风险，假设条件是否仍然成立
机会风险来临：无需分析原因，直接采取措施（如需动用储备，先进行储备分析）
已知未知风险：使用应急储备，并不涉及基准调整
未知未知风险：进行变更流程，使用管理储备
监督风险
项目风险管理
预先批准的卖方清单
正式的采购政策、程序和指南
采购管理计划（采购过程中开展的各种活动）
最常用，需求固定
固定总价
超过上限，卖方承担
低于下限，给予奖励
总价加激励费用（价格设置上下限）
履约周期长，基于通货膨胀等
总价加经济价格调整
总价合同
对甲方好，风险在乙方
成本加固定费用（乙方最有可能通过节约成本增加收益）
成本加激励费用（乙方也要承担一些风险）
成本加奖励费用
成本补偿合同（需求不确定首选成本合同）
酬金固定，对乙方好，风险在甲方
范围不清晰时使用
工料合同T&M（工时+材料）
风险双方承担
合同支付类型
判断范围是否明确
判断工种是否清晰
合同类型的选择
采购策略
招标文件
规格
所需数量
质量水平
绩效数据
履约时间
采购工作说明书SOW（拟采购的产品、服务或成果）
供方选择标准（已有招标文件，仍无法确定供方，需要参考供方提供标准）
自制或外购决策（比较成本，确定是否需要外包）
独立成本估算（确保知道市场范围内的价格，以此和卖方的价格做对照）
工作大纲TOR用于“服务”采购
技术
义务
规划采购管理
市场调研
自制或外购分析
供方选择分析
卖方建议书
选定的卖方
签合同之前，双方需要对合同结构、各方权利义务及其他条款进行澄清，并达成一致
对合同双方具有约束力，项目中涉及的所有不一致，优先参考合同
协议（合同）
分支主题
实施采购
信息邀请书：采购服务或货物的更多信息
报价邀请书：满足买方需要的成本信息
建议邀请书：出现问题并确定解决方案
发布招标文件
广告
卖方提交建议书之前，对所有潜在卖方开会解答
时间
确保投标人对招标文件的理解一致且清晰
投标人会议
卖方建议书（投标文件）：需要给予采购政策编制并提交的文件
建议书评价：以供方选择标准为基础，选择建议书并筛选
谈判-替代争议解决办法-仲裁-诉讼
索赔管理
审查合同工作的绩效
对可交付成果的简单审查、对工作本身进行实地审查
对采购过程的结构化审查
结束的采购
供应商延迟交付，并不能确定是否对项目有影响，首先需要执行风险分析
采购文档更新
与合同要求不符
投标同意过可交付成果，说明采购说明书上有此时，可以提交变更合同请求
超出合同范围
关闭采购：已交付全部可交付成果，没有未决索赔，全部最终款项已经付清
控制采购
项目采购管理
问卷调查：大规模信息收集
姓名、角色、利益、影响力、态度
令其满意：利益低、权利高
重点管理：利益高、权利高
随时告知：利益高、权利低
监督管理：利益低、权利低
权力利益方格
对接人
工作人员
高管
直接领导
权力影响方格
影响作用方格
权力&紧急程度&合法性（7个分区）
凸显模型
向上、向下、向外、横向
影响方向
相关方映射分析/表现
小型项目，关系简单
大型项目，关系复杂
利益&作用
参与度
相互依懒性
对项目潜在影响
识别
记录
分析
流程
相关方登记册不完善→出现大量需求
除了更新文件，还要把信息传递出去（及时沟通）
相关方需求变更
最高优先级的相关方，是可以影响实现项目目标的人
避免相关方未提供信息，不支持项目，需要事先识别并记录相关方信息
相关方登记册：相关方什么样
相关方参与计划：怎么管理相关方
相关方登记册 VS. 相关方参与计划
识别相关方
标杆对照：将实际或计划的产品、过程和实践，与其他可比组织的实践进行比较，以便识别最佳实践，形成改进意见
优先级排序/分级
用于表现相关方及其之间的关系
抵制型
不了解型
中立型
支持型：支持项目工作和成果
领导型：积极参与，确保项目成果
五种类型
同级
当前状态与期望状态
未识别到相关方：更新登记册和评估矩阵
用于表现目前参与情况与期望参与程度进行比较
提供与相关方进行有效互动的可行计划
相关方无法参与，先参考计划再决定如何行动
引导相关方参与
相关方未被管理：需要先更新参与计划再按照计划执行管理
相关方变化频繁，保持沟通并按计划管理
规划相关方参与
基本规则
与相关方沟通和写作，以满足其需求与期望、处理问题，并促进相关方合理参与
概念
让项目经理能够提高相关方的支持，并尽可能降低相关方的抵制
制定参与度评估矩阵确定参与程度
全部相关方纳入参与计划
执行评估以符合项目目标
相关方适当参与措施
先了解项目对相关方的好处，再面对面沟通，说服相关方支持
相关方反对
会议出席名单的重要原因：后期审查会议纪要的证据
会议混乱：提前发布会议议程
相关方会议
提供情商培训、提高技能、保证信息共享
团队与相关方关系紧张、沟通困难
需要保持沟通
相关方人多，团队在不同地区
项目决定不是需要所有相关方都参与
应该由供应商自己解决
供应商自身问题
管理相关方参与
监督项目相关方关系，并通过修订参与策略和计划，来引导相关方合理参与项目
监督相关方参与
项目相关方管理
预测：需求技术相对稳定
敏捷：需求技术相对不稳定
斯泰西图
分析-设计-构建-测试-交付
预测型（瀑布型）
需求以增量的形式存在，产品以增量的形式交付，不断循环PDCA流程
增量型
分析-分析设计（原型）-构建测试（改善）-交付
迭代型
完善工作，频繁交付
敏捷型（适应型）
生命周期的类型
敏捷方法迁移：一个阶段完成后（回顾结束）确认付款
不同组织或相关方提要求，需要根据项目实际情况做决定不能直接遵循某一方观点
转型期间合规问题：先与合规部门确认，再进入具体工作
帮助相关方理解敏捷：展示以往成功的敏捷项目
长期研究、规模大且复杂的项目，适用于敏捷
多阶段项目不适用于快速变化的市场环境
混合：预测+敏捷
可能是不同的团队实施
例如：开发某种高科技产品，然后面向大量用户推出并培训
先敏捷后预测
短迭代
每日站会
回顾
团队逐渐向敏捷过度
前期评估
工作分配
进度跟踪
其他方面遵循预测
预测和敏捷结合
处理不确定性、复杂性或范围蔓延机会项目的部分
敏捷
管理项目其余部分
预测
预测为主敏捷为辅
例如：小规模安装测试，以确定安装方法，在足够时间里解决问题，并尽早发现问题，通过测试调整，增量改进
某个特定要素不可协商，或敏捷方法不可行，使用此方法
例如：集成不同供应商的外部组件，这些组件不能或不会以协作或增量方式合作。在组件交付之后，需要单独集成
敏捷为主预测为辅
改进学习，加强团队与相关方一致性
增加迭代技术
加快对发起人的价值和投资回报
增加增量技术
计划渐进
组织越大，活动部件越多，需要的时间越长
转换时间长
先尝试：风险不大、中低程度不确定性的项目
成功后再尝试：更复杂的项目
先从简单的项目进行实践
过渡策略
根据组织情况、特定风险、团队适应并接受变革的就绪情况，调整渐进混合过度
依据项目因素进行裁剪
裁剪
混合生命周期
混合项目变更流程：CCB和产品负责人均有权审批变更
范围确定，进度成本不确定
传统项目
范围不确定，进度成本确定
敏捷铁三角
价值目标：提供可交付产品
质量目标：提供可靠、适应性强的可交付产品
敏捷三角形
约束目标：在可接受的约束内，实现价值和质量目标
敏捷价值及生命周期
长时间的质量管理活动：可能影响团队专注，需要清除障碍不能直接拒绝，也不能置之不理
团队绩效下降：需要给予合理指导，找到问题所在
敏捷教练作用：培养和发展团队成员（不可以只培养岗位能力）
敏捷培训：需要敏捷教练亲力亲为（某成员不了解敏捷工具方法，直接指导他）
扫除“合规性要求不适用于项目”的障碍：先找出哪些适合项目，再确定需要什么资源
无法形成完整故事：需要相关方澄清，团队自行决策（敏捷教练不能替团队做决定）
敏捷教练
自我管理，同时帮助其他成员解决问题
不是所有想法，都适合公开讨论
遇到问题，敏捷教练提供建议，团队先自行调整
没有凝聚力：为同一个目标，一起工作，互相协作
持续改进是对工作本身的建议，不属于团队意识问题
工作方式自组织
设定挑战性目标
达到最高绩效的标准
“高绩效”与“认可”无关
开发团队
面对面解决最直接
PO与关键相关方意见冲突：已超出权限的，上报最合适
增加决策权：可以解决无权决策，无法解决冲突
高层之间对项目状态有冲突：把燃尽图发给高层，展现本次迭代工作总量和剩余量
个别相关方不满意可交付成果：在验收时，及时沟通获得反馈
本次迭代冲突问题，下次迭代避免
开会可能是后续步骤
单独开会有些滞后
验收标准：PO负责定义
预测项目出色，迭代项目混乱：说明对敏捷不了解
持续反馈，才能保证信息交互
定期检查评审，才能确认当前，判断后续
频繁沟通
从PO获得反馈，不足以达到目的
面对面最好
地域问题：使用视频会议最佳
开放透明沟通
敏捷相关方
结对编程：时间翻倍之后平摊在两个人身上
刺探
敏捷风险
制约因素驱动交付：一开始就设置成本、质量、时间
动态系统开发
考虑风险
敏捷合同三角形：进度成本固定，范围工作量固定，功能可调整
敏捷合同
最好降最低，至少双方共担风险
拥抱变化≠毫无限制
自组织团队（被授权）
免于打扰的环境
通才型专家
适合的人运用，才能产生价值
帮助团队解决问题，提高能力
不能面对面的时候使用，但无法替代对话
过程和工具
个人以及互动高于流程和工具以人为本
解决信息孤岛
工作的产品是最终量化结果
不建议花太多时间在细节上
需求变化快，静态文档不适合
鼓励交互、反馈
可用的软件高于完成的文档以结果为导向
不使用谈判
专注商业决策
与开发团队形成伙伴关系
定义价值
客户
客户合作高于合同谈判合作共赢
唯一不变的就是变化
共同理解，更易响应变化
着重探索
低成本迭代，快速试错
应对变更高于遵循计划拥抱变化
敏捷宣言
“高于”是优先，并没有否定老的行为
最大的好处：能够聚焦价值，解放行为
团队内外保持一致：保持合作，遵循敏捷原则
过于详细的计划：不符合敏捷原则，应该及时修改
张贴计划：即计划被认同
开发人员与客户意见不同：需要互相协作
尽早
持续
有价值的软件
满足客户
原则1：最高目标
原则3：经常交付，越短越好
经常检查，加入已明确的改进
遇到问题，分析原因
在产品待办中，添加有关改进质量的工作
确保质量达标的具体工作
价值与质量没有直接关系
原则8：可持续开发，步调稳定
产品缺陷：没通过测试就是不成功
原则7：可用的软件，关注结果
原型作用：全面收集客户反馈
MVP作用：实现早期交付
原型 VS. 最小可行产品（MVP）
PO：帮助团队理解客户（利益相关方）需求，从而帮助团队实现价值
原则2：欢迎变更，利用变更帮助客户
价值原则
发布即将开始：先交付，再分析新需求
原则4：业务开发一起工作
原则5：给予环境和支持，激励并相信团队
原则6：面对面沟通
原则11：自组织团队
团队原则
项目涉及不熟悉的领域：需要进行讨论沟通
适合敏捷：能够在一起工作
VS. 渗透式沟通：无意识交流，信息无意识共享
信息项目≠适合敏捷
主观意识下的面对面沟通：需要集中办公
全面培训：有助于新员工尽快适应整个项目
团队整体问题：需要敏捷教练协助解决
回顾会议：改善不足，寻找提高团队工作效率的方式
敏捷教练：为他人铺路，不分配任务
确保项目成功交付：大家都参与
交叉与集成领域：Scrum of Scrums
建议“集中办公”，不是必须的
遇到问题：先分析原因，避免下次再出现
一起工作只能满足面对面交流的条件，参与与否不确定
频繁持续整合：无法保证“集成”不出现问题
原则9：精益求精，不断完善
原则10：简洁，减少不必要的工作
原则12：定期反思，回顾、调整
工作原则
敏捷十二原则
敏捷是开放的方式不应该设定在一个限制里
敏捷宣言及十二原则
投资回报
商业论证框架
产品目标、卖点、客户群、产品需求
产品愿景盒
产品愿景及项目成功标准（达到哪些条件意味着项目完成）
需要一个项目，首先制定“项目章程”
对产品定位、目标客户、关键收益、竞争优势的简短说明
电梯测试
团队行为准则和价值观（由团队决策）
构想
敏捷计划：拥抱变化
确定方向，同时期待变化
版本计划：基于功能
迭代计划：基于技术
时间盒：固定时间段
史诗故事→主题故事→用户故事→故事细节（任务）
最小可行产品（MVP）：为客户提供的最小价值产品
最小可售功能（MMF）：为客户提供的价值足够小且足够完整的功能包
故事地图
骨干需求（必须做的）
行走骨架（很重要的）
更少选择
额外特性
更多选择
1.0版
2.0版
3.0版
谁：作为（一个角色）
想要：做什么（潜在需求）
以便于：达到什么目的（商业价值）
用户故事描述
卡片正面
Given（在什么样的情境或条件下）
When（做了什么操作，采取了什么行动）
Then（得到了什么结果）
DOD（已完成的定义：验收标准）
通过制定DOD，提高代码质量测试未必可以解决代码质量问题
卡片背面
用户故事
用于表达完成一个产品待办项或其他任何某项工作所需的所有工作量的估算结果
比较用户故事的规模、复杂程度、不确定性
专家匿名提交估算结果，多轮提交，直到达成共识
宽带德尔菲
参与者同时展示自己的卡片，团队一起讨论估计值，异常值（最低值和最高值）着重讨论
计划扑克
估计构建各个工作项所需的实际时间，不考虑速度或中断
理想时间
快速估算大规模需求未完项（衬衫、咖啡杯、斐波那契数列）
亲和估算
估算方法
故事点
价值（投资回报率）决定优先级
Must：必须做的
Should：应该做的
Could：可以做的
Would not：不要做的
MoSCoW法则
产品性能与用户满意的关系（实现与满意）
卡诺分析（KANO模型）
优先级分类
最高风险放最上
高价值高风险 — 高价值低风险 — 低价值低风险（尽量避免：低价值高风险）
风险四象限
已排序风险列表+需求价值排序=风险调整待办事项
正面影响：具有该功能，带来的收益
负面影响：缺乏该功能，带来的损失
相对权重
优先级排序
优先级
其他因素：主题、风险（反价值）、依赖关系、政治
架构刺探：用来证明一个特定架构方案是否可行
基于风险的刺探：研究某个问题而进行的快速的概念验证活动
刺探/探针（Spike）：b style=\
用于消除项目风险
功能
Card：卡片
Conversation：对话
Confirmation：确认
3C原则
独立的（Independent）：低耦合
可协商的（Negotiable）：可改动
有价值的（Valuable）
可估计的（Estimate）：工作量可算
小的（Small）：一天一变
可测试的（Testable）：关于质量
INVEST原则
难用：进行可用性测试观察用户与软件的交互
迭代计划关键组件
推测
产品愿景
产品有几个版本
产品路线图（1年）
高层级行动计划（粗略）
每个版本有几个迭代
敏捷发布计划（6个月）
可以根据项目实际情况进行调整
具体到产品特性
每个迭代有几个功能（用户故事）
迭代计划（2-4周）
不轻易改动
每日计划
产品需求规划（敏捷洋葱圈）
敏捷发布规划（洋葱头）
产品高层级目标
取出故事→确定故事→任务→估算排序→调整计划
质量保证：交付故事，人人有责
匹配能力与计划，自行决定故事粒度
迭代长度越短越好，满足“有价值、可用软件、可验收”以及发布实践范围、探索系数、准备评审时间的约束
迭代计划
核心：自律的个人和团队
方法：签约承诺
注意：适应型领导；管业绩目标，不管具体任务
工作量管理
实践：每日站会、故事任务检查表、燃尽图
监督迭代进程
迭代计划和监督
内在事物，不解决会阻碍未来发展，是实际变更成本与最佳变更成本的差值
技术债务
预测设计与适应设计之间的平衡
简单设计
尽早组合成一个整体，减少后续无法组合造成的高成本和测试负担
持续集成
单元测试，每次迭代中的质量保证和验收测试，各类测试自动化
自动化测试
不改变外部功能，减少技术债务
重构
低成本变更
技术实践
不了解敏捷
客户缺乏：参与、信任、决策责任、验收标准和测试
过长的开发进度，导致交付无意义
不明确的需求，导致不切实际的进度
教育客户
同步敏捷理念和方法
信任和尊重
彼此善意
清除不信任的人
构建信任
分享信息、协作创新、共同决策
互动驱动创新
鼓励点对点互动
互动
引导辩论，不是削弱冲突
原则：对事不对人
平等
贡献宝贵
攻击问题，不是对人
保持隐私
尊重彼此和差异
人人参与
团队规则
冲突解决
实践：把问题和人分离；关注价值与利益；能协作创新就不能妥协
教练和团队发展
快速有效解决问题
全情参与：畅所欲言
互相理解
兼收并蓄
责任共担
参与式决策
团队协作
基于共同价值观和原则
组织延期（不一致）
决策分级法：可分级解决
过度分析或没有良好的参与，将会导致慢决策
步骤：定义问题 — 做出决策 — 决策回顾
产品负责人全程参与
协调客户，也协调相关方
保护团队
客户每日交互
每日团队会议
项目社区
探索
获取客户反馈，响应变化
评审产品
发现和记录客户需求的变化
产品功能审查（产品演示会）
技术问题
设计问题
架构缺陷
技术质量（技术评审会）
技术审查
低于标准
达到标准
高于标准
团队绩效检查点（团队绩效评估会）
原始计划、修订计划、实际交付的对比
看板
累计流图：反映工作项在每个流程环节的流动问题
功能与价值交付
信息发射源
项目整体状态审查
团队
本次迭代中，实际完成功能的故事点大小的总和
团队通过观察历史表现，更准确地规划下阶段的能力衡量团队所交付的成果，不是团队预测将交付的成果
每一迭代完成的用户故事点
只有用户故事完成了，才计算在内
1速度=1故事点
剩余故事点
燃尽图
风险燃尽图：剩余多少风险（严重程度）
已完成故事点
燃起图
可以增加需求点
展现
发布：整个项目
迭代：当前冲刺
时间和故事点的关系
敏捷基于经验和价值
最好的结果：开发能力会趋于持续、稳定
工作量越少，越有可能交付
敏捷并不能创造出更多的工作能力
不同团队不做横向比较速度
监控
速度
适应
识别每次迭代的问题和缺陷进行根本原因分析
以往速度：作为下一个规划的参考
接下来的工作没有计划的复杂：速度可能会增加
扫尾：清楚未完事项
回顾：项目回顾、团队学习
庆祝：感谢、结束的氛围
敏捷管理阶段框架
关键环节，显而易见
保证干系人理解统一
能够看到过程，并理解看到的内容
透明性
经常检视
及时发现偏差
检视
典型用户操作，开发和测试在旁观察、聆听和记录
可用性测试
预设条件下，运行软件，评估结果
集成软件与系统其他部分结合，在实际运行环境下，进行严格有效的测试
系统测试
测试人员通过测试学习软件，同时整理和分析学到的内容，创造和设计新的更好的测试
探索性测试
测试
如果发现偏差不可接受，且会导致产品不可接受必须对过程或过程化的内容加以调整，调整工作必须b style=\
三个支柱
对接客户，收集需求
新增
删除
创建产品待办事项列表（需求池）
包括：变更后排序
排列待办事项优先级
制作产品路线图，并根据团队实际成果重新规划路线图
与团队合作，为迭代准备故事，细化足够的故事
向团队介绍故事，遇到不确定的问题，请求团队进行刺探（快速试错），了解风险
根据实际情况，清理、变更及重新排序
监控需求
经常及时给出反馈
鉴定“已完成的用户故事”
定义“已完成”
指定交付内容
有权接受或拒绝验收
产品负责人PO
价值排序（高于团队）
从“管理协调”转向“促进合作”
促进作用
培训、辅导、指导、引导
关键词：鼓励、辅导、提问、询问、提醒、提示、建议
对团队
敏捷教练SM
详尽的文档
冗长的过程
频繁的打扰
跨部门工作
行政任务
从“问题”中解放团队教育相关方
被求助
团队违反敏捷
不会敏捷工具
冲突无法自行解决
敏捷教练插手
日常会议培训：针对所有人，包括PO、团队、相关方等
消除障碍不分配工作不替团队做决定
主动认领任务
自我管理
自主决策
主动担责
聚焦业绩
交付价值
特点
核心职责：短期交付
允许建议性对抗：鼓励不同意见，即使会带来争论
3-9人
100%参与
跨职能通才型专家
构成
各种必要技能
获得授权
自组织管理
责任属于整个团队
改善沟通（渗透式沟通）
知识共享（团队培训）
集中办公（首选）
相互合作
鱼缸窗口
远程结对
视频会议
在线看板
在线协同工具
环境
项目团队
鼓励尝试新技术
三个角色
分布式团队：开始项目之前，确保团队之间的基本规则先确定规则，再确定待办如何改进
添加待办事项：需要PO与相关方一起协商敏捷教练不需要参与
需求问题：需要先找PO价值排序每日站会同步信息，不解决问题
客户不提供反馈：PO去沟通，确保获得客户反馈仅仅告知客户，无法确保反馈
“已完成”的标准：只有产品负责人最终接受该事项已完成，才是验收通过，故事状态才是“已完成”
所有工作的有序列表
PO按照价值从大到小排序（包括当下关注程度）
形式：用户故事
史诗故事
主题故事
用户故事（分类）
功能性需求
在迭代规划会议上，PO与团队合作为迭代准备，细化足够的故事团队选择该迭代承诺完成多少工作
团队每周不超过1h为下一批工作细化故事
滚动式规划（拆分）
系统重构
培训需求
根本原因
纠正措施
风险应对
运维工作
非功能性需求（性能）
详略适宜的（Detailed Appropriately）
可估计的（Estimable）
涌现的（Emergent）
排好优先级的（Prioritized）
DEEP原则
产品待办事项列表
维护产品待办事项列表
细化待办
上期遗留
新增事项
优先插队
删除事项
办成增量
PO维护产品待办事项列表
定义冲刺目标，明确本次冲刺的具体任务
迭代规划会议：产出起始冲刺待办事项列表
透明沟通：放在团队都看得到的地方
团队讨论并认领任务
任务：每天更新剩余任务工作量的估算
如果团队同意，有些事项可以先做大体估算，在冲刺中再分解成任务
团队资产，不轻易修改；若已无价值或紧急新增，团队有权增删改任务（置换）
冲刺待办事项列表
与PO沟通
为及时反馈和接纳，频繁向客户交付连续改善的工作产品
可交付产品增量
可测试的：说明没通过测试
为演示和反馈，冲刺末期交付增量
三个工件
细化待办事项不足：首先需要创建就绪的定义（DOR）细化：PO确定，相关方给建议，团队可参与，敏捷教练无需参与
产品待办事项列表：展示最大价值和投资回报率（针对整个项目）成本效益分析：针对单个故事的分析
功能驱动开发（FDD）：没有产品负责人由团队创建故事，添加到待办列表
细化故事没有确定方案：先将该风险故事移到待办的最前面，最先关注该工作
待办事项梳理会议
开发之前需要先把故事分解成任务
从产品待办事项列表（迭代规划会议）到迭代回顾会议结束本轮冲刺完成的工作及成果
默认迭代周期：1个月
冲刺/迭代
为即将开展的冲刺，制定计划
冲刺第一天：8小时（1周冲刺 — 2小时规划会议）
定义本次冲刺交付内容如何完成
具体目的
PO讲解产品待办，并细化故事（分解）；团队评估，自选事项，得到冲刺待办
团队将用户故事拆分成任务（及子任务），同时估算时间
团队认领任务
更新冲刺待办
会议内容
冲刺规划会议
一般15分钟
人多可以延长，或划分团队
主持人：任何人
团队：过看板
方式
PO可以旁听：抽签复述，提高参与度
已经完成了什么
计划完成什么
障碍是什么（风险/问题）
不要变成状态报告
发现问题，不是解决问题
两种反模式
冲刺结束时：4小时以内
产品负责人
被邀请的主要利益相关方
参会者
PO确认哪些事项已完成，哪些未完成
开发团队讨论哪些工作做得好，遇到什么问题，问题是如何解决的
开发团队演示“完成”的工作，解答交付增量的相关问题，获得验收
所有参会者探讨下一步工作，为下次迭代规划会议提供有价值的输入
未完成或未通过评审的用户故事，重新放回产品待办事项列表，在下次规划中评价
评审市场、潜在产品使用方式所带来的、接下来要做的最有价值的东西的改变同时，为下个预期产品功能或产品能力版本的发布，评审时间表、预算、潜力和市场（趋势分析）
指明方向
迭代评审会议
开发团队自我检视
创建下一个冲刺改进计划
评审之后且下次规划之前：3小时以内（内部会议）
确保会议举行，且积极、富有成效
确保每个参会者都明白会议目的
教导大家遵守时间盒规则
敏捷教练要做的
检视：成员、关系、过程、工具等
找出做的好的和做的不好的
制定改进计划
迭代回顾会议
12h-12h-15min-6h-6h
迭代6周
8h-8h-15min-4h-3h
迭代4周
4h-4h-15min-2h-2h
迭代2周
2h-2h-15min-1h-1h
迭代1周
Scrum会议时间盒
五个事件
敏捷教练如何确定团队是否缺乏知识：通过冲刺规划和相关方需求分析，安排一次冲刺
时间盒：规划期间可以调整
冲刺目标：描述接下来冲刺的主要目标
即时需求细化：需求分解为故事，使工作按小增量方式进行（规划会议的一个实践）
可以邀请其他关键相关方（客户）
产品待办梳理会-迭代规划-每日站会-迭代评审-迭代回顾
每日站会如何确定时间：站会主要针对团队，应该与团队讨论并确定具体时间
站会提出问题：先与直接人分析原因，再指定负责人跟进障碍，然后商议解决方案
团队成员每日工作报告：敏捷教练通过站会记录每个人的工作并分发给领导
同步最近项目所进行的活动：每日站会
风险提出时间：每日站会
同步信息
评审期间发现遗漏相关方：邀请相关方参与下次评审并提供反馈意见识别相关方无法解决不满足其需求的问题
回顾会议提出问题：直接讨论原因，商议解决方案
故事存在交付风险：在回顾会议上，先确定风险并规划措施，再安排工作
质量管理：项目正常进行的时候，通过回顾会议进行质量管理
通过获取更多想法解决问题：回顾会议上进行头脑风暴
愿意对目标作出承诺
承诺（Commitment）
全身心放在工作上
专注（Focus）
团队内所有信息对所有人开放
开放（Openness）
每个人都有独特的价值和经验
尊重（Respect）
勇于承诺，履行承诺，敢于说不
勇气（Courage）
五个价值观
敏捷Scrum实践
不均衡（Mura）
超负荷（Muri）
浪费（Muda）
消除浪费
浪费3M
花最少的钱，办最好的事
思想
浪费最小化，价值最大化
团队自我提升，进行决策
授权团队
即时生产，快速交付价值
快速交付
检视系统整体，各方面改进
全面优化
重构，持续集成，单元测试，优化
品质为先
尽早计划&最晚决策（避免反复修改）
晚做决策
尽早沟通，频繁反馈（保持学习状态）
强化学习
核心理念
等着被使用，应该：各环节更紧密
等待
多余的动作，多次重复浪费时间，应该：一次搞定
动作
检查出来的质量问题，应该：提前预防
缺陷
原料&产品库存积压，应该：即时制造
库存
生产溢出，应该：适当产出
过量生产
过度加工
运输空气，应该：最开始就是运输状态
运输
制造七浪费
多余的流程
镀金
多余的特性
多余的动作
思考方式转换、休息
任务切换
部分完成的工作
开发七浪费
选定需要分析的产品族
调查现状
绘制现状图
检讨问题点
绘制未来图
制定改善计划
分析信息或材料流动
价值流图
自动检测，发现问题停止生产
自动化
发送信号卡片
每道工序完成，指示上游提供库存
拉动系统
找出某情形发生的深层原因
持续改进
改善
安灯、单件流、现场现物、及时制
其他实践
精益（Lean）
体现增值与非增值数据
识别浪费，加以改进
每天都需要同步进行很多工作：说明在制品过多
可视化工作流程
约束在制品（WIP）
度量和管理流动（拉动）
显示化规则
建立反馈环
在协作及实验中改进
核心实践
信息共享的白板
狭义
基于信息可视化的系统性实践方法
广义
含义
累积流图（燃起图）：进度测量指标
信息发射器
与相关方了解项目
共享信息
管理风险
有助于
看板（Kanban）
Scrum：限制迭代周期
Kanban：限制在制品数量
Scrum & Kanban
基于频繁交付周期的软件开发方法
核心
关注团队凝聚力、沟通、代码质量和编程
过程中至少有一名客户代表
两个开发一起工作一个输入代码，一个审查代码
结对编程
快速学习
测试驱动开发（TDD：Test-Driven Development）
代码集体所有
不加班（一周不超过40小时）
开放的工作空间
及时调整计划
XP提倡的方法
持续集成（自动化测试）
极限编程XP
2-4周
迭代长度
遵循迭代计划
迭代内需求变化
团队酌情安排
迭代内优先级
子主题
工程实践
Scrum
1-2周
如果变化规模与原始相似，且原始未开始，，可以进行替换
严格按照优先级顺序
TDD，自动测试，结对编程，简单设计，重构
XP
Scrum & XP
其他敏捷实践
支持方法
团队信任度
团队决策能力
文化
变更速度
增量交付
项目关键性
团队规模
业务反馈
经验水平
敏捷适用性过滤器
分数越低，越接近敏捷
愿景
启动变革
理论：价值观、原则、协议
规划变革
实践：刺探、渗透、蚕食、累计
实施变革
平衡理论与实践
短期价值激励参与
管理过渡
维持变革
敏捷变革（变革管理模型）
锁定成本与进度，范围可变
动态系统开发方法（DSDM）
主协议固定，轻量级动态变化
多层结构
范围分解为：总价微型可交付成果（例如用户故事）
总价增量
置换：新工作替代原有工作
固定时间和材料
共担财务风险：期限前交付-奖励；期限后交付-惩罚
累进时间和材料
敏捷采购与合同
敏捷合同/协议
敏捷变革模型
敏捷项目
0 条评论
回复 删除
下一页
