PMP敏捷项目管理冲刺：Scrum、看板与混合方法核心考点梳理

备考PMP的朋友都知道，2021年考纲改革后，敏捷和混合型内容占到了约50%的比例，这已经不是“选做题”了，而是决定你过与不过的半壁江山。很多人在传统项目管理部分刷题刷得飞起，一到敏捷题就凭感觉选，结果成绩单上“Below Target”的区域往往就是敏捷相关领域。这篇内容专门针对考前冲刺阶段，把PMP敏捷项目管理部分的考点做一个高密度梳理，不聊虚的，全是考试直接能用的东西。

我个人当年备考的经验是：敏捷部分想拿高分，关键不是背了多少工具，而是完成一次思维上的切换。传统项目经理习惯“先计划、再执行、严格控制变更”，敏捷项目经理想的是“快速交付、收集反馈、拥抱变更”。这种思维惯性如果转不过来，题目换个场景你照样错。所以这篇冲刺内容，我会先带你完成认知层面的纠偏，再把必考的框架、工具、方法逐一拆开，最后给出一套应对选择题的实战法则。

1. 先转变思维：敏捷和预测型的本质差异

很多考生在敏捷题上栽跟头，根本原因不是知识盲区，而是大脑还停留在瀑布思维里。比如题干描述“项目开发过程中，客户提出了一项对现有系统影响较小的新需求”，敏捷思维下的正确做法是把它加入待办事项列表并按优先级排序，而预测型思维会下意识选择“走变更管理流程”或“评估影响后拒绝”。这就是PMP敏捷题最常见的失分点。新考纲下题目本身并不难，难的是你能否放下旧思维的惯性。

1.1 项目生命周期怎么选：预测型、敏捷还是混合

考试中常见的题干背景是项目经理需要根据项目特点选择合适的生命周期。判断标准并不复杂，记住三个维度就够了：需求确定性、交付频率、变更成本。

• 需求明确、变更少、交付物可以一次性定义清楚，选预测型。比如建筑工程、大型设备制造这类项目，早期需求变更的成本极高，必须靠详细计划和合同约束。
• 需求存在不确定性、客户希望尽早看到部分成果、小步迭代快速响应市场变化，选敏捷型。比如软件开发、产品设计、营销活动这类项目，边做边调是常态。
• 项目整体需要前期合规审批和整体规划、但具体交付团队希望保持灵活性，选混合型。比如带监管要求的金融系统升级，外部边界必须按阶段把关，内部开发则采用迭代方式推进。

考试时题干中如果出现“需求可能频繁变更”“客户希望尽快看到可行性成果”“团队规模小而紧密”等信息，优先考虑敏捷或混合。出现“合同已明确所有范围”“法规要求严格的阶段审批”“一次性交付才能验收”则倾向预测型。

提示：不要把“敏捷”和“没有计划”画等号。敏捷同样有计划，只是计划分层且滚动更新——产品路线图定大方向，迭代计划只规划当前冲刺的内容。考试中如果选项出现“敏捷不需要计划”或“敏捷可以不遵守流程”，基本可以立刻排除。

1.2 敏捷四大宣言与十二原则：考试核心中的核心

敏捷宣言的四个价值对是选择题的“题眼”，几乎每次考试都会以变换场景的方式出现。

注意“高于”不代表“不要”，而是“更有价值”的意思。考试时经常会在选项里设置极端表述，例如“敏捷项目不需要任何文档”“为了响应变化可以完全放弃计划”，这类选项都是错的。敏捷追求的是“适度文档”“有原则地调整计划”。

十二原则中考试频率较高的有：客户满意度通过早期和持续交付有价值成果来实现；欢迎需求变化，并利用变化为客户创造竞争优势；频繁交付可工作的产品（几周或几个月，倾向于更短周期）；业务人员和开发人员在整个项目中每天在一起工作；项目是围绕有动力的个体建立的，给予他们所需的环境和支持，并信任他们完成工作；向团队传达信息最有效的方法是面对面交谈；可工作的产品是衡量进度的主要标准；可持续的开发节奏；持续关注技术卓越和良好设计；简单化是必不可少的；最好的架构、需求和设计来自自组织团队；团队定期反思如何更有效，并调整行为。

考试不会直接问“敏捷十二原则是什么”，而是给一个具体场景，让你判断哪项做法符合原则。核心就把握一点：凡是体现“快速交付、持续反馈、客户协作、团队自组织、拥抱变化”的选项，大概率是正确方向。

1.3 敏捷需求怎么管：用户故事拆解与优先级排序

几乎所有敏捷项目都以用户故事（User Story）为需求表达载体。用户故事本身不是一个完整的需求文档，而是一张“备忘卡片”，用来触发团队讨论。标准句式很简单：作为（角色），我想要（功能），以便（价值）。例如：“作为在线商店的顾客，我想要按商品类别筛选搜索结果，以便更快找到心仪商品。”考试中常让考生判断哪个选项是一则规范的用户故事，核心就看是否同时覆盖了角色、功能、价值三要素，记账、立项批复都不属于用户故事的组成部分。

用户故事有了之后，排优先级常用的技巧有两类。MoSCoW法把需求分为Must、Should、Could、Won't四个等级，Must是本次发布缺了就跑不动流程的功能，Should值得做但可以等，Could是锦上添花，Won't是这轮明确不做。Kano模型则从客户满意度角度分类：基本型需求做了不会提升满意度但不做一定会抱怨，期望型需求与满意度正相关，兴奋型需求不做不扣分做了会惊喜。考法往往是给一个需求判断优先级，或问“当迭代容量不足时应该先砍掉哪类需求”，记住“Won't先砍、基本型必须保障”就能应对。

2. 核心框架：Scrum 3355 全解

Scrum是PMP敏捷部分占篇幅最大的框架，考试中对Scrum的考查占敏捷类题目的70%以上，属于必须要吃透的内容。备考圈流行一个口诀——“3355”，对应3个角色、3个工件、5个事件、5个价值观。把这个框架彻底弄清楚，敏捷题基本就能拿下一半分数。

2.1 三个角色：PO、SM、开发团队各管什么

Scrum中有且仅有三个角色，考试里经常出现“项目经理想介入某个角色职责”的场景，判断标准就是看职责边界。

• 产品负责人（Product Owner）：唯一的责任人，负责“做什么、先做什么、不做什么”，管理产品待办列表的内容与优先级排序。PO可以接受或拒绝交付成果，但不能替开发团队估时。高频考点：PO有权取消冲刺（Sprint），但必须尊重团队已完成的成果。
• Scrum Master：服务型领导，负责“流程怎么走、障碍怎么清、规则怎么守”，确保团队正确理解和执行Scrum规则，移除团队面临的组织层障碍，推动团队成员内部的协作与自组织能力。高频考点：SM是教练，不是团队经理，无权给开发团队分配具体任务或决定发布日期。
• 开发团队：跨职能的成员集合体，负责“怎么做、做多少”，自行拆分任务、估算工时、组织实现方式。开发团队自组织、跨职能，没有子团队或固定角色标签。高频考点：团队成员没有固定头衔，比如测试人员也属于开发团队整体，大家共同对交付负责。

考试中常见的踩坑选项包括：“SM为团队确定冲刺目标”“PO评估每个用户故事的工时”“开发团队成员向SM汇报工作”“项目经理直接领导敏捷团队并分配任务”。这些全部错误。敏捷团队强调自组织，PM的职责转变为消除障碍和提供支持。

注意：敏捷项目里还有一个容易混淆的角色——敏捷教练（Agile Coach）。它与SM有些重叠，但也有区别。SM聚焦Scrum流程的严格执行，敏捷教练则更侧重于组织整体敏捷转型和文化建设。考试中如果出现“帮助组织推广敏捷实践、培训多个团队”，通常指敏捷教练。如果题目描述针对单个Scrum团队内部流程改进，优先选SM。

2.2 三个工件：从待办列表到可交付增量

Scrum的三大工件是产品待办列表（Product Backlog）、冲刺待办列表（Sprint Backlog）、增量（Increment）。

产品待办列表是从项目启动一直贯穿到收尾的动态化清单，包含所有可能的功能需求、缺陷修复、技术改进和知识获取，由PO负责维护，所有条目按优先级排序。高频考点：产品待办列表中的条目应当是细化的、估算过的、优先级明确的，是否细化到“可以放进即将开始的冲刺”要视具体情况而定，因为长期条目允许保持粗粒度。

冲刺待办列表是当前冲刺范围内的目标，包含该冲刺要实现的待办项和为完成这些项目开发团队自行拆解的任务列表，由团队在冲刺规划会议中共同制定。高频考点：冲刺待办列表属于团队内部，随时可以动态调整——只要不影响冲刺目标达成，团队成员可以自行增删调整任务。

增量是冲刺结束时交付的可工作、可验收的功能总和，必须符合团队定义的完成标准（DoD）。高频考点：“增量”必须是可工作的、可使用的；“部分完成”的功能不能被算作增量。考试中如果选项说“增量仅指新开发的功能，不包含既有功能的优化或缺陷修复”，则是错误说法。

PMP考试很喜欢让考生区分这三大工件的核心差异：产品待办列表关注“全部需求的优先级”，冲刺待办列表关注“本次冲刺团队要做的任务”，增量关注“本次冲刺真正做完了什么”。紧扣这三个方向就能判断正误。

2.3 五个事件：节奏感与仪式感的来源

Scrum的五个事件构建了项目的固定迭代节奏。冲刺本身包含四个会议事件，外加冲刺规划形成闭环，整体是“规划—执行—验收—反思”的循环。

冲刺规划会议的参加者是全体Scrum团队，目的是确定这个冲刺要交付什么、如何交付，输出一份冲刺待办列表和明确的冲刺目标。时长一般按冲刺长度按比例确定，例如两周冲刺规划会议控制在两小时以内。高频考点：冲刺规划会议需要PO参加，因为团队需要PO现场澄清范围和优先级。选项中出现“SM独自制定冲刺目标”或“团队成员不参加规划会，由PO代劳”均错误。

每日站会是开发团队每天进行的同步活动，时间严格限制15分钟以内，三个标准问题是：昨天我做了什么、今天我打算做什么、有什么障碍阻挡我。站会的目的是检视当前进度、暴露风险，不解决深层次问题。高频考点：需要解决的问题在会后由相关人员单独讨论，SM负责记录障碍并协调解决。选项中出现“利用站会解决技术难题”“PO在站会中分配任务”都是错的。

冲刺评审会议在冲刺结束时进行，团队向PO及利益相关者演示可工作的增量成果、收集反馈并更新产品待办列表。评审的目标是“检验增量是否符合需求，决定下一步做什么”。高频考点：评审不是验收会，不是审批会，是一种协作式的反馈仪式——多选题里“只要能工作的软件都不算完整增量”这个判定标准其实是在考DoD，与评审是两个层面，注意区分。

冲刺回顾会议是整个Scrum循环中我个人认为最容易被考生忽视、但在考试中反复出现的点。它与评审不同，评审针对产品增量，回顾针对团队协作过程的改进。回顾的目标不是追究责任，而是识别哪些做得好、哪些需要改进，并确定一个具体的流程改善行动在下一个冲刺落地。高频考点：回顾是Scrum中“检视与适应”的集中体现，错误选项往往把“把回顾当作绩效评估会”“只讨论产品功能问题”设为陷阱。

五事件易混淆题最容易错在区分“评审”和“回顾”上。冲刺评审面向产品与干系人，关注“我们做对了什么产品”；冲刺回顾面向团队内部，关注“我们协作得好不好”。选择题题干里出现“客户”“干系人”“演示”“反馈”，就是评审；出现“团队内部”“流程改进”“做得好的地方”“需要改进的地方”，就是回顾。

2.4 五个价值观：承诺、专注、开放、尊重、勇气

Scrum的五个价值观常以概念题形式出现，有时候会结合场景让考生判断体现的是哪个价值观。

• 承诺：团队承诺达成冲刺目标，个人承诺完成任务。
• 专注：团队专注于冲刺目标，不被其他事项分散精力。
• 开放：团队对工作进展、困难、风险保持透明。
• 尊重：成员之间尊重彼此的专业能力和差异。
• 勇气：有勇气说出真相、承认错误、挑战不合理要求。

考试中容易出现干扰项，比如把“遵守流程”包装为价值观。记法很简单：价值观不是约束而是行为倾向，凡是“主动沟通、真诚表达、不怕冲突、坚持已见但尊重他人”一类的选项，都对应开放或勇气。凡是“言出必行、全力投入、聚焦优先级”一类，对应承诺或专注。

3. 敏捷估算与规划：考试必会的核心方法

预估和规划是PMP敏捷部分的重点，也是很多考生的丢分重灾区。传统项目喜欢用小时数做精确估算，敏捷项目强调相对估算和团队共识，因为需求本身存在不确定性，过早追求精确意义不大。

3.1 用户故事与完成定义：DoD 是“做完”的唯一标准

用户故事是敏捷需求表达的最小单元，但用户故事本身不包含验收标准，验收标准由团队自行约定。这里必须区分两个概念：

• 就绪定义（Definition of Ready）：一个用户故事可以被团队接纳进入冲刺规划的前提条件。例如“故事已明确、有验收标准、有独立可估算的价值、足够小到能在单次冲刺内完成”。DoR属于“进入冲刺前”的门槛，通常由团队与PO共同确定。
• 完成定义（Definition of Done）：一个用户故事或增量被正式视为“完成”需要满足的质量检查清单。例如“代码已编写并通过单元测试”“通过代码评审”“完成用户界面联调”“已更新用户手册”“通过产品负责人的功能验收”。DoD属于“做完”的硬指标，且不同团队可以有不同的DoD，一旦确定就应一致执行。

考试中经常出现“什么时候可以把一个用户故事标记为完成”一类问题。正确方向永远是看该故事是否满足团队定义的DoD，而不只是“功能实现了”或者“开发说可以了”。选项中如果出现“客户已确认满意”可能与DoD有关但也可能超出范围，需要谨慎判断，因为客户验收一般是发布条件，不完全取决于验收标准本身。

需要留心的是，同一团队的不同故事可能共享同一DoD，但不同团队之间DoD可以不同，这不算违规。如果考试问“以下哪个关于DoD的说法是正确的”，通常会有一个选项写“完成定义由团队自己定义，且应被团队一致认可以保证透明度”，这个大概率是正确的。

3.2 敏捷估算技术：扑克牌、T恤尺码与亲和估算

敏捷估算的主流方法有三种，考试中出现频率依次为：计划扑克、T恤尺码估算、亲和估算。计划扑克采用斐波那契数列（1、2、3、5、8、13、21……）进行相对估算。估算时先给每个故事单独打分，一轮结束后如果偏差大，重点听取最大和最小估算者的理由，再重新打分直至收敛。PMP考试经常考的是它如何体现“团队共识”：所有成员同时出牌、不能相互商量后报数、有争议时讨论后重新出牌。

T恤尺码估算不做精确数字，而是用S/M/L/XL的颗粒度来排序。考试中通常在早期需求不明确、或团队希望快速完成粗略规模评估时使用。亲和估算的核心是“把故事按相对大小分组贴到墙上”，适合大量故事需要快速分类排序的场景，精度要求不高但速度快。

还有一个必须掌握的概念：估算故事点。故事点是一个相对单位，代表用户故事的复杂度和工作量，不等于人天或小时。考试中如果题干提到“团队每个冲刺完成30个故事点”，这个词本身不是工具的选项，但会用来描述团队速率（Velocity），题目往往需要基于速率反推一个冲刺能装下多少故事点，从而判断哪些需求能进入这个冲刺。

3.3 速率、燃尽图与燃起图：进度追踪的三种手段

速率是团队在一个冲刺中实际完成的“已验收”故事点总和，只能通过历史数据得出，不能提前承诺。考试中常见的考法是：根据前两三个冲刺的速率平均值，预测未来冲刺可交付的需求量。例如团队最近三个冲刺完成的故事点分别为28、32、30，平均值30，那么接下来一个冲刺计划30个故事点比较合理。选项中如果说“直接按团队宣称的能力确定速率”“依据每个开发人员个人能力加总”，都是错误理解。

燃尽图（Burn-down Chart）展示的是“一个冲刺内剩余工作量随时间的变化”。横轴是冲刺天数，纵轴是剩余工作量（故事点或任务小时），理想情况下曲线从左上角向右下角平滑下降。如果曲线在冲刺中途出现上升，说明有新工作被加入或发现原先低估了工作。燃起图（Burn-up Chart）展示“累积已完成工作量随时间的变化”，同时画一条目标线，直观看到目前离冲刺目标还差多少。

考试中如果问“冲刺已过半，但剩余工作量高于预期，下一步该怎么办”，正确方向一般是“与团队一起分析原因、调整范围或重新协商冲刺目标、向PO反馈”。错误选项往往是“立即加班赶工”“要求团队加快速度、不做分析”。记住一条敏捷铁律：数据不是用来施压的，而是用来暴露问题并触发调整的。

3.4 发布规划与迭代规划：长期与短期的平衡

敏捷计划体系是分层级的，考试常见的是把发布规划与迭代规划做对比。发布规划站在更高维度，覆盖未来多个冲刺，估算颗粒度较粗，用来给干系人一个预期：哪些功能会在哪个版本或哪个时间窗口出现，基于当前速率预测大致节奏。迭代规划则聚焦当前冲刺，细化到具体任务、小时数或故事点，是团队在冲刺规划会议上完成的工作。

发布规划的一个重要输出是“按优先级排列的目标版本”，它不建议精确到具体日期，因为不确定性较高。考试中题干如果问“项目发起人想知道系统正式上线的时间应该参考什么”，一般答“发布规划”而不是“冲刺计划”。题干描述“团队正在细化下一冲刺的每日任务、明确每个人的工作内容”，则属于冲刺规划。

一个很容易错的点：发布规划调整不等于迭代目标可以随意改。迭代目标在一轮冲刺内相对稳定，一旦团队做出了承诺，就应尽力完成。发布规划和路线图都是可以随市场变化和反馈动态调整的，尤其需求变更时，优先调整产品待办列表和发布的版本范围，这是敏捷的核心机制。

4. 看板方法：另一个高频考点框架

看板方法在PMP考试中的比重逐年上升。与Scrum固定迭代节奏不同，看板采用的是连续流：工作项持续流入看板，团队按能力拉取新任务，而不是等某个“冲刺”开始才启动。

4.1 看板核心实践：可视化工作流与在制品限制

看板最核心的实践包括：可视化工作流、限制在制品数量（WIP Limit）、管理流动、明确过程策略、持续改进。

可视化工作流是看板的基础：把工作流分列为“待办”“进行中”“测试中”“已完成”等列，每项工作用一张卡片表示，所有状态一目了然。

限制在制品数量是另一个关键考点。在制品的英文缩写是WIP，团队规定某列最多只能同时进行X项工作，目的是防止多任务切换造成效率下降。考试中的经典考法是给一个场景：看板中“编码中”列已经有3项任务，还有一项新任务完成分析了，但团队只有4个人，此时按看板原则应“先完成已有任务，等出现空位再接新任务”，而不是“立刻拉入新任务一起推进”。这个原则和很多人的直觉相反，一定要在考场上提醒自己。

看板同时高度强调“管理流动”和“持续改进”。如果某列积压的任务越来越多，持Scrum思维的人可能会说“增加人手”，而看板思维的第一反射是“先找出瓶颈环节、解决流动受阻的根因”。考题中选项如果提到“增加在制品限制”通常是在反方向设置干扰项，因为限制WIP是降低浪费、促进流动的手段，真正应对瓶颈的方式是识别并缓解瓶颈。

4.2 看板与Scrum全方位对比：记住差异才能做对题

考试最喜欢的出题点是“看板与Scrum的区别”，这里整理一套对比表，考前反复看一遍可以有效防混。

考试的经典场景是：“项目团队希望保持敏捷原则且减少会议频率、让工作以连续流动的方式进行”，正确答案通常是看板。而“团队明确需要周期性交付演示、且希望每个周期结尾有反思机制”，则适合Scrum。只掌握“两者核心差异在固定节奏 vs 连续流”就足以应对大部分题。

5. 混合方法与实践要点：别被新词吓到

新考纲中的混合型生命周期在某些考题中比重不低，但难度不大。所谓的混合型，就是同时包含预测型与敏捷型的要素。常见情境一是项目前端有合同谈判、预算审批等必须用预测型流程的阶段，一旦进入开发时期则采用Scrum迭代；二是外部服务商或供应商有自己独立的交付节奏，内部团队跟着整合即可；三是法规要求某些文档完整归档，但功能开发用迭代方式推进。

考试中判断“什么情况下选用混合生命周期”并不复杂：只要题干体现“一部分工作必须严格走阶段审批、另一部分需要快速迭代响应需求”，就是混合型。此时项目经理的做法一般是：保持整体按阶段关口推进，但在可独立的子系统内允许团队使用敏捷实践；文档流程按组织规定执行，但不该为此牺牲开发团队的协作效率。

另外，PMP敏捷部分常考的实践还有极限编程（XP）的核心实践——结对编程、测试驱动开发、持续集成、小批量发布、编码规范。考试题目如果你看到“两个开发人员在同一台电脑上共同编写代码”，那就是结对编程；看到“先写失败的测试，再写实现代码使其通过”，是测试驱动开发；看到“频繁集成代码到共享主线、并由自动化构建验证”，是持续集成。

6. 敏捷选择题的实战解题法则

冲刺阶段刷题不能盲目，做题时建议给自己规定一套固定动作。先看题目最后一句话问的是什么，这能避开大部分陷阱；然后识别题干中的过程域，属于角色职责、工件管理、事件目标还是工具应用；再判断思维模式，看题干是体现预测型还是敏捷场景，同时用敏捷思维去锁定正确答案方向。

具体来说，PMP敏捷题有几个非常顽固的出题规律：

• 遇到“团队成员抱怨会议太多”的场景，优先选项往往指向“减少非必要会议、让团队按需协作”或“每日站会时长按15分钟严格控制、保留评审和回顾这类高价值仪式”，不会建议你直接取消所有会议，因为仪式感对敏捷依旧重要。
• 遇到“PO提出冲刺中途加入紧急需求”时，先看这项需求是否影响当前冲刺目标。如果影响巨大，正确操作是将原冲刺目标取消或重规划，PO有权取消冲刺；如果不影响冲刺目标，则把这个故事排进后续冲刺的产品待办列表，不在本轮硬塞。
• 遇到“多个干系人意见不一致”时，优先建议让客户和PO最终拍板，并解释是否影响优先级排序，通常不是“项目经理开会投票解决”。
• 遇到“迭代结束但部分故事未完成”时，不要把未完成故事计入速率，更不能为了美观把它标成“已完成”。正确做法是把未完成项根据反馈重新估算后放回产品待办列表或顺延到下一冲刺，同时查明阻碍原因。
• 遇到“团队内部出现技术分歧”时，正确的敏捷做法是让团队自行讨论、利用结对或协作工具解决，而不是项目经理直接做技术决策。PM的角色是确保讨论有结论、障碍被移除，而不是充当专家裁判。

这些法则背后有一条贯穿始终的主线：敏捷选择题的正确选项，永远在强调团队自组织、透明沟通、持续反馈、拥抱变化这些价值观。当你在几个选项中犹豫不决时，就挑那个对协作和适应最友好的选项，多数情况下它都是对的。

最后分享一个我冲刺阶段反复验证过的小技巧：每天拿出40分钟，只做“划题干关键词+写出你认为该场景对应的敏捷事件/角色/工具”这种专项练习，不需要完整做整卷，一周下来敏捷题的题感就会有明显提升。刷题错题多不可怕，怕的是不分析；每次做错都复盘一下“我当时是拿什么思维在选”，这套纠偏动作比多刷200道题都管用。考试时真遇到不确定的题目，也先画关键词、排除绝对的预测型选项、再挑与敏捷价值观最匹配的那个，基本能把正确率稳定在85%以上。