第18章：敏捷题型特训

在 PMP 考试中，敏捷相关内容占比已超过 50%。本章聚焦敏捷题型的核心考点，通过深度解析敏捷价值观、Scrum 框架、仆人式领导和敏捷度量等关键主题，帮助你准确把握敏捷思维在实际场景中的应用。我们将通过大量真题案例和 AI 模拟练习，让你在考试中快速识别敏捷题型的解题思路。

18.1 敏捷价值观考点

18.1.1 敏捷宣言四大价值观

敏捷宣言的四大价值观是 PMP 考试的高频考点，理解其深层含义至关重要：

1. 个体和互动 高于 流程和工具
2. 工作的软件 高于 详尽的文档
3. 客户合作 高于 合同谈判
4. 响应变化 高于 遵循计划

关键理解要点：

• "高于"不是"替代"——右侧项目仍有价值，但左侧更重要
• 在冲突场景中，优先选择左侧价值观指导的行动
• 敏捷强调适应性而非预测性

价值观深度解析：

1. 个体和互动 高于 流程和工具

这一价值观强调人的因素是项目成功的关键。优秀的团队配合即使使用简单工具也能成功，而缺乏协作的团队即使有最好的工具也难以成功。

实践要点：

• 面对面沟通优于邮件和文档传递
• 团队协作空间设计（如团队房间、白板墙）
• 日常站会、结对编程等促进互动的实践
• 冲突解决优先通过直接对话而非流程仲裁

考试场景示例：

• 团队成员抱怨工具不好用 → 先改善团队协作，再考虑工具
• 远程团队沟通困难 → 增加视频会议频率，而非依赖项目管理工具
• 新成员加入团队 → 安排导师制和结对工作，而非只提供流程文档

2. 工作的软件 高于 详尽的文档

强调可交付成果的实际价值，而非过程文档的完备性。文档应该"恰到好处"（just enough），服务于软件开发而非成为目的本身。

实践要点：

• 优先交付最小可行产品（MVP）
• 文档应该简洁、及时更新、易于维护
• 代码即文档（自解释的代码、单元测试作为规范）
• 用户故事替代详细需求规格说明书

考试场景示例：

• 客户要求看到进展 → 展示可工作的原型，而非进度报告
• 需求不明确 → 快速开发原型获取反馈，而非编写详细需求文档
• 文档与代码不一致 → 以可工作的软件为准，更新必要文档

3. 客户合作 高于 合同谈判

将客户视为合作伙伴而非对手，共同为项目成功努力。合同是起点，但持续的合作关系更重要。

实践要点：

• 客户或产品负责人深度参与整个开发过程
• 定期展示和获取反馈（Sprint Review）
• 灵活应对需求变更，而非死守合同条款
• 建立信任关系，透明沟通项目状态

考试场景示例：

• 客户提出合同外的变更 → 评估价值和影响，协商双赢方案
• 发现原定功能不符合用户需求 → 与客户协商调整，而非强行交付
• 项目遇到技术难题 → 及时与客户沟通，共同寻找解决方案

4. 响应变化 高于 遵循计划

认识到变化是不可避免的，拥抱变化而非抗拒。计划是重要的，但适应变化的能力更重要。

实践要点：

• 短迭代周期，降低变更成本
• 持续规划，滚动式细化（Rolling Wave Planning）
• 保持产品待办事项列表的灵活性
• 经验教训及时应用，持续改进

考试场景示例：

• 市场环境变化要求调整产品方向 → 调整产品路线图，而非坚持原计划
• Sprint 中发现技术方案不可行 → 及时调整方案，通知相关方
• 竞争对手发布新功能 → 重新评估优先级，可能调整当前 Sprint 目标

18.1.2 十二条敏捷原则应用

考试常通过场景题考察对敏捷原则的理解，以下是完整的十二条原则及其应用要点：

十二条敏捷原则详解：

1. 客户满意度优先：通过尽早和持续交付有价值的软件 - 题目特征：涉及交付频率、价值优先级排序 - 正确选项：选择更频繁交付、优先交付高价值功能 - 实践应用：MVP 方法、增量交付、价值流映射

2. 欢迎需求变更：即使在开发后期也欢迎改变需求 - 题目特征：客户提出变更请求的处理 - 正确选项：积极响应变更，评估影响后纳入待办事项 - 实践应用：变更被视为竞争优势的机会，而非风险

3. 频繁交付可工作软件：几周到几个月，倾向于较短周期 - 题目特征：发布计划、迭代长度设置 - 正确选项：2-4 周的迭代周期最常见 - 实践应用：持续集成/持续部署（CI/CD）

4. 业务人员与开发者密切合作：整个项目期间每天如此 - 题目特征：业务参与度问题 - 正确选项：产品负责人全程参与，业务代表定期反馈 - 实践应用：现场客户、产品负责人角色设置

5. 依靠受信任的个体：提供环境和支持，相信他们能完成工作 - 题目特征：团队授权和自主性 - 正确选项：赋能团队做决策，提供资源支持 - 实践应用：自组织团队、去中心化决策

6. 面对面沟通：最有效的信息传递方式 - 题目特征：团队沟通问题解决 - 正确选项：优先安排面对面会议或视频会议 - 实践应用：团队同地办公、每日站会、白板讨论

7. 工作的软件是进度的主要度量 - 题目特征：进度报告和度量方式 - 正确选项：用完成的功能而非文档或代码行数衡量 - 实践应用：演示驱动、功能完成定义（DoD）

8. 可持续的开发节奏：发起人、开发者和用户应能无限期保持恒定步调 - 题目特征：团队工作负荷和节奏 - 正确选项：避免加班，保持稳定的速度 - 实践应用：限制在制品（WIP）、团队速度稳定性

9. 持续关注技术卓越和良好设计：增强敏捷性 - 题目特征：技术债务、重构、质量实践 - 正确选项：投入时间进行重构和技术改进 - 实践应用：测试驱动开发（TDD）、代码评审、持续重构

10. 简单性：最大化未完成工作量的艺术

    • 题目特征：功能范围、设计复杂度
    • 正确选项：选择最简单可行的解决方案
    • 实践应用：YAGNI（You Aren't Gonna Need It）原则

11. 自组织团队：最好的架构、需求和设计出自自组织团队

    • 题目特征：团队决策权、问题解决方式
    • 正确选项：让团队自主决定技术方案和工作分配
    • 实践应用：团队章程、集体代码所有权

12. 定期反思和调整：团队定期反思如何更有效，并相应调整

    • 题目特征：持续改进、回顾会议
    • 正确选项：定期举行回顾会，实施改进措施
    • 实践应用：Sprint 回顾会、改善（Kaizen）文化

18.1.3 敏捷思维 vs 传统思维

理解敏捷思维与传统项目管理思维的差异是考试成功的关键。PMP 考试经常通过对比场景来考察候选人是否真正理解敏捷理念。

核心思维差异：

| 维度 | 传统思维（预测型） | 敏捷思维（适应型） |

详细场景对比：

| 场景类型 | 传统思维 | 敏捷思维 | 考试提示 |

思维转换要点：

1. 从控制到赋能 - 传统：项目经理控制和指挥 - 敏捷：Scrum Master 服务和引导 - 考试技巧：看到"empower"、"facilitate"通常是正确答案

2. 从预测到适应 - 传统：详细的前期计划 - 敏捷：响应变化的能力 - 考试技巧：选择灵活性和适应性高的选项

3. 从个体到团队 - 传统：明确的个人职责 - 敏捷：集体所有权和责任 - 考试技巧：强调团队协作的选项优先

4. 从阶段到迭代 - 传统：瀑布式阶段门 - 敏捷：短周期快速迭代 - 考试技巧：选择更短周期和更频繁交付

5. 从合同到协作 - 传统：固定范围、时间、成本 - 敏捷：固定时间、成本，可变范围 - 考试技巧：优先考虑价值和协作

18.1.4 典型题目解析

例题 1：价值观应用

项目进行到第三个迭代，客户突然要求增加一个重要功能。团队评估后发现会影响当前迭代目标。项目经理应该：

A. 拒绝变更，维护迭代目标 B. 立即加入当前迭代 C. 与产品负责人讨论优先级，可能调整下个迭代计划 D. 要求客户提供详细需求文档

解析： 答案 C。体现"响应变化高于遵循计划"和"客户合作"的价值观。

例题 2：原则理解

敏捷团队完成了一个功能，但只实现了 60% 的原定需求。最佳做法是：

A. 延迟发布直到 100% 完成 B. 发布当前版本，收集反馈后迭代 C. 加班完成剩余 40% D. 降低质量标准以完成所有功能

解析： 答案 B。体现"尽早交付价值"和"迭代改进"原则。

18.2 Scrum 事件顺序题

Scrum 框架的事件管理是 PMP 考试的重点内容。理解每个事件的目的、时间盒、参与者和输出至关重要。考试经常通过场景题考察事件的正确顺序、参与规则和时间管理。

18.2.1 Scrum 事件时间盒

Sprint (冲刺)
├── Sprint Planning (冲刺计划会)
│   └── 时间盒：8小时（4周冲刺）
├── Daily Scrum (每日站会)
│   └── 时间盒：15分钟
├── Sprint Review (冲刺评审会)
│   └── 时间盒：4小时（4周冲刺）
└── Sprint Retrospective (冲刺回顾会)
    └── 时间盒：3小时（4周冲刺）

时间盒计算公式：

• Sprint Planning: 冲刺长度 × 2小时
• Sprint Review: 冲刺长度 × 1小时
• Sprint Retrospective: 冲刺长度 × 0.75小时
• Daily Scrum: 固定15分钟（不受Sprint长度影响）

时间盒管理原则：

1. 严格遵守时间限制 - 时间盒是最大时限，不是必须用完 - 提前完成可以结束，但不能超时 - Scrum Master 负责确保遵守时间盒

2. 根据 Sprint 长度调整 - 2周 Sprint：Planning 4小时，Review 2小时，Retro 1.5小时 - 3周 Sprint：Planning 6小时，Review 3小时，Retro 2.25小时 - 4周 Sprint：Planning 8小时，Review 4小时，Retro 3小时

3. 时间分配建议 - Sprint Planning：前半部分确定"做什么"，后半部分确定"怎么做" - Sprint Review：展示占60%，讨论反馈占40% - Sprint Retrospective：检查占40%，改进计划占60%

常见时间盒问题：

| 问题场景 | 错误做法 | 正确做法 |

18.2.2 事件顺序与目的

标准 Scrum 事件流程：

1. Sprint Planning（开始） - 确定 Sprint 目标 - 选择 Product Backlog 项 - 制定 Sprint Backlog - 参与者：整个 Scrum Team

2. Daily Scrum（每天） - 同步进度 - 识别障碍 - 调整当日计划 - 参与者：Development Team

3. Sprint Review（结束前） - 展示完成的增量 - 收集反馈 - 调整 Product Backlog - 参与者：Scrum Team + 相关方

4. Sprint Retrospective（最后） - 检查人、关系、过程、工具 - 识别改进项 - 制定改进计划 - 参与者：Scrum Team

18.2.3 角色职责矩阵

| Scrum 角色 | Sprint Planning | Daily Scrum | Sprint Review | Sprint Retrospective |

18.2.4 常见顺序题陷阱

陷阱 1：Review 和 Retrospective 顺序

• 正确：先 Review（对外），后 Retrospective（对内）
• 原因：先展示成果收集反馈，再内部总结改进

陷阱 2：Daily Scrum 参与者

• 正确：只有 Development Team 发言
• 错误选项：PO 主持会议、SM 分配任务

陷阱 3：Sprint 中途加入紧急任务

• 正确：只有 Development Team 可以改变 Sprint Backlog
• 注意：不能改变 Sprint 目标

例题：事件顺序

Sprint 即将结束，以下事件的正确顺序是：

A. Retrospective → Review → Planning B. Review → Retrospective → Planning C. Planning → Review → Retrospective D. Review → Planning → Retrospective

解析： 答案 B。标准顺序是先对外展示（Review），再对内改进（Retrospective），最后规划下个 Sprint（Planning）。

18.3 仆人式领导场景

18.3.1 仆人式领导核心特征

仆人式领导是敏捷环境中的关键领导风格，Scrum Master 是典型代表：

核心行为模式：

1. 服务优先：先服务，后领导
2. 赋能团队：帮助团队成员成长和成功
3. 移除障碍：主动识别和清除团队障碍
4. 促进协作：创造协作环境，而非命令控制

18.3.2 仆人式领导 vs 传统领导

| 情境 | 传统领导方式 | 仆人式领导方式 | PMP 考试倾向 |

18.3.3 Scrum Master 典型场景题

场景 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。保护团队的同时考虑业务价值。

18.3.4 仆人式领导能力模型

        促进能力
           ↑
    引导 ← SM → 教练
           ↓
        服务意识

关键能力要素：

- 引导（Facilitation）：帮助团队高效协作
- 教练（Coaching）：提升团队能力
- 指导（Mentoring）：分享经验知识
- 教学（Teaching）：传授敏捷实践

考试提示：

• 看到 "empower"、"facilitate"、"coach"、"support" 等词汇，通常是正确选项
• 避免选择 "direct"、"assign"、"decide for" 等命令式词汇
• 记住：Scrum Master 没有对团队的直接管理权

18.4 敏捷度量指标题

18.4.1 速度（Velocity）相关计算

速度定义： 团队在一个 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

18.4.2 燃尽图（Burndown Chart）分析

理想燃尽线与实际燃尽线：

故事点
100|＼ 理想线
   | ＼
75 |  ＼_____ 实际线
   |    ＼   ＼
50 |     ＼___＼
   |         ＼＼
25 |          ＼＼___
   |              ＼
0  |________________＼___
   Day1  Day5  Day10  Day15

解读要点：

- 实际线在理想线上方：进度落后
- 实际线在理想线下方：进度超前
- 实际线平坦：工作停滞
- 实际线上升：范围增加

燃尽图问题诊断：

| 图形特征 | 可能原因 | 建议对策 |

18.4.3 燃起图（Burnup Chart）应用

燃起图示例：

故事点
150|           _____ 范围线
   |      ____/
100|  ___/  _____ 完成线
   | /  ___/
50 |/__/
   |
0  |________________
   Sprint1  2  3  4

优势：

- 明确显示范围变化
- 区分进度问题和范围问题
- 更适合向相关方汇报

18.4.4 其他关键敏捷指标

1. 周期时间（Cycle Time） $$\text{Cycle Time} = \text{完成时间} - \text{开始工作时间}$$ 用途：预测单个工作项的交付时间

2. 前置时间（Lead Time） $$\text{Lead Time} = \text{交付时间} - \text{需求提出时间}$$ 用途：衡量端到端的交付效率

3. 在制品（WIP）限制 - 看板方法的核心 - 限制并行工作数量 - 公式：$\text{WIP} \leq \text{团队容量}$

4. 缺陷逃逸率 $$\text{Defect Escape Rate} = \frac{\text{生产环境发现的缺陷}}{\text{总缺陷数}} \times 100\%$$

目标：< 5%

5. 团队幸福指数 - 定性指标 - 通过回顾会收集 - 趋势比绝对值重要

18.4.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估算标准不一致。

18.4.6 反模式识别

常见度量反模式：

1. 速度竞赛 - 症状：团队追求更高速度数字 - 问题：故事点膨胀，质量下降 - 正解：速度用于预测，不用于评价

2. 个人度量 - 症状：统计个人完成的故事点 - 问题：破坏团队协作 - 正解：只度量团队整体

3. 过度度量 - 症状：收集大量指标 - 问题：分散注意力 - 正解：关注 2-3 个关键指标

18.5 AI 对练：敏捷教练模拟

18.5.1 AI 角色扮演设置

使用 AI 工具进行敏捷教练场景模拟，可以大幅提升实战能力。以下是推荐的 prompt 模板：

基础设置 Prompt：

你是一位经验丰富的敏捷教练，我是准备 PMP 考试的学员。
请模拟真实的敏捷项目场景，给我提供需要解决的问题。
每个场景后，请等待我的回答，然后：

1. 评估我的答案是否符合敏捷原则
2. 指出可能的 PMP 考试陷阱
3. 提供标准答案和解释

18.5.2 场景练习模板

场景 1：团队冲突处理

AI Prompt:
生成一个 Scrum 团队内部冲突的场景，涉及：

- 开发人员对 PO 优先级的质疑
- 技术债务vs新功能的权衡
- 时间压力下的质量担忧
要求我以 Scrum Master 身份处理

场景 2：相关方管理

AI Prompt:
创建一个场景，其中：

- 高层管理要求固定范围和时间
- 客户期望持续看到进展
- 团队倡导敏捷方法
要求我提供沟通策略

场景 3：度量指标解释

AI Prompt:
给我一组 Sprint 数据：

- 3个 Sprint 的速度值
- 燃尽图数据点
- 缺陷统计
要求我分析问题并提出改进建议

18.5.3 AI 批量题目生成

批量生成 Prompt：

生成 10 道 PMP 敏捷相关选择题，要求：

1. 覆盖敏捷宣言、Scrum 框架、看板、极限编程
2. 每题包含一个实际场景
3. 4 个选项，其中 2 个是常见误区
4. 提供答案和详细解析
5. 标注考察的知识点

18.5.4 弱项强化训练

个性化训练 Prompt：

我在以下方面容易出错：

- 混淆 Scrum 事件的参与者
- 不清楚 SM 和 PO 的职责边界
- 计算题容易出错

请针对这些弱项：

1. 生成专项练习题
2. 提供记忆技巧
3. 创建对比表格

18.5.5 AI 模拟面试

面试模拟 Prompt：

模拟 PMP 考试的情景判断题面试：

1. 描述一个复杂的项目情况
2. 我需要选择最佳行动方案
3. 追问我的选择理由
4. 指出其他选项的问题
5. 关联到 PMP 知识体系

18.5.6 知识点速查

快速复习 Prompt：

用一问一答的方式帮我快速复习：

- Scrum 的 3-3-5-5 框架
- 敏捷估算技术对比
- 仆人式领导 vs 命令控制
- 敏捷合同类型
每个问题等待我回答后再给出正确答案

本章小结

本章深入探讨了 PMP 考试中的敏捷题型特点和解题策略：

核心知识点回顾

1. 敏捷价值观与原则 - 四大价值观："高于"而非"替代" - 12 条原则的实际应用 - 敏捷思维 vs 传统思维的关键区别

2. Scrum 框架要素 - 3 个角色：PO、SM、Dev Team - 5 个事件：Sprint、Planning、Daily、Review、Retrospective - 3 个工件：Product Backlog、Sprint Backlog、Increment - 时间盒概念和计算方法

3. 仆人式领导 - 服务、赋能、引导、保护 - Scrum Master 的核心职责 - 避免命令控制式管理

4. 敏捷度量体系 - 速度（Velocity）：预测工具，非评价标准 - 燃尽/燃起图：可视化进度管理 - 周期时间、前置时间：流程效率指标 - WIP 限制：看板核心实践

5. AI 辅助学习 - 场景模拟提升实战能力 - 批量题目生成针对性练习 - 个性化弱项强化训练

关键公式汇总

• 平均速度 = $\frac{\sum \text{Past Velocities}}{n}$
• 剩余 Sprint = $\frac{\text{Remaining Points}}{\text{Average Velocity}}$
• 沟通渠道 = $\frac{n(n-1)}{2}$
• 缺陷逃逸率 = $\frac{\text{Production Defects}}{\text{Total Defects}} \times 100\%$

解题策略要点

1. 识别题型：看关键词判断是否为敏捷场景
2. 价值观优先：冲突时选择敏捷价值观指导的选项
3. 角色定位：明确你在题目中的角色和职责
4. 避免陷阱：注意"高于"vs"替代"、"引导"vs"指挥"

常见陷阱与错误（Gotchas）

1. 角色混淆陷阱

错误： Scrum Master 分配任务给团队成员 正确： 团队自组织决定任务分配

错误： Product Owner 参与估算故事点 正确： 只有 Development Team 进行估算

错误： 相关方参加 Sprint Retrospective 正确： Retrospective 只有 Scrum Team 参加

2. 事件顺序陷阱

错误： Sprint Review 后直接开始下个 Sprint 正确： Review → Retrospective → Planning

错误： Daily Scrum 用于解决问题 正确： Daily Scrum 只用于同步，问题在会后解决

3. 度量使用陷阱

错误： 用速度评价团队绩效 正确： 速度只用于预测，不用于评价

错误： 比较不同团队的速度 正确： 速度是团队内部指标，不可跨团队比较

错误： 追求燃尽图完美匹配理想线 正确： 接受合理波动，关注趋势

4. 敏捷实践陷阱

错误： 敏捷项目不需要文档 正确： 需要恰到好处的文档

错误： 敏捷等于没有计划 正确： 敏捷强调适应性计划

错误： 客户的所有变更都必须接受 正确： 评估影响，与 PO 协商优先级

5. 领导风格陷阱

错误： Scrum Master 是团队的管理者 正确： Scrum Master 是服务者和引导者

错误： 遇到问题立即介入解决 正确： 先让团队尝试自己解决

错误： 保护团队意味着隔离所有外部干扰 正确： 平衡保护和必要的相关方互动

记忆技巧

1. 3-3-5-5 框架记忆法 - 3 个角色 - 3 个工件 - 5 个事件 - 5 个价值观（4+1：四大价值观 + 勇气）

2. INVEST 用户故事标准 - Independent（独立） - Negotiable（可协商） - Valuable（有价值） - Estimable（可估算） - Small（小） - Testable（可测试）

3. 时间盒快速计算 - Planning = Sprint 周数 × 2 小时 - Review = Sprint 周数 × 1 小时 - Retrospective = Sprint 周数 × 0.75 小时

考试应对建议

1. 题目关键词识别 - "自组织"→ 选择团队决定 - "障碍"→ 选择 SM 介入 - "优先级"→ 选择 PO 决定 - "技术决策"→ 选择开发团队

2. 情景判断原则 - 人重于流程 - 对话重于文档 - 适应重于计划 - 价值重于合同

3. 时间管理策略 - 敏捷题通常较长，预留充足时间 - 先读问题，再看场景 - 标记不确定题目，最后复查

通过本章学习和大量练习，你将能够：

• 快速识别敏捷题型特征
• 准确应用敏捷原则和实践
• 避免常见的思维陷阱
• 在 PMP 考试中自信应对敏捷相关题目