PMP®考试敏捷常考知识点汇总，绝对干货！！
2024-02-23
PMP®是项目管理领域的国际认证，拥有一大批考证大军。
PMP®证书一个很大的优势是不受行业限制，不论你是在金融，建筑，通信，IT，制造业等领域，还是企业中的项目管理者，项目负责人，或者是普通技术人员都是适用的。
改版后的PMP®考试敏捷题型比重上升，为了帮助广大考生尽早掌握PMP®考试中的敏捷知识点，将PMP®考试敏捷相关信息做了整理，让我们一睹为快吧！
一、敏捷宣言十二原则
01、我们的最高目标是，通过尽早持续地交付有价值的软件来满足客户的需求；
02、即使在项目开发的后期，仍欢迎对需求提出变更。敏捷过程通过拥抱变化。帮助客户创造竞争优势；
03、要不断交付可用的软件，周期从几周到几个月不等,且越短越好；
04、在项目过程中,业务人员与开发人员要每天在一起工作；
05、要善于激励项目人员，给他们所需要的环境和支持，并相信他们能够完成任务；
06、团队内部和各个团队之间，最有效的沟通方法是面对面的沟通；
07、可工作软件是衡量进度的首要指标；
08、敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久、稳定的进展速度；
09、对技术卓越和好的设计的持续关注有助于增强敏捷性；
10、尽量做到简洁，尽最大可能减少不必要的工作。这是一门艺术；
11、最佳的架构、需求和设计出自自组织团队；
12、团队要定期回顾和反省如何能够做到更有效,并相应地调整团队的行为。
二、SCRUM的三三四
三个角色：
产品负责人Product Owner；
团队负责人Scrum Master；
自组织团队Self-organizing Teams；
三个物件：
产品代办事项列表Product Backlog；
冲刺列表Sprint Backlog；
可交付产品增量 Increment。
四个会议：
冲刺计划会议Sprint Planning；
迭代评审会议Sprint Review；
迭代回顾会议Sprint Retrospective；
每日站会Daily Scrum。
三、产品负责人
敏捷中主要包括三个角色：产品负责人(Product Owner)、敏捷教练(Scrum Master)、 项目团队(Scrum Team)。
产品负责人(Product Owner)：主要负责确定产品的功能和达到要求的标准，维护产品代办事项列表，指定软件的交付的内容，同时有权力接受或拒绝开发团队的工作成果。
四、敏捷教练(Scrum Master)
Scrum框架中的三个角色之敏捷教练(Scrum Master)：
主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。主要有服务团队、教导团队、保护团队、引导Scrum的有效应用职能。
五、敏捷三大角色之项目团队
主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在3~9人左右(PO、SM不包含在人数中，除非参加执行冲刺列表中的工作)，团队获得授权，自组织和管理他们的工作。每个成员可能负责不同的技术方面，但要求每成员必须要有很强的自我管理能力，责任属于整个开发团队。为团队提供了一种一起成功、失败、调整、改进的途径。
六、敏捷-冲刺计划会
目的：
用来决定本次Sprint的交付成果以及为了达成目标应该如何工作。
特征：
标志着Sprint的开始；
确定哪些用户故事会被纳入本迭代中进行；
并拆分成task以估算时间团队成员领取task；
PO必须为迭代计划会议准备一个最新的、经过排序的待办事项列表；
对于一个月的 Sprint来说， Sprint计划会一般不超过8个小时。
七、敏捷-每日站会
定义：
为了在团队内部沟通交流成果以及阐述任何存在的障碍而召开的每日例会。
做法：
不超出 15 分钟；
团队以某种方式“过一下”看板或任务板，而团队中的 任何人都可以主持站会；
每个人轮流回答问题：
昨天，我做了什么?
今天，我准备做什么?
是否有任何障碍?
两种反模式：
变成状态报告；站会是为了发现问题， 而不是解决。
八、敏捷-冲刺评审会
目的：
团队给PO和相关干系人演示 Sprint中所完成的功能(尽可能使用相对真实的环境)，并接受PO的意见、建议和评价，用以检视所交付的产品增量并根据需要调整产品待办事项。
评审结果：
一份修订后的产品待办事项列表，明确很可能进人下一个送代的待办事项。
九、敏捷-冲刺回顾会
定义：
在Sprint结束时召开的关于团队自我持续改进的回顾复盘会议。通常在Sprint评审会之后，在下次Sprint计划会议之前展开。一个月的sprint不超过2小时。
目的：
总结这一个迭代中的经验和问题；
找出后续潜在改进的主要方面，同时加以排序；
制定改进工作计划。
十、敏捷-仆人式领导
定义：
一种为团队赋权的方法。通过对团队服务来领导团队 的实践，注重理解和关注团队成员的需要和发展，旨在使团队尽可能达到最高绩效。
作用：
促进团队发现和定义敏捷。仆人式领导实践并传播敏捷。
十一、敏捷-待办事项列表
待办事项列表是所有工作的有序列表，它以故事形式呈现给团队。价值越大的排在上面。
产品负责人制作一个产品路线图，以显示预期的可交付成果序列。产品负责人根据团队的实际成果重新规划路线图。
产品负责人在迭代中的会议中与团队合作，为即将进行的迭代准备故事，细化足够的故事。
向团队介绍故事创意、潜在的挑战或问题。
十二、SCRUM的三个物件-冲刺列表
定义了冲刺的目标，明确了冲刺过程中具体需要完成的任务；
尽量放在方便团队看到的地方；
任务不是分配下去的，而是团队讨论与个人挑选的结果；
对每一个任务，每天更新剩余任务工作量的估算；
Sprint 计划会议产出其实Sprint Backlog；
是团队的资产，团队可以增加、删除或者修改任务；
如果团队同意，对于一些事项，可以先做大的整体估算。
十三、敏捷项目章程
敏捷项目也是有项目章程的。
项目章程是重要的管理文件，需要所有干系人的参与。
虽然专家建议章程应不超过一页，但是因为所有的干系人必须参与进来并且达成一致意见，所以创建项目章程是非常具有挑战性的。
敏捷项目章程中应包含3个关键信息：愿景，任务和成功标准。
十四、敏捷项目范围管理
敏捷项目管理中的范围管理，大概是这样：每次迭代开始之前，由PO和团队开一个迭代规划会，从产品待办列表至上而下切出来优先级最高的内容，作为当前迭代的内容。确定之后，需求锁定。
每个迭代的版本要实现的需求，是由PO来决定。决策的依据是投资回报率，优先做最有价值的需求。
十五、敏捷项目进度管理
敏捷中，故事地图本质上等同于项目计划，它将用户故事，产品特性按逻辑主题排列，作为开发的计划。
敏捷项目一般是采用看板来展示进度，用看板作为信息发射源。如果团队成员要了解进度，看公开出来的看板即可。
十六、敏捷项目成本管理
敏捷中，成本管理的内容较少。
记得有一个敏捷估算，估算故事点的大小。这种一般都是轻量级的估算，不会估算的特别精细，因为敏捷的需求变化很快，没有必要花太多时间进行精细化估算。
十七、敏捷项目质量管理
敏捷项目中，质量管理主要体现在每日站会，迭代产品评审会和回顾反思会。
1）团队每天开每日站会，可以暴露问题，防止成员摸鱼，Scrum Master可以及时协助团队处理障碍，保障项目质量和进度。
2）迭代评审会，由PO和团队一起开，主要审查做出来的产品是否满足客户的需要，如果不符合，将由PO修改用户故事，并放到产品待办列表，重新排需求优先级，纳入下一个迭代。
3）回顾反思会，团队总结经验教训，哪些做的好的，哪些做的不好的，识别出问题，在后续的迭代中加以优化改进。
十八、敏捷项目资源管理
敏捷项目管理的team人员比较固定，一般3到9人。
十九、敏捷项目风险管理
敏捷的节奏性和迭代性使其非常适合于管理产品开发和相关项目中常见的各种风险。敏捷实践带来的好处和价值不容置疑，如何正确的将风险管理纳入敏捷项目管理中，是非常重要的。敏捷模式下对传统的风险识别方法是个非常大的挑战。
最简单的办法就是：有不满足要求的可交付成果，纳入未完项，由PO重新排优先级，下一个版本迭代。
二十、敏捷项目沟通/相关方管理/采购管理
1、项目沟通管理
是为了确保项目信息合理收集和传输，以及最终处理所需实施的一系列过程。如何进行有效的沟通是很多人思考的问题。主要知识点：制定敏捷的沟通矩阵、建立项目信息门户等。
2、相关方管理
相关方是指影响项目或者受项目影响的全部人员，群体或组织。一般涉及人员有：项目经理、顾客/客户、执行组织、发起者。
3、采购管理
敏捷采购是快速削减成本的立竿见影之法，任何有需求的企业都不妨一试。
二十一、精益,敏捷相关的名词/概念
1、WIP 在制品限制
work in process，是指材料或部分已开始生产但是还未完成的产品，也就是半成品。
2、看板 ，kanban ,kanken，板
看板是丰田公司在19世纪40-50年代开发的一个及时（JIT）生产调度系统。它是通过卡片或者信号来请求（需求信号）其他独立系统中（供应方）生产流程的必须部分，以此控制和减少库存。看板已被应用于敏捷中，来帮助控制工作流。他可以帮助团队意识到他们是如何工作以及下一步要做什么，让团队形成自我指挥。
3、XP极限编程
极限编程(XP)是一项以编程人员为中心的敏捷架构，注重小而迅速的发布。XP极限编程强调以下原则：结对编程 可持续速度 不断自动测试 有效沟通 简单性 反馈 勇气 集体所有 持续集成 激励工作 共享工作空间 现场客户代表 使用隐喻说明概念。
XP极限编程用语中“caves和common”指的是，为团队成员创造的两个分区。common是一个公共的空间，在此常有渗透沟通和协作。caves是一个私人的交易预留空间，需要一个孤立且安静的环境。
4、计划扑克
计划扑克是基于宽带德尔菲估算技能、是以共识为基础的工作量估算技能。有时候也称为敏捷扑克，往往在故事点和开发用户故事中用来估算相对工作量。
在计划扑克会议中，每一位成员各持有一副相同价值的计划扑克卡片。
计划扑克会议按如下的步骤运行：
1）一名调停人，主持会议，不参与估算。
2）产品负责人对用户故事做概述，并回答开发者提出的澄清问题，往往产品负责人不参与投票。
3）每一位成员抽取一张卡片来估算工作量。
4）每人抽取一张卡片后，同时将他们的卡片翻转，
5）持高和低估算的成员各有一次辩护机会。
6）达成共识前，不断重复以上流程。
5、用户故事：
用户故事：User Strory，它是这样来描述需求的：身为某一个角色，为了什么价值，需要什么功能。
用户故事三要素：角色，动机，价值。
举例：作为一个60后的微信用户，为了高效地完成信息交流，需要一个语音聊天的功能。这就是用户故事来描述用户需求的方法。
用户故事开发时长：开发一个用户故事的理想持续时长是2-5天。
用户故事3C：卡片card，对话communication，确认confirm. (罗恩•杰弗里斯提出的)
6、亲和估算
亲和估算是预测工作量的一个方法，基本的亲和估算模式涉及从小到大范围测量用户故事。这个范围可以是斐波那契数列或者T-shirt尺码，常常贴在大型会议室墙上。然后参与者在估算时可将他们的用户故事贴到这面墙上。
7、优先级排序技术 MoScow
MoSCoW技术通常用在敏捷项目中，主要用来对用户故事进行优先级排列：
M-must have必须有；//完成业务需要/价值所必须的功能，合规，安全等，没有要丢命。
S-should have应该有；//不涉及核心功能，但是严重影响用户体验，没有要丢钱。
C-could have可能有；// 影响不大，忽略也没有问题，没有可能会丢脸
W-won't have this time这次不会有；// 团队决定本次迭代不予实现，丢来没事。
8、价值流程图：
价值流程图就是用来寻找增值和非增值的工作，从而识别关键改进区域。价值流程图是敏捷采用的精益生产分析技能，用于对形成客户产品或服务的原料和信息（即价值）的流动进行分析。
执行价值流程图大致包括5个步骤：
1）确认产品，客户和范围（即流程的始末）。
2）确认流程步骤，延时和信息需求。估算流程步骤的持续时长和前置期持续时长（lead time duration）。前置期是指在发生前一项流程或者事件需等待的时长。
3）分析价值流程图来确认浪费存在的地方（比如前置期）和流程可完善的地方（流程时间通常认为是价值增加时间，但是应尽量减少整个流程的时间，由此来缩短向客户交付价值流的时间）。
4）通过分析，总结出一份展示价值流应努力达到的前景或者目标的未来价值流程图。
5）通过流程完善活动（即完善）或者其他方法来达到目标的一些工作。
9、解聚
将史诗故事或大型故事分解成小型用户故事。解聚类似于传统项目的分解。
（史诗是大型故事的意思，实现的时候，要进行分解，分解的过程就是解聚）
10、迭代速度的计算
题目：在上一次迭代中，Paula和她的敏捷团队完成了10个各值1个点的用户故事，2个各值5个点用户故事，还有1个值5个点的用户故事即将完成。请问该团队在之前的迭代中的速度是<20>。
10×1+2×5=20.部分完成故事的故事点不包括在速度指标里。
11、教练指导
敏捷里面提供教练式指导，让富有动力的团队运作更流畅，生产效率高，表现超越期望值。
可提高动力的简单步骤包括：
1）共度黄金时间，团队成员可在个人层面上了解他人以此营造轻松氛围，
2）提供反馈，指导和训练，赞扬和感谢团队成员的出色工作，同时为技能和能力提升提供指导和训练，
3）授权，授权团队成员作关键决策，在此期间，建立信任并显示领导对团队能力的信任。
12、燃尽图
项目的燃尽图是一个常用来展示迭代进度的信息发射源。它记录两项序列，横轴是时间，纵轴是剩余的实际工作和剩余的理想/预估的工作。
13、燃起图
与燃尽图相反，它的横轴是时间，纵轴是已完成的实际工作和剩余的理想/预估的工作。
14、累积流量图
展示用户故事的未完项、过程中的工作及完成功能与时间关系的一种图表，是信息发射源的组成部分。
15、概念性和感知性
精益软件开发架构中存在的两种完整性类型有：概念性的和感知性的。
概念上的完整性是由开发者决定的，如果产品集成良好和功能详细，那么完整性会非常高。
感知上的完整性是由客户观察得出的，如果客户最初对产品满意，然后产品满足需求，那么完整性会很高。
16、FDD
FDD(Feature-Driven Development，特性驱动开发)由Peter Coad、Jeff de Luca 、Eric Lefebvre共同开发，是一套针对中小型软件开发项目的开发模式。此外，FDD是一个模型驱动的快速迭代开发过程，它强调的是简化、实用、 易于被开发团队接受，适用于需求经常变动的项目。
17.Crystal Methods
Crystal Methods（水晶方法族）由Alistair Cockburn在20实际90年代末提出。之所以是个系列，是因为他相信不同类型的项目需要不同的方法。虽然水晶系列不如XP那样的产出效率，但会有更多的人能够接受并遵循它。
18.DSDM
DSDM（动态系统开发方法）是众多敏捷开发方法中的一种，它倡导以业务为核心，快速而有效地进行系统开发。实践证明DSDM是成功的敏捷开发方法之一。在英国，由于其在各种规模的软件组织中的成功，它已成为应用最为广泛的快速应用开发方法。
DSDM不但遵循了敏捷方法的原理，而且也适合那些成熟的传统开发方法有坚实基础的软件组织。
19.ASD
ASD(Adaptive Software Development，自适应软件开发)由Jim Highsmith在1999年正式提出。ASD强调开发方法的适应性（Adaptive），这一思想来源于复杂系统的混沌理论。ASD不象其他方法那样 有很多具体的实践做法，它更侧重为ASD的重要性提供最根本的基础，并从更高的组织和管理层次来阐述开发方法为什么要具备适应性。
20.轻量型RUP
RUP其实是个过程的框架，它可以包容许多不同类型的过程， Craig Larman 极力主张以敏捷型方式来使用RUP。
他的观点是:目前如此众多的努力以推进敏捷型方法，只不过是在接受能被视为RUP 的主流OO开发方法而已。
- 上一篇：如何系统的学习项目管理？给你捋出来了
- 下一篇：PMP®考试答题方法汇总,精髓归纳
