在 PMP 考试中，敏捷相关内容占比已超过 50%。本章聚焦敏捷题型的核心考点，通过深度解析敏捷价值观、Scrum 框架、仆人式领导和敏捷度量等关键主题，帮助你准确把握敏捷思维在实际场景中的应用。我们将通过大量真题案例和 AI 模拟练习，让你在考试中快速识别敏捷题型的解题思路。
敏捷宣言的四大价值观是 PMP 考试的高频考点，理解其深层含义至关重要：
1. 个体和互动 高于 流程和工具
2. 工作的软件 高于 详尽的文档
3. 客户合作 高于 合同谈判
4. 响应变化 高于 遵循计划
关键理解要点：
价值观深度解析：
1. 个体和互动 高于 流程和工具
这一价值观强调人的因素是项目成功的关键。优秀的团队配合即使使用简单工具也能成功，而缺乏协作的团队即使有最好的工具也难以成功。
实践要点：
考试场景示例：
2. 工作的软件 高于 详尽的文档
强调可交付成果的实际价值，而非过程文档的完备性。文档应该”恰到好处”（just enough），服务于软件开发而非成为目的本身。
实践要点：
考试场景示例：
3. 客户合作 高于 合同谈判
将客户视为合作伙伴而非对手，共同为项目成功努力。合同是起点，但持续的合作关系更重要。
实践要点：
考试场景示例：
4. 响应变化 高于 遵循计划
认识到变化是不可避免的，拥抱变化而非抗拒。计划是重要的，但适应变化的能力更重要。
实践要点：
考试场景示例：
考试常通过场景题考察对敏捷原则的理解，以下是完整的十二条原则及其应用要点：
十二条敏捷原则详解：
理解敏捷思维与传统项目管理思维的差异是考试成功的关键。PMP 考试经常通过对比场景来考察候选人是否真正理解敏捷理念。
核心思维差异：
| 维度 | 传统思维（预测型） | 敏捷思维（适应型） |
|---|---|---|
| 计划方式 | 前期详细规划 | 持续规划，渐进明细 |
| 变更态度 | 控制和最小化变更 | 拥抱变更作为机会 |
| 文档要求 | 详尽的文档 | 恰到好处的文档 |
| 团队结构 | 层级式，职能分工 | 跨职能，自组织 |
| 客户参与 | 阶段性参与 | 持续深度参与 |
| 风险处理 | 预先识别和规避 | 快速失败，快速学习 |
| 质量保证 | 阶段性质量门 | 内建质量，持续测试 |
| 价值交付 | 项目结束时交付 | 持续交付价值 |
详细场景对比：
| 场景类型 | 传统思维 | 敏捷思维 | 考试提示 |
|---|---|---|---|
| 需求不明确 | 要求详细需求文档 | 快速原型，迭代细化 | 选择”开发原型” |
| 客户变更 | 走变更控制流程 | 评估后纳入 backlog | 选择”与 PO 讨论优先级” |
| 团队冲突 | 升级到管理层 | 团队自组织解决 | 选择”促进团队讨论” |
| 进度落后 | 加班赶工 | 调整范围，确保质量 | 选择”与 PO 协商范围” |
| 质量问题 | 加强测试 | 内建质量，持续改进 | 选择”回顾会分析根因” |
| 资源冲突 | 资源经理分配 | 团队协商解决 | 选择”团队决定” |
| 技术决策 | 架构师决定 | 团队集体决策 | 选择”团队评估选项” |
| 绩效评估 | 个人绩效考核 | 团队整体评估 | 选择”团队速度” |
| 沟通问题 | 加强文档和流程 | 增加面对面交流 | 选择”安排工作坊” |
| 范围蔓延 | 严格控制范围 | 评估价值后调整 | 选择”重新排序 backlog” |
思维转换要点：
例题 1：价值观应用
项目进行到第三个迭代，客户突然要求增加一个重要功能。团队评估后发现会影响当前迭代目标。项目经理应该：
A. 拒绝变更，维护迭代目标 B. 立即加入当前迭代 C. 与产品负责人讨论优先级，可能调整下个迭代计划 D. 要求客户提供详细需求文档
解析： 答案 C。体现”响应变化高于遵循计划”和”客户合作”的价值观。
例题 2：原则理解
敏捷团队完成了一个功能，但只实现了 60% 的原定需求。最佳做法是：
A. 延迟发布直到 100% 完成 B. 发布当前版本，收集反馈后迭代 C. 加班完成剩余 40% D. 降低质量标准以完成所有功能
解析： 答案 B。体现”尽早交付价值”和”迭代改进”原则。
Scrum 框架的事件管理是 PMP 考试的重点内容。理解每个事件的目的、时间盒、参与者和输出至关重要。考试经常通过场景题考察事件的正确顺序、参与规则和时间管理。
Sprint (冲刺)
├── Sprint Planning (冲刺计划会)
│ └── 时间盒：8小时（4周冲刺）
├── Daily Scrum (每日站会)
│ └── 时间盒：15分钟
├── Sprint Review (冲刺评审会)
│ └── 时间盒：4小时（4周冲刺）
└── Sprint Retrospective (冲刺回顾会)
└── 时间盒：3小时（4周冲刺）
时间盒计算公式：
时间盒管理原则：
常见时间盒问题：
| 问题场景 | 错误做法 | 正确做法 |
|---|---|---|
| Planning 超时 | 延长会议时间 | 时间盒内完成，必要时简化讨论 |
| Daily Scrum 冗长 | 详细讨论问题 | 15分钟同步，问题会后解决 |
| Review 准备不足 | 临时准备演示 | 提前准备，确保高效展示 |
| Retro 流于形式 | 缩短或跳过 | 保证充分时间深入反思 |
标准 Scrum 事件流程：
| Scrum 角色 | Sprint Planning | Daily Scrum | Sprint Review | Sprint Retrospective |
|---|---|---|---|---|
| Product Owner | 必须参加 | 可选 | 必须参加 | 必须参加 |
| Scrum Master | 必须参加 | 确保召开 | 必须参加 | 必须参加 |
| Dev Team | 必须参加 | 必须参加 | 必须参加 | 必须参加 |
| 相关方 | 不参加 | 不参加 | 受邀参加 | 不参加 |
陷阱 1：Review 和 Retrospective 顺序
陷阱 2：Daily Scrum 参与者
陷阱 3：Sprint 中途加入紧急任务
例题：事件顺序
Sprint 即将结束，以下事件的正确顺序是：
A. Retrospective → Review → Planning B. Review → Retrospective → Planning C. Planning → Review → Retrospective D. Review → Planning → Retrospective
解析： 答案 B。标准顺序是先对外展示（Review），再对内改进（Retrospective），最后规划下个 Sprint（Planning）。
仆人式领导是敏捷环境中的关键领导风格，Scrum Master 是典型代表：
核心行为模式：
| 情境 | 传统领导方式 | 仆人式领导方式 | PMP 考试倾向 |
|---|---|---|---|
| 团队遇到技术难题 | 直接给出解决方案 | 引导团队找到答案 | 选择”facilitate” |
| 团队成员冲突 | 裁决谁对谁错 | 促进双方对话 | 选择”mediate” |
| 进度落后 | 要求加班 | 帮助识别根因 | 选择”coach” |
| 外部干扰 | 传达压力给团队 | 保护团队专注 | 选择”shield” |
| 团队士气低落 | 批评或激励演讲 | 倾听并提供支持 | 选择”support” |
场景 1：团队自组织
开发团队在 Sprint Planning 中无法就任务分配达成一致。Scrum Master 应该：
A. 根据技能分配任务 B. 让 Product Owner 决定 C. 引导团队通过讨论达成共识 D. 推迟到下个 Sprint
解析： 答案 C。体现引导（facilitate）而非指挥。
场景 2：移除障碍
团队反馈测试环境经常不可用，影响工作。Scrum Master 首先应该：
A. 要求团队适应现状 B. 向管理层汇报问题 C. 与运维团队协调解决 D. 在 Retrospective 中讨论
解析： 答案 C。主动移除障碍是 SM 的核心职责。
场景 3：保护团队
Sprint 进行中，销售总监要求团队参加一个重要客户演示。Scrum Master 应该：
A. 立即安排团队参加 B. 与 PO 协商是否符合 Sprint 目标 C. 拒绝请求 D. 让团队投票决定
解析： 答案 B。保护团队的同时考虑业务价值。
促进能力
↑
引导 ← SM → 教练
↓
服务意识
关键能力要素：
- 引导（Facilitation）：帮助团队高效协作
- 教练（Coaching）：提升团队能力
- 指导（Mentoring）：分享经验知识
- 教学（Teaching）：传授敏捷实践
考试提示：
速度定义： 团队在一个 Sprint 中完成的故事点总和
计算公式： \(\text{Velocity} = \sum \text{Completed Story Points in Sprint}\)
平均速度： \(\text{Average Velocity} = \frac{\sum \text{Velocity of Past Sprints}}{n}\)
预测完成时间： \(\text{Sprints Remaining} = \frac{\text{Remaining Story Points}}{\text{Average Velocity}}\)
典型考题：
团队过去 3 个 Sprint 的速度分别为 21、25、23 点。Product Backlog 剩余 138 个故事点。预计还需要几个 Sprint？
计算：平均速度 = (21+25+23)/3 = 23 Sprint 数 = 138/23 = 6
理想燃尽线与实际燃尽线：
故事点
100|＼ 理想线
| ＼
75 | ＼_____ 实际线
| ＼ ＼
50 | ＼___＼
| ＼＼
25 | ＼＼___
| ＼
0 |________________＼___
Day1 Day5 Day10 Day15
解读要点：
- 实际线在理想线上方：进度落后
- 实际线在理想线下方：进度超前
- 实际线平坦：工作停滞
- 实际线上升：范围增加
燃尽图问题诊断：
| 图形特征 | 可能原因 | 建议对策 |
|---|---|---|
| 前期平缓 | 任务未分解/团队启动慢 | Daily Scrum 加强同步 |
| 中期停滞 | 遇到障碍/依赖问题 | Scrum Master 介入 |
| 后期陡降 | 赶工/质量风险 | Review 测试覆盖率 |
| 线条上升 | 范围蔓延 | 与 PO 确认范围 |
燃起图示例：
故事点
150| _____ 范围线
| ____/
100| ___/ _____ 完成线
| / ___/
50 |/__/
|
0 |________________
Sprint1 2 3 4
优势：
- 明确显示范围变化
- 区分进度问题和范围问题
- 更适合向相关方汇报
1. 周期时间（Cycle Time） \(\text{Cycle Time} = \text{完成时间} - \text{开始工作时间}\)
用途：预测单个工作项的交付时间
2. 前置时间（Lead Time） \(\text{Lead Time} = \text{交付时间} - \text{需求提出时间}\)
用途：衡量端到端的交付效率
3. 在制品（WIP）限制
4. 缺陷逃逸率 \(\text{Defect Escape Rate} = \frac{\text{生产环境发现的缺陷}}{\text{总缺陷数}} \times 100\%\)
目标：< 5%
5. 团队幸福指数
例题 1：选择合适指标
产品负责人想了解团队的交付能力以规划发布。应该关注：
A. 个人生产率 B. 代码行数 C. 团队速度 D. 加班时间
解析： 答案 C。速度是预测交付能力的最佳指标。
例题 2：燃尽图解读
Sprint 第 5 天，燃尽图显示实际线明显高于理想线。Scrum Master 应该：
A. 要求团队加班 B. 在 Daily Scrum 中了解障碍 C. 削减 Sprint 范围 D. 等到 Sprint Review 再处理
解析： 答案 B。先了解问题，不要急于采取行动。
例题 3：度量改进
团队发现过去 3 个 Sprint 的速度波动很大（15、35、20）。最可能的原因是：
A. 团队能力不稳定 B. 故事点估算不一致 C. Sprint 长度不同 D. 团队成员变动
解析： 答案 B。大幅波动通常indicates估算标准不一致。
常见度量反模式：
使用 AI 工具进行敏捷教练场景模拟，可以大幅提升实战能力。以下是推荐的 prompt 模板：
基础设置 Prompt：
你是一位经验丰富的敏捷教练，我是准备 PMP 考试的学员。
请模拟真实的敏捷项目场景，给我提供需要解决的问题。
每个场景后，请等待我的回答，然后：
1. 评估我的答案是否符合敏捷原则
2. 指出可能的 PMP 考试陷阱
3. 提供标准答案和解释
场景 1：团队冲突处理
AI Prompt:
生成一个 Scrum 团队内部冲突的场景，涉及：
- 开发人员对 PO 优先级的质疑
- 技术债务vs新功能的权衡
- 时间压力下的质量担忧
要求我以 Scrum Master 身份处理
场景 2：相关方管理
AI Prompt:
创建一个场景，其中：
- 高层管理要求固定范围和时间
- 客户期望持续看到进展
- 团队倡导敏捷方法
要求我提供沟通策略
场景 3：度量指标解释
AI Prompt:
给我一组 Sprint 数据：
- 3个 Sprint 的速度值
- 燃尽图数据点
- 缺陷统计
要求我分析问题并提出改进建议
批量生成 Prompt：
生成 10 道 PMP 敏捷相关选择题，要求：
1. 覆盖敏捷宣言、Scrum 框架、看板、极限编程
2. 每题包含一个实际场景
3. 4 个选项，其中 2 个是常见误区
4. 提供答案和详细解析
5. 标注考察的知识点
个性化训练 Prompt：
我在以下方面容易出错：
- 混淆 Scrum 事件的参与者
- 不清楚 SM 和 PO 的职责边界
- 计算题容易出错
请针对这些弱项：
1. 生成专项练习题
2. 提供记忆技巧
3. 创建对比表格
面试模拟 Prompt：
模拟 PMP 考试的情景判断题面试：
1. 描述一个复杂的项目情况
2. 我需要选择最佳行动方案
3. 追问我的选择理由
4. 指出其他选项的问题
5. 关联到 PMP 知识体系
快速复习 Prompt：
用一问一答的方式帮我快速复习：
- Scrum 的 3-3-5-5 框架
- 敏捷估算技术对比
- 仆人式领导 vs 命令控制
- 敏捷合同类型
每个问题等待我回答后再给出正确答案
本章深入探讨了 PMP 考试中的敏捷题型特点和解题策略：
错误： Scrum Master 分配任务给团队成员 正确： 团队自组织决定任务分配
错误： Product Owner 参与估算故事点 正确： 只有 Development Team 进行估算
错误： 相关方参加 Sprint Retrospective 正确： Retrospective 只有 Scrum Team 参加
错误： Sprint Review 后直接开始下个 Sprint 正确： Review → Retrospective → Planning
错误： Daily Scrum 用于解决问题 正确： Daily Scrum 只用于同步，问题在会后解决
错误： 用速度评价团队绩效 正确： 速度只用于预测，不用于评价
错误： 比较不同团队的速度 正确： 速度是团队内部指标，不可跨团队比较
错误： 追求燃尽图完美匹配理想线 正确： 接受合理波动，关注趋势
错误： 敏捷项目不需要文档 正确： 需要恰到好处的文档
错误： 敏捷等于没有计划 正确： 敏捷强调适应性计划
错误： 客户的所有变更都必须接受 正确： 评估影响，与 PO 协商优先级
错误： Scrum Master 是团队的管理者 正确： Scrum Master 是服务者和引导者
错误： 遇到问题立即介入解决 正确： 先让团队尝试自己解决
错误： 保护团队意味着隔离所有外部干扰 正确： 平衡保护和必要的相关方互动
通过本章学习和大量练习，你将能够：