导图社区 PMP-敏捷复盘
PMP考前敏捷开发相关知识及考点整理，内容有项目生命周期选择、敏捷宣言、十二原则、Scrum框架、其他敏捷的概念、按照10大知识领域来看敏捷。
PMP项目质量管理章节知识点考前整理复习， 新考纲过程领域 任务7-规划和管理可交付成果的质量，确定项目可交付成果必须达到的标准 根据质量差距提出改进方案的建议 持续调查项目可交付成果的质量。
PMP项目风险管理章节考前知识点整理复习，风险管理的目标在于提高正面风险的概率和（或）影响，降低负面风险的概率和（或）影响，从而提高项目成功的可能性。
PMP项目整合管理章节知识点整理，考前复盘，预测型项目，整合管理由项目经理负责，整合管理的责任不能被授权或转移；项目经理被要求尽早介入启动项目，例如开展商业论证和效益管理。
社区模板帮助中心，点此进入>>
论语孔子简单思维导图
《傅雷家书》思维导图
《童年》读书笔记
《茶馆》思维导图
《朝花夕拾》篇目思维导图
《昆虫记》思维导图
《安徒生童话》思维导图
《鲁滨逊漂流记》读书笔记
《这样读书就够了》读书笔记
妈妈必读：一张0-1岁孩子认知发展的精确时间表
PMP敏捷复盘
项目生命周期选择
预测型
传统的项目，成熟的行业：如建筑，制造业，IT行业
敏捷型
迭代
增量
混合型
公司转过渡阶段，从预测到敏捷
预测转敏捷活项目一部分是预测，一部分是敏捷
预测或敏捷，以题目的答案作为选择的方向
以关键字作为区分敏捷还是预测的题目
组织变革：从预测转敏捷
先分析评估公司的文化以及转型对公司的影响
进行自上而下的变革，让公司各个层级的人都参与进来，了解变更的好处和变革势在必行
可以选一个复杂度不高的项目作为试点，快速取得成功，给其他项目带来信心
敏捷宣言
人员
个体互动胜过过程和工具
客户合作胜过合同谈判
价值交付
可用的软件胜过完整的档案
应对变更胜过遵循计划
十二原则
我们最重要的目标，是通过及时和持续不断地交付有价值的软件使客户满意
欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化
经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期
可工作的软件是进度的首要度量标准
业务人员和开发人员必须相互合作，项目中的每一天都不例外
激发个体的斗志，以他们为核心搭建项目。提供所虚的环境和支援，辅以信任，从而达成目标
不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈
敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定持续
最好的架构、需求和设计出自组织团队
团队定期地反思如何能够提高成效，并依此调整自身的行为表现
过程
坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强
技术负债（Technical debt)和重构
以简洁为本，它是极力减少不必要工作量的艺术
Scrum框架
总体框架
产品愿景和产品路线图
需要多少个版本实现最终的产品
发布计划
1个版本确定了发布的迭代或冲刺次数
冲刺计划
要点
敏捷项目章程
我们为什么要做这个项目
项目愿景
谁会从中受益
这可能是项目愿景和/或项目目标的一部分
对此项目而言，达到哪些条件才意味着项目完成
项目的发布标准
我们将怎样合作
预期的工作流程
团队章程（团队社会契约）
团队价值观
例如可持续的开发速度和核心工作时间
工作协议
例如“就绪”如何定义，这是团队可以接受工作的前提；
例如“完成”如何定义，这样团队才能一致的判断完整性；
考虑时间盒
使用工作过程限制
基本规则
例如有关一个人在会议上发言的规定
团队规范
例如团队如何对待会议时间
3355
3个角色
产品负责人
开发团队
Scrum Master
3个工件
产品待办事项列表
Sprint待办事项列表
产品增量
5个事件
Sprint
Sprint计划会议
每日站会
Sprint评审会议
Sprint回顾会议
5个价值观
承诺
专注
开放
尊重
勇气
产品负责人PO （客户代表、业务专家）
维护和更新产品待办事项列表
产品负责人是管理产品待办事项列表的唯一责任人
维护产品待办事项列表，排优先级
清晰描述和表达，让团队能够充分理解产品待办事项列表
判断和批准产品增量是否完成
确定产品增量是否完成，符合DOD完成的定义
常出考点
PO必须是全职独立的，不能由开发团队或SM兼任
冲突途中，有新需求变更怎么办？
一般常规的新需求，现在PB表上，由PO进行优先级排序，通常不在本冲刺做这个需求
题目强调法律法规要求，优先级极高的需求，如果不马上完成，会导致项目失败，这种情况，一般是需要PO和团队进行沟通，重新调整本次冲刺的目标，以便尽快完成关系项目生死存亡的需求
自组织团队
一专多能，跨职能团队
不认可开发团队成员的头衔，无论承担哪种工作，他们都是开发者
最好是100%投入，全职团队，克服组织孤岛
追踪太阳
常见考点
题目中遇到要求，命令，强制团队去干事的，直接排除
开发团队自行决定和负责用户故事的估算，工作的分配等等
Scrum Master 又被称为敏捷教练，团队促进者, Scrum主管，项目经理
要确保敏捷整个团队和相关方遵循Scrum的理论、实践和规则
对于PO
确保他能理解PO的工作职责，包括如何维护和更新PB表
对于开发团队
确保他能按照日常敏捷事件，比如每日站会，比如使用透明化的工具等
对于项目外部
确保能理解敏捷实践，比如需要了解进度可以看信息发射源，需要了解用户故事优先级可以和PO沟通等
仆人式领导，服务式领导，关注团队成长，帮助团队消除障碍
内部障碍
开发团队遇到技术、流程等问题，协助解决而不是亲自动手解决
外部障碍
SM去协商去沟通外部相关方
在敏捷环境中，SM不负责具体的工作分配，工作安排等
一般都是SM负责扫除外部干扰团队的一些因素和阻碍
产品待办事项列表 Product backlog
用户故事
概念
作为一个<角色>，我想要<功能>，以便于实现<价值>
INVEST原则
Idependent（独立的）
Negotiable（可协商的）
Valuable（有价值的）
Estimatable（可评估的）
Small（小的）
Testable（可测试的）
故事点
作为一个内部参照的标准，团队内部使用。不同团队之间对故事点多少的比较没意义
估算用户故事点
计划扑克（宽带德尔菲）
使用敏捷估算扑克的好处
促进团队成员间的交流，可共享、了解更多的信息
团队对估算结果进行讨论和评判，会使估算结果更真实、客观，避免很多过于武断的决定
适用于一个具体的用户故事或者一个迭代的所用用户故事
亲和估算
适用于整个PB表，粗略的整体估算
包含内容
列出所有的特性、功能、需求、增强和修复对未来要发布的产品进行的改变
按照优先级由高到底排列的一个序列，高价值高风险>高价值低风险>低价值低风险
排序越高的产品待办事项列表条目更清晰、更具体，符合DOR，需要立即进行开发
持续动态更新，渐进明细
产品负责人负责
冲刺待办事项列表 Sprint backlog
把优先级高的用户故事从PB表移动到Sprint Backlog，在这个冲刺由团队决定做多少故事，并且由团队对用户故事进行细化
刺探/探针
主要是为了获取背景知识以知道某需求在技术上可行还是不可行，通常在不能有效估计用户故事时采用该方法
至少包括一项在先前回顾会议中确定下来的高优先级过程改进
开发团队负责，PO进行解答疑惑
产品增量 Product Increment
打到了“完成”的定义标准DOD
产品负责人决定是否完成，不管是否发布，增量必须保证可用和持续集成
翻译为“冲刺”或“迭代”
时间2-4周（固定的时间盒 time box），5-9人
注意事项
不能做出有害于 Sprint 目标的改变
不能降低质量的目标
只有产品负责人才有取消Sprint的权力，由于Sprint的时间都很短，取消意义不大
Sprint规划会议
做计划
接下来的Sprint交付的增量要包含什么内容
要如何完成交付增量所需的工作
开发团队自己决定选择产品待办列表项的数量
产品负责人能够帮助解释清楚所选定的用户故事，并作出权衡
参加人员
一般是SM、开发团队、PO 共同参与，也可以邀请重要相关方参加
会议内容
昨天
我为帮助开发团队达成Sprint目标做了什么
今天
我为帮助开发团队达成Sprint目标准备做什么
是否有任何障碍在阻碍我或开发团队达成Sprint目标
会后更新信息发射源（看板、燃尽图、燃气图等）和问题看板
只记录问题而不是讨论问题，可会后专门相关人员进行问题解决会议
SM确保同一时间，同一地点举行，一般建议团队成员来主持，时长一般是15分钟
每日站会能够即使跟进进度和纠偏
每日站会能够避免同样的工作被不同的成员重复开展
能够及时发现问题和风险，在会后及时改进能够最大限度地降低风险对项目造成的影响
开发团队（SM、PO、重要相关方视情况）
SOS会议（Scrum of Scrums）
Sprint评审会议 review meeting
检视产品增量，获得反馈
开发团队演示产品增量，PO邀请利益相关方参与，PO确定产品增量是否完成
调整产品待办列表
阐明很可能进入下个Sprint的产品待办列表项
Sprint评审会议的结果是一份修订后的产品待办列表
客户
重要相关方
PO
SM
Sprint回顾会议 Retrospective meeting
回顾哪些做得好，哪些需要改进，需要改进的内容放到下一个Sprint里面跟进（持续改进）
PO（视情况）
愿意对目标做出承诺
把你的心思和能力都用到你承诺的工作上去
Scrum把项目中的一切开放给每个人看
每个人都有他独特的背景和经验
有勇气做出承诺，履行承诺，接受别人的尊重
其他敏捷的概念
看板管理
可视化的工作流程
一个白板，一些卡片就可以创建
消除瓶颈
WIP（Work In Progress）在制品的限制
题目提到项目工作流程混乱，造成一些工序堵塞，看板管理能有效解决这个问题
题目提到其他的流程或者工序开展非常顺利，只有某一道工序遇到了瓶颈，造成整个流程的进度延迟，可以考虑把其他流程的跨职能团队成员分派过来整个瓶颈的流程
MVP（Minimum Viable Product）
快速地构建出符合产品预期功能的最小功能集合，这个最小集合所包含的功能足以满足产品部署的要求并能够验证有关客户与产品交互的关键假设
用最少资源和最短时间做实验，获得早期用户的反馈
客户无法明确确定需求，可以构建初步产品原型，通过后续反馈和修正，最终满足客户需求
在市场不确定的情况下或者风险比较大的时候，通过MVP设计实验来快速检验你的产品或方向是否可行
按照10大知识领域来看敏捷
整合
把对具体产品的规划和交付授权给团队来控制。团队成员自行决定计划和整合方式
项目经理的关注点在于营造一个合作型的决策氛围，并确保团队有能力应对变更
敏捷不存在变更控制流程的说法，敏捷是拥抱变更
范围
敏捷方法有目的地构建和审查原型，并通过发布多个版本来明确需求。这样一来，范围会在整个项目期间被定义和再定义
每次冲刺开始前都定义范围
Sprint规划会议和Sprint的待办事项列表
每次冲刺结束前都确认范围
Sprint的评审会议review和产品增量的批准
进度
产品愿景、发布规划和迭代计划之间的关系
具有未完项的迭代型进度计划
是一种基于适应性生命周期的滚动式规划。这种方法需求记录在用户故事中，然后在建造之前按优先级排序并优化用户故事，最后在规定的时间盒内开发产品功能。这一方法通常用于向客户交互增量价值，或多个团队并行开发大量内部关联较小的功能
按需进度计划
通常用于看板体系，基于制约理论和来自精益生产的拉动式进度计划概念，根据团队的交付能力来限制团队正在开展的工作。按需进度计划方法不依赖于以前为产品开发或产品增量指定的进度计划，而是在资源可用时立即从未完项和工作序列中提取出来开展
控制进度工具
信息发射源
燃尽图
燃起图
成本
采用轻量估算方法
详细的估算适用于采用准时制的短期规划
质量
规划质量管理
DOD的定义
管理和控制质量
循环回顾，定期检查质量过程的效果，寻找问题的根本原因，实施新的质量改进方法
关注小批量，可以频繁交付
测试驱动开发TDD，持续集成
资源
得益于最大限度地集中和协作的团队结构，例如拥有通才的自组织团队
沟通
尽量简化团队成员获取信息的通道，频繁进行团队检查，并让团队成员集中办公
集中办公
日常工作：每日站会
需要以透明的方式发布项目工件，并定期邀请相关方评审项目工件
日常工作：信息发射源
汇报沟通：冲刺评审会议
虚拟团队
鱼缸窗口
建立长期视频会议链接
远程结对
通过使用虚拟会议工具来共享屏幕，包括语音和视频链接
风险
迭代规划的时候，应该考虑风险
在迭代期间应该识别、分析和管理风险
应该根据对当前风险敞口的理解的加深，定期更新需求文件，并随项目进展重新排列工作优先级
采购
可能需要与特定卖方协作来扩充团队。这种协作关系能够营造风险共担式采购模型，让买方和卖方共担项目风险和共享项目奖励
灵活的协议
多层结构
主协议
补充协议
相关方
提倡高度透明
例如，邀请所有相关方参与项目会议和审查，或将项目工件发布到公共空间，其目的在于让各方之间的不一致和依赖关系，或者与不断变化的项目有关的其他问题，都尽快浮现
高度变化的项目更需要项目相关方的有效互动和参与。为了开展及时且搞笑的讨论及决策，适应性团队会直接与相关方互动，而不是通过层层的管理级别
