导图社区 PMP认证考试-敏捷项目管理知识
- 213
- 9
- 0
- 举报
PMP认证考试-敏捷项目管理知识
PMBOK 6 之后，新增了敏捷项目管理知识，这一部分新增的内容，囊括了敏捷管理的多个框架，包含Scrum、精益和看板等敏捷实践，是学习敏捷管理必须要掌握的内容。
编辑于2022-05-13 15:15:04- 敏捷管理
- 管理知识
- 认证考试
- 敏捷框架
- 相似推荐
- 大纲
PMP认证考试-敏捷项目管理知识
敏捷价值与敏捷宣言
敏捷宣言
个体与互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划
敏捷价值原则
原则1：我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户
原则2：欢迎对需求提出变更，即使在项目开发后期也不例外。 敏捷过程要善于利用需求变更，帮助客户获得竞争优势。
原则3：要经常交付可用的软件，周期从几周到几个月不等，且越短越好。
原则4：可用的软件是衡量进度的首要衡量指标。
原则5：敏捷过程提倡可持续的开发。项目发起人、开发人员和用户应该保持步调稳定。
敏捷生命周期
预测型
需求固定计划驱动
一种更为传统的方法，提前进行大量的计划工作，然后一 次执行；抗行是一个连续的过程。也称为计划型或瀑布式。
迭代型
需求变化变更频繁
这种方法允许对未完成的工作进行反馈，从而用一次次的 迭代去改进和修改该工作。
增量型
需求变化逐步交付
这种方法是通过在预定的时间区间内渐进增加产品功能的 一系列迭代来产出可交付成果。
敏捷型
迭代增量合二为一
宏观掌控全局 微观把握细节
这种方法既有迭代，也有增量，便于完善工作，频繁交付。
子类型
基于迭代
基于流程
混合型生命周期
敏捷法为主
预测法为辅
敏捷十二原则
(1)我们的最高目标是，通过尽早持续地交付有价值的软件来满足客户的需求。
尽早交付
持续交付
有价值
客户满意
满意度
(2)欢迎对需求提出变更，即使在项目开发的后期也不例外。敏捷过程要善于利用需求变更，帮助客户获得竞争优势。
传统项目管理影响和控制会导致变化的因素
敏捷不是，而是预期到需求会变化
拥抱变化，即使这些变化发生在项目后期
通过原则、模式、实践来保证软件足够灵活
迅速应对和适应变化，能给客户带来显著的竞争优势，从而应对新的机遇
拥抱变化
(3)要经常交付可用的软件，周期从几周到几个月不等，且越短越好。
经常交付可用的软件，时间间隔越短越好
Scrum的迭代周期大概为2-4周
XP的迭代周期则会短至一周
较短的迭代周期强化团队持续关注客户的价值
频繁交付
且需要交付客户价值
(4) 项目实施过程中，业务人员与开发人员要必须始终通力协作。
传统项目中负责商业价值的人员和软件开发人员是严格分开工作的
让每支团队都可以集中精力做他们擅长的事情
敏捷项目管理提倡他们同一个地方一起工作
团队成员和用户能相互理解彼此的想法
他们的共同目标就是通过可用的软件向客户传递价值
一起工作
(5)要善于激励项目人员，给予他们所需的环境和支持，并相信他们能够完成任务。
激励人，人比拥有最好的流程和工具更重要
建立强有力的团队并积极避免微观管理
自律的团队，而不是一个自上而下的指令
分享空间：可视性和共同性
给团队自由时间
提供环境支持
(6)无论是对开发团队还是团队内部，信息传达最有效的沟通方法都是面对面的交谈。
非正式的口头沟通在敏捷项目管理中远比正式的书面沟通更普遍
敏捷项目中的沟通都是公开的，任何团队成员都可以自由参与对话
最高效的沟通是面对面交谈
渗透式沟通
高带宽沟通
面对面沟通
(7)可工作软件是衡量进度的首要指标。
传统项目往往极其纠结的是，项目的不断更新使得文件成为一种负担
真正的价值是通过结果来表达的，结果又是通过可用的软件来呈现的
可工作的软件是首要度量标准
关注需求完成度
关注软件的可用程度
衡量指标
(8)敏捷过程提倡可持续的开发。项目发起人、开发人员和用户应该都能够始终保持步调稳定。
敏捷项目比传统项目有更高的近作强度)（尤其是使用XP这样的方法时）
保持一个稳定的可持续的进展速度，从而使得团队成员不会在迭代周期的尾端匆忙赶工
不允许过度的压力和过度疲劳
不会借用明天的精力来在今天完成多一点工作
可持续步调
(9)对技术的精益求精以及对设计的不断完善将提高敏捷性。
保持软件干净、整洁
设计越完善，维护越简单
编写高质量代码
重构
稳定和优质的项目比劣质的项目更加允许团队快速应对变化
技术卓越
(10) 简洁，即尽最大可能减少不必要的工作，这是一门艺术。
这个原则被所有的敏捷方法所拥护，尤其是精益方法
关键点是对客户价值保持专注和毫不犹豫地削减不增加价值的活动
保持简单是最基本的原则
不构建华而不实的系统
简洁
(11)最佳的架构、需求和设计将出自于自组织团队。
自我组织是敏捷团队的核心元素之一
任务是分配给整个团队的，而不是某个人
自组织团队，即该团队自己去决定工作如何分配及谁去做某个特定的工作
传统项目和敏捷项目最显著的区别
不仅小团队是自我组织的，较大的跨职能团队也可以是自我组织的。
不存在某个人对架构、需求、测试负责的情况，整个团队共同承担这些责任
自组织团队
(12)团队要定期反省怎样做才能更有效，并相应地调整团队的行为。
传统项目里，当项目或阶段完成时开会总结是最常见的做法
敏捷通过更频繁的回顾来完成这项工作。
Retrospective Meeting
在一个回顾活动中，查看上个迭代周期中已完成的工作或发布， 并评估下一次如何改进他们的做法
每日站立会议是另一项协调团队努力方向、团队自我评定和自我调整的重要方式
定期反思
生命周期类型选择
选择方法
敏捷适用性筛选器
对照敏捷
确定适合性or差距
原则
以最好方式创造商业价值
选择提问
我们怎样做才能最成功？
当团队创造价值时，是否需要反馈？
探讨各种想法时，是否需要管理风险？
能否交付交付中间价值
混合敏捷法
裁剪
价值
需求模式.稳定or偶发
利用时间盒
使用流程敏捷
产品增量的质量不佳
考虑.各种TDD.实践
团队
经验水平所要求.过程改进速度
更频繁回顾
成员缺乏经验
培训基本原理
创建某个产品需多个团队
了解正规框架
精心制定方法
方法
工作流往往被各种延误和障碍打断
利用看板
混合生命周期
四种方法组合
先敏捷+再预测
同时敏捷+预测
预测主+敏捷辅
敏捷主+预测辅
预测过渡到敏捷
渐进混合过渡
尝试敏捷新技术
项目类型
风险不大
不确定性程度适中
尝试复杂项目
增加更多技术
目的
选择最可能成功的方法
PMBOK中关于在敏捷或适应型环境中需要考虑的因素
整合：自组织团队Self organizing team
范围：需求变化，多迭代版本，产品待办列表
进度：燃尽图、燃起图
成本：根据严格的预算控制范围，产品待办列表
质量：PDCA，频繁的增量交付，评审会议，回顾会议
资源：具有通才的自组织团队，共同承担责任
沟通：集中办公，面对面沟通，信息发射源，定期邀请相关方评审
风险：及时响应，作为用户故事添加，定期排列需求优先级
采购：大型项目，适应型针对某些可交付成果，变更只针对适应型工作
相关方：直接与客户对接，减少中间的层层管理级别； 加快组织内部和组织之间的信息分享，敏捷提倡信息高度透明
敏捷项目管理阶段框架
敏捷的五个阶段
构想
愿景
商业论证框架
投资目标限于已有资金。
投资回报是与愿景相关联的收益流。
投资和回报与里程碑相关联。
里程碑确定时间，收益和成果与价值优先级排序的时间相关。
产品愿景盒
团队分解成小组（4-6人）来设计并演示产品盒
各小组探讨产品的差异化优势
敏捷团队章程
团队社会契约
团队价值观：如可持续的步调和工作时间
工作协议：如就绪的定义，完成的定义，时间盒的期望，工作流的限制
基本准则：如一个人如何在会上发言
团队规范：团队如何对待会议时间
推测
步骤
故事清单
发布计划
概念
时间盒
目的：克服帕金森定律
优点：高度关注价值
缺点：客户价值转移到技术难度
固定的一段相对比较短的时间
计划的工作要在这段时间内完成
用户画像Personal（人物）
故事地图(MVP VS MMF)
最小可行产品MVP（Minimum Viable Product）
最小可售功能MMF（Minimal Marketable Feature）
特性Feature
对客户有用和有价值的特性
最小可售功能（MMF）
可以为客户提供价值的足够小且足够完整的功能包
价值交付
敏捷洋葱圈
敏捷发布规划（洋葱头）
产品愿景驱动产品路线图
产品路线图驱动发布计划
发布计划规定迭代
迭代计划安排功能开发
功能开发满足用户故事
用户故事创建任务
产品地图
故事地图
用户故事
用户故事的3C原则
Card 卡片
Conversation 交谈
Confirmation 确认
用户故事的INVEST原则
Independent 独立的
Negotiable 可协商的
Valuable 有价值的
Estimable 可估计的
Small 小的
Testable 可测试的
用户故事估算
宽带德尔菲
一种基于团队共同参与的估算方法，一群专家匿名提交估算结果，彼此不 知道真实的结果，这样可以提升团队成员对结果的认同感，也可以避免产 生一些“花车效应”和“花环效应”。一般会进行多轮，直到达成共识。
计划扑克
每人10张数字牌，每个人选一张卡片，这个时间点选择的卡片不能给他人 看。所有参与者同时展示自己的卡片，团队一起来讨论这些估计值，尤其 对异常值（最高的和最低的）要着重讨论。最后选择连续几轮的估算。
理想时间
除了使用故事点来估算用户故事的相对规模外，敏捷团队还可以用理想时间 来估计，即估计构建各个工作项所需的实际时间，而不考虑速度或中断。
用户故事优先级
优先级排序的方法
MoSCoW法则
Must: 必须做的
Shoud： 应该做的
Could: 可以做的
Would not：不要做的
卡诺模型 (KANO模型）
卡诺模型 (KANO模型）是对用户需求分类和优先排序的有用工具，以分析用户需求对用户满意的影响为基础，体现了产品性能和用户满意之间的非线性关系。
风险四象限
敏捷团队通常会维护工作项的一个有序列表，把最高风险的项 放在这个列表最上面，使它们最先得到处理。这种实践叫已调 整风险的待办列表。
适应
适应性行动
探索
完成的故事
刺探/探针 (Spike)
是一种技术尝试，快速试错， 可以明确新技术在新环境下 的可行性，以降低风险
架构刺探Spike 用来证明一个特定的 架构方案是否可行
基于风险的刺探Spike 团队研究某个问题而进行的快速的概念验证 活动，常用来测试陌生的或全新的技术。 在深入采用这种技术之前，探测的结果能够 避免陷入太深，用于消除项目风险
探索实践
迭代计划和监督
工作量管理
迭代计划和监督
技术实践
低成本变更
项目社区
教练和团队发展
每日团队会议
参与式决策
客户每日交互
结束
五个阶段的实践清单
构想阶段
项目论证
顶目章程
我们为什么要做这个项目？
谁会从中受益？如何受益？
对此项目而言，达到哪些条件才意味着项目完成？
(愿景及产品路线图）
我们将怎样合作？
产品感景说明
电梯测试说明
关于产品定位、目标客户、关键收益和竞争优势的简短声明
产品架构
项目数据表
得到正确的人员
参与人员识别
客户和团队接口
过程定制
推测阶段
创造场景和人物
什么是场景？
什么时间(when)
会想到某种手段 (method)来满足欲望
什么用户（who）萌发了某种欲望 (desire)
什么地点 (where)
周围出现了什么事物时 (with what)
场景举例 (GreatPos)
收银员：销售点给顾客找零钱的场景
饭店服务生：接受订单的场景
功能分解结构
产品未完项
高层级亲和估计
产品路线图
版本、里程碑、迭代计划
性能需求卡片
划分故事-故事卡片
探索阶段
工作量管理
低成本变更
教练和团队发展
每日团队会议
参与式决策
客户每日交互
适应阶段
迭代审查
迭代回顾
结束阶段
项目总结
复盘
庆祝
敏捷SCRUM实践
三个支柱
透明性 (Transparency)
过程中的关键环节对相关人是显而易见的，同时保证干系人对这些关键环节理解是统一的。
管理生产成果的人不仅要能够看到过程的这些方面，而且必须理解他们看到的内容。
检视 (Inspection)
Scrum使用者必须经第检视Scrum的工件和完成Sprint目标的进展，检视顿率应适宜
适应 (Adaptation)
如果检视发现一个或多个方面的偏差偏离可接受范国以外，并且将会导致产品不可接受时，就心须对过程或过程化的内容加以调整。调整工作必须尽快执行，如此才能减少进一步的偏离。
三个角色
产品负责人(Product Owner)
产品负责人负责指导产品的开发方向。
产品负责人根据商业价值对任务进行排序。
提供产品反馈，为将要开发/交付的下一个功能设定方向。
敏捷教练(Scrum Master)
敏捷项目经理 敏捷项目管理师 敏捷管理人士 敏捷管理专业人士
（仆人式领导）
促进作用
消除组织障碍
为他人贡献铺路
【要点】鼓励、辅导、提问、询问、提醒、提示。建议。总之，不做决定。
项目团队(Scrum Team)
敏捷开发团队 敏捷团队
自组织团队
团队特点
自组织、授权；强烈的产品责任感，价值驱动导向， 建设性对抗。
作为一个独立团队，交付完成的价值，聚焦绩效，自主决策，自主担责。
团队构成
3~9名，100%专职成员，通才型专家（PO，SM不包含在人数中）
团队规模：两个披萨原则；
通才型专家T：敏捷团队是跨职能的，鼓励成员成为通才；
专职成员：多任务带来切换成本。但并非所有人都要求专职，如临时专家。
团队环境
团队获得授权，自组织和管理他们的工作。责任属于整个开发团队。
集中办公（首选）与虚拟办公
集中办公：改善沟通（渗透式）、知识共享（团队培训）、致力于相互合作；
虚拟办公（分布式）：鱼缸窗口和远程结对。
【要点】聚焦绩效，自主决策，自主担责，建设性对抗
【要点】团队内部问题，自主决策，自主担责。
【要点】鼓励通才型专家团队，打破孤岛(竖井问题的沟通瓶颈
【要点】全球的，分布式团队，虚拟团队，使用在线协作工具（视频、看板）辅助沟通：
成功敏捷团队的角色
产品负责人
指导产品的开发方向；创建、维护产品待办事项列表；
根据商业价值排序任务；提供反馈
敏捷教练
团队促进者，确保遵循敏捷流程；
引导、指导、消除障碍
敏捷团队
拥有各种必要技能；以常规节奏交付潜在可发布产品；
核心职责是在短时间内交付任务
三个工件
产品待办事项列表 (Product Backlog)
理念与原则
产品待办事项列表是所有工作的有序列表，它以故事形式呈现给团队，价值越大的排在越上面。
产品负责人PO在迭代规划会议中与团队合作，为即将进行的送代准备故事，细化足够的故事。
团队每周用不超过1小时的时间来为下一批工作细化故事。团队希望把时间尽可能花在工作上，而不是计划上。
包含内容
功能性
用户故事
主题故事
史诗故事
非功能性
技术债务
系统重构
培训需求
根本原因
纠正措施
风险应对
运维工作
变化内容
细化待办
上期遗留
新增事项
优先插队
删除事项
办成增量
DEEP模型
详略适宜的 (Detailed Appropriately)
可估计的 （Estimable)
涌现式的 (Emergent)
排好优先级的 (Prioritized)
要点
技术债务、风险应对、运维工作等作为非功能性用户故事列入待办事项
过大的用户故事需要拆分，以确保能够在迭代期间内完成
冲刺待办事项列表 (Sprint Backlog)
要点
冲刺待办事项列表定义了Sprint的目标，明确了Sprint过程中具体需要完成的任务
可交付产品增量 (Increment)
可交付产品增量，是指为及时反馈和接纳，频繁向客户交付连续改善的工作产品。
为演示和反馈，往往在每一个冲刺或迭代的未期交付产品增量。
五个事件
冲刺迭代（Sprint)
为即将要开展的sprint制定计划
sprint第一天，控制在8小时以内（每周送代时长对应约2h会议时间）
定义本sprint要交付的内容如何完成
会议基本内容
1、一般由PO来讲解产品待办事项列表 (Product backlog)，并细化故事，团队来进行评估，得出冲刺待办事项列表 (Sprint backlog)。
2、将用户故事拆分成任务(task)以估算时间
3、团队成员领取任务 (task)
4、更新sprint待办列表
冲刺规划会议 （Sprint Planning)
【要点】细化、定义、挑送、分解、估算，形成迭代待办事项。
【要点】相关方可以通过参加冲刺计划会议了解与参与团队工作
每日站会(Daily Scrum)
一般不超出15分钟；（人数过多可稍微延长，或划分团队）
团队以某种方式“过一下”看板或任务板，而团队中的任何人都可以主持站会；
每个人轮流回答问题：
1、上次站会以来我都完成了什么？
2、从现在到下一次站会，我计划完成什么？
3、我的障碍（风险或问题）是什么？
两种反模式
变成状态报告；
站会是为了发现问题，而不是解决问题。
【要点】每日站会是支撑敏捷原则最重要的基石之一
【要点】每日站会共识信息，协调团队专注目标；提出问题和风险，消除冲突，确保持续改进
迭代评审会议 (Sprint Review）
发生在sprint结束时，控制在4小时以内
参会者包括Scrum团队和产品负责人邀请的主要利益相关者
会议内容
1.产品负责人说明哪些产品待办列表项已经“完成”和哪些没有“完成”
2.开发团队讨论在Sprint期间哪些工作做得很好，遭遇到什么问题以及问题是如何解决的；
3开发团队演示“完成”的工作并解答关于所交付增量的问题，获得相关方验收通过；
4.未完成或未通过评审的用户故事，重新放回产品待办事项列表，在下一次迭代规划会议评价；
5.参会的所有人就下一步的工作进行探讨，为接下来的Sprint计划会议提供有价值的输入信息；
6.评审市场或潜在的产品使用方式所带来的接下来要做的最有价值的东西的改变；同时为下个预期产品功能或产品能力版本的发布评审时间表、预算、潜力和市场。
迭代回顾会议 (Sprint Retrospective)
Sprint回顾会议是Scrum 团队检视自身并创建下一个Sprint计划的机会。
回顾会议发生在Sprint评审会议结束之后，下个Sprint计划会议之前。
ScrumMaster确保会议是积极的和富有成效的。ScrumMaster教导大家遵守时间盒的规则。
目的在于
1.检视前一个Sprint中关于人、关系、过程和工具的情况如何；
2.找出并加以排序做得好的和潜在需要改进的主要方面；同时制定改进Scrum团队工作方式的计划。
五大价值观
承诺 (Commitment) -愿意对目标做出承诺
专注(Focus) -全身心都用到你承诺的工作上去
开放 (Openness) -团队内所有信息对所有人开放
尊重 (Respect)-每个人都有他独特的价值和经验
勇气 （Courage) -勇于承诺，履行承诺，敢于说不
敏捷变革模型
敏捷适用性过滤器
文化
是否具有支持该方法
并已建立信任的团队环境？
团队是否有自主决策能力？
指标
支持方法
团队信任度
团队决策能力
团队
变更速度极快？
增量交付可行？
项目关键性如何？
指标
团队规模
经验水平
客户/业务联系
项目
适当规模的团队？
客户/业务反馈？
敏捷经验水平？
指标
变更可能性
产品或服务关键性
增量交付
敏捷变革
Stacy斯泰西图
变革管理模型
启动变革
建立理论基础，理解为什么需要变革，以及未来如何好。
规划变革
理论：价值观、原则、协议
识别活动，帮助人们为过渡做好准备。
实施变革
实践：刺探、渗透、蚕食、累计
做出必要的改进或调整。
管理过渡
平衡理论和实践，短期价值激励参与。
如何满足与未来状态实现后可能出现的变化有关的需求。
维持变革
持续改进
确保新效果持续，而旧世界不会卷土重来。
敏捷采购与合同
动态系统开发方法（DSDM）
敏捷合同/协议
多层结构
主协议：固定项目（担保、仲裁等）锁定
主要服务协议：可能会变更的服务价格、产品说明等；
轻量级工作说明说：范围、进度和预算等更多动态变化项目。
总价增量
项目可以将范围分解为总价微型可交付成果（例如用户故事），而不是 将整个项目范围和预算锁定到单个协议中。
固定时间和材料
将整体预算限制为固定数量。如客户需纳入新观点，必须管理给定能 力，用新的工作替代原有工作。
累进的时间和材料
共担财务风险法，合同期限之前交付，则奖励；反之，则惩罚。
其他敏捷实践
精益思想
花最少的钱，办最好的事，核心是消除浪费。
浪费3M
不均衡(Mura）
超负荷(Muri)
浪费(Muda)
精益七大 核心概念
消除浪费
要想获得最大化的价值，必须将浪费最小化。延期、没有用 的功能、等待都是一种软件浪费。
授权团队
尊重团队成员并由团队来进行决策，保证项目的效率并且有 利于项目成功。
快速交付
通过快速交付有价值的软件来最大化项目的投资回报率(ROI)
全面优化
去检视系统的整体而不是一部分，关注整个组织的优化改进，关注团体。
品质为先
精益开发不是测试为先，而是通过重构、持续集成、单元测试 等技术手段来加强质量保证。
晚做决策
最早计划和最晚决策
强化学习
通过尽早沟通和频繁的反馈来建立学习的内容。软件项目是业 务和技术两项经验的积累，需要尽快开始并保持学习的状态。
精益制造 的 七大浪费
价值流图
步骤一：选定需要分析的产品族
步骤二：调查现状
步骤三：绘制现状图
步骤四：检讨问题点
步骤五：绘制未来图
步骤六：制定改善计划
其他实践
自动化：创建自动化方法，只要检测到问题就停止生产。
看板：发出信号的卡片
拉动系统：流程中每个工序在零部件消耗完成时指示上游工序它需要更多库存
根本原因分析：找出某种情形发生的“深层”原因
持续改善：持续改进
安灯
单件流
现场现物
及时制
看板实践
看板六大核心实践
1、 可视化工作流程
2、约東在制品(WIP)
3、 度量和管理流动（拉动）
4、 显示化规则
6、建立反馈环
6、在协作及实验中改进
信息发射器
累计流图
燃起图
响应时间
交付周期
周期时间
工作列队
剩余任务
燃尽图
极限编程（XP）
是一种基于频繁交付周期的软件开发方法。
关注团队凝聚力、沟通、代码质量和编程。
XP实践领域
组织
集中办公
整个团队
信息灵通的工作场所
真实客户参与
团队连续性
可持续节奏
技术
结对编程
测试驱动开发
增量设计
共用代码/隼体所有制
代码和测试文档
重构
规划
用户故事
每周周期
每季周期
松弛
根本原因分析
裁剪团队
按使用情况支付
协商范围合同
每日站会
整合
10分钟构建
持续集成
测试优先
单代码库
增量部署
每日部署
XP提倡的方法
1、过程中至少有一名客户代表
2、快速交付
3、结对编程
4、 驱动测试开发TDD(Test-Driven Development)
5、代码集体所有
6、不加班（一周不超过40h）
7、开放的工作空间
8、及时调整计划
9、重构