本章深入探讨敏捷项目管理的核心概念和实践方法。作为 PMP 考试的重要组成部分，敏捷内容占比已达到约 50%。我们将重点学习 Scrum 框架、看板方法、敏捷估算技术以及关键指标，帮助你建立完整的敏捷知识体系，应对考试中的敏捷相关题目。
Scrum 建立在五个核心价值观之上，这些价值观不仅是理论基础，更是日常实践的指导原则：
价值观在实践中的体现：
Scrum 团队由三个角色组成，形成自组织、跨职能的协作单元：
产品负责人（Product Owner）
Scrum Master
开发团队（Development Team）
Scrum 定义了五个事件，每个事件都是检视和适应的机会。这些事件形成了 Scrum 的心跳节奏：
Sprint (冲刺周期) ──── 容器事件
├── Sprint Planning (冲刺计划会) ──── 设定方向
├── Daily Scrum (每日站会) ──── 保持同步
├── Sprint Review (冲刺评审会) ──── 验证价值
└── Sprint Retrospective (冲刺回顾会) ──── 持续改进
冲刺（Sprint）
冲刺计划会（Sprint Planning）
两部分议程：
第一部分：What - 选择待办事项
第二部分：How - 制定实现计划
每日站会（Daily Scrum）
冲刺评审会（Sprint Review）
冲刺回顾会（Sprint Retrospective）
事件间的关系与节奏：
产品待办列表（Product Backlog）
冲刺待办列表（Sprint Backlog）
产品增量（Increment）
完成的定义（Definition of Done）
用户故事（User Story）
验收标准（Acceptance Criteria）
看板方法源自精益生产，强调可视化管理和流动效率：
看板板是可视化管理的核心工具，设计良好的看板板能够一目了然地展示工作状态和流动情况。
典型的看板板结构：
┌─────────┬──────────┬────────┬─────────┬──────────┐
│ Backlog │ To Do │ Doing │ Testing │ Done │
│ │ (WIP:5) │ (WIP:3)│ (WIP:2) │ │
├─────────┼──────────┼────────┼─────────┼──────────┤
│ Story1 │ Story2 │ Story5 │ Story7 │ Story9 │
│ Story3 │ Story4 │ Story6 │ Story8 │ Story10 │
│ Story11│ │ │ │ Story12 │
└─────────┴──────────┴────────┴─────────┴──────────┘
高级看板板设计：
┌──────────┬─────────────────────────┬─────────┬──────────┐
│ │ Development │ Testing │ │
│ Backlog ├──────┬────────┬─────────┼────┬────┤ Done │
│ │Ready │ Coding │ Review │Test│UAT │ │
│ │(WIP:3)│(WIP:2)│ (WIP:2) │(WIP:2)│ │
├──────────┼──────┼────────┼─────────┼────┼────┼──────────┤
│ 优先级1 │ ★ │ ◆ │ │ │ │ │
│ 优先级2 │ │ │ ● │ ▲ │ │ ✓ │
│ 优先级3 │ ■ │ │ │ │ ✦ │ ✓ │
│ 待规划 │ │ │ │ │ │ │
└──────────┴──────┴────────┴─────────┴────┴────┴──────────┘
图例：★紧急 ◆常规 ●缺陷 ▲技术债务 ■新功能 ✦客户反馈
WIP 限制的设计原则：
利特尔法则（Little’s Law）： \(\text{平均周期时间} = \frac{\text{平均在制品数量}}{\text{平均吞吐率}}\)
启示：降低 WIP 可以缩短周期时间
泳道（Swimlane）设计：
┌──────────┬──────────┬────────┬─────────┬──────────┐
│ 类型 │ To Do │ Doing │ Testing │ Done │
├──────────┼──────────┼────────┼─────────┼──────────┤
│ 紧急修复 │ 🔥 │ │ │ │
├──────────┼──────────┼────────┼─────────┼──────────┤
│ 功能开发 │ F-101 │ F-102 │ F-103 │ F-104 │
│ │ F-105 │ │ │ │
├──────────┼──────────┼────────┼─────────┼──────────┤
│ 技术债务 │ TD-01 │ TD-02 │ │ │
├──────────┼──────────┼────────┼─────────┼──────────┤
│ 维护任务 │ M-001 │ │ M-002 │ M-003 │
└──────────┴──────────┴────────┴─────────┴──────────┘
服务分类（Class of Service）：
阻塞和等待状态可视化：
前置时间（Lead Time） \(\text{Lead Time} = \text{完成时间} - \text{请求时间}\)
周期时间（Cycle Time） \(\text{Cycle Time} = \text{完成时间} - \text{开始时间}\)
吞吐量（Throughput）
累积流图（Cumulative Flow Diagram）
| 维度 | Scrum | 看板 |
|---|---|---|
| 节奏 | 固定冲刺周期 | 连续流动 |
| 角色 | 定义明确的三个角色 | 无规定角色 |
| 变更 | 冲刺期间不变更 | 随时可变更 |
| 承诺 | 冲刺承诺 | 按需拉动 |
| 估算 | 通常需要估算 | 可选 |
| 会议 | 规定的 Scrum 事件 | 按需进行 |
| 板重置 | 每个冲刺重置 | 持续使用 |
渐进式改进
服务等级协议（SLA）
拉动系统优化
敏捷强调相对估算而非绝对估算，这是敏捷思维方式的重要体现。
为什么选择相对估算？
绝对误差会累积：10h ± 2h + 15h ± 3h = 25h ± 5h
相对误差会抵消：故事点在大量样本下趋于稳定
相对估算的层次：
精确度低 精确度高
速度快 速度慢
┌─────────────┬──────────────┬──────────────┐
│ T恤尺码 │ 故事点 │ 理想日 │
│ (S/M/L) │ (1,2,3,5,8) │ (0.5-10) │
└─────────────┴──────────────┴──────────────┘
初期 后期
定义与特征
为什么使用斐波那契数列？
执行步骤：
规划扑克的价值：
使用服装尺码进行快速估算：
转换示例：
XS = 1 点
S = 2-3 点
M = 5-8 点
L = 13 点
XL = 21 点
XXL = 需要拆分
步骤：
理想日（Ideal Days）
为什么敏捷偏好故事点而非工时？
估算锥（Cone of Uncertainty）
初始阶段: ±400%
需求阶段: ±100%
设计阶段: ±50%
编码阶段: ±25%
测试阶段: ±10%
提高估算准确性的方法：
定义
计算与应用 \(\text{平均速度} = \frac{\sum \text{各冲刺完成的故事点}}{冲刺数量}\)
速度图示例：
故事点
40 | ★
35 | ★ ★
30 | ★ ★---平均速度
25 | ★
20 |
└─────────────────→ 冲刺
1 2 3 4 5
注意事项：
冲刺燃尽图
剩余工作
100|★ 理想线
80| ★\
60| ★\___实际线
40| \★-★
20| \ ★-★
0| \ ★
└────────────────────→ 天数
0 2 4 6 8 10
发布燃尽图
优势对比燃尽图：
故事点
150| ━━━━ 总范围
120| ━━
90| ━━
60| ★━★━★ 完成工作
30| ★
0|★
└────────────────→ 冲刺
0 1 2 3 4 5
解读要点：
工作项数
50| ▓▓▓ 完成
40| ▓▓▓▒▒
30| ▓▓▓▒▒▒░░ 测试中
20| ▓▓▒▒▒░░░░░
10| ▓▒▒░░░░░░░░░ 开发中
0|▒░░░░░░░░░░░░░ 待办
└──────────────→ 时间
缺陷密度 \(\text{缺陷密度} = \frac{\text{发现的缺陷数}}{\text{代码行数(KLOC)}}\)
缺陷移除效率（DRE） \(\text{DRE} = \frac{\text{内部发现的缺陷}}{\text{总缺陷数}} \times 100\%\)
缺陷年龄
团队稳定性
技术健康度
业务价值交付
基础用户故事生成：
请基于以下功能需求生成用户故事：
功能：[功能描述]
用户角色：[目标用户]
业务目标：[期望结果]
输出格式：
- 用户故事（As a...I want...So that...）
- 验收标准（Given...When...Then...）
- 故事点估算建议
批量故事拆分：
将以下史诗故事拆分为3-5个独立的用户故事：
史诗：[大型功能描述]
约束：每个故事应在1-2个冲刺内完成
依赖：[已知依赖关系]
相对大小比较：
比较以下两个用户故事的复杂度：
故事A：[描述]
故事B：[描述]
考虑因素：
- 技术复杂度
- 业务规则复杂度
- 集成点数量
- 测试场景数量
输出：哪个更大？大约是几倍？
BDD 场景生成：
为以下用户故事生成 BDD 测试场景：
用户故事：[故事内容]
生成：
- 正常路径场景
- 边界条件场景
- 异常处理场景
- 性能相关场景
定制化回顾问题：
基于以下冲刺数据生成回顾会议问题：
- 完成故事点：[数值] vs 承诺：[数值]
- 缺陷数：[数值]
- 团队反馈：[关键词]
生成5个开放式问题，促进深度讨论
问题描述： 团队刚开始实施 Scrum，产品负责人经常在冲刺中途要求添加紧急需求，开发团队抱怨无法专注，Scrum Master 应该如何处理？
分析要点：
建议方案：
数据：
可能原因：
改进建议：
现象： 测试列的 WIP 经常达到上限，开发完成的工作项堆积
根因分析：
解决方案：
本章系统介绍了敏捷项目管理的核心知识，覆盖了 PMP 考试中敏捷相关的主要考点：
关键概念回顾：
核心原则强调：
考试要点提醒：
错误：Scrum Master 分配任务给团队成员 正确：开发团队自组织，自行分配任务
错误：产品负责人参与技术决策 正确：产品负责人关注”什么”和”为什么”，团队决定”如何”
错误：每日站会用于向 Scrum Master 汇报进度 正确：每日站会是团队同步会议，为团队服务
错误：冲刺评审会是签字验收会议 正确：冲刺评审是获取反馈、调整产品待办列表的机会
错误：将故事点直接转换为工时 正确：故事点是相对度量，不等同于时间
错误：个人完成的故事点用于绩效考核 正确：速度是团队指标，强调集体责任
错误：比较不同团队的速度 正确：速度只在同一团队内有比较意义
错误：追求速度最大化 正确：追求可持续的、可预测的速度
错误：敏捷意味着没有计划 正确：敏捷强调适应性计划，而非无计划
错误：敏捷不需要文档 正确：敏捷强调”足够”的文档，而非无文档
错误：敏捷等于快速交付 正确：敏捷强调持续交付价值，质量不能妥协
错误：在 Scrum 中随意修改框架规则 正确：先完整实施，理解原理后再考虑调整
错误：预测型项目直接切换到敏捷 正确：渐进式转型，可能需要混合方法过渡
通过掌握这些知识点和避免常见陷阱，你将能够在 PMP 考试中准确回答敏捷相关题目，并在实际工作中有效应用敏捷方法。记住，敏捷不仅是一套方法论，更是一种思维模式的转变。