深度解析 25 年 PMP 新考纲中的“敏捷”

备考PMP时，发现：敏捷开发已成为新考纲的重中之重（占比50%+），所以本篇系统梳理的敏捷核心概念、关键知识点及易错点。

敏捷核心概念

1、价值观

敏捷开发有 4 大重要的价值观：

• 个体互动 > 流程工具

例如：团队用每日站会替代复杂项目管理工具，通过面对面沟通快速解决技术难题。

• 可用软件 > 详尽文档

例如：通过每周发布MVP（最小可行产品），3个月内完成核心功能上线，而传统文档驱动模式需6个月。

• 客户协作 > 合同谈判

例如：软件项目在开发过程中邀请客户参与迭代评审，需求变更接受率、客户满意度双重提升。

• 响应变化 > 遵循计划

例如：团队在开发后期根据测试反馈调整核心功能，提升用户留存率。

敏捷价值观的本质是通过「以人为本、价值导向」的理念构建自适应系统。 —— 不得不说，这简直就是万金油的定义

2、十二原则

（1）客户满意度至上

核心：通过快速交付有价值的软件满足客户需求，优先实现核心功能而非追求完美。

实践：采用短周期迭代（如Scrum的2周冲刺），每轮迭代交付可运行的最小可用产品（MVP）。例如，电商平台优先上线商品搜索和下单功能，后续再优化推荐算法。

（2）拥抱需求变化

核心：即使开发后期也欢迎需求变更，视变化为竞争优势。

实践：通过用户故事（User Story）动态管理需求池（Product Backlog），定期与客户同步优先级。例如，金融系统开发中根据监管政策调整交易流程。

（3）高频交付可运行软件

核心：交付间隔越短越好（通常2-6周），确保功能闭环且无重大缺陷。

案例：某打车软件每两周发布新版本，逐步上线地图导航、拼车、支付等功能。

（4）业务与开发紧密协作

核心：业务人员（如产品经理）全程参与开发，减少沟通误差。

方法：每日站会（Daily Standup）同步进展，使用看板（Kanban）可视化任务状态。

（5）激发团队自主性

核心：信任团队能力，提供资源支持而非微观管理。

实践：自组织团队选择任务分配方式，如T型人才（全栈工程师）减少依赖。

（6）面对面沟通优先

核心：直接交流效率高于文档传递，减少信息衰减。

工具：使用白板、即时通讯工具，辅以简明文档（如架构图、API说明）。

（7）可运行软件为进度标准

核心：功能可用性比文档完整度更重要，避免“纸上谈兵”。

指标：使用自动化测试覆盖率（如Jenkins持续集成）验证软件质量。

（8）可持续开发节奏

核心：避免过度加班，保持稳定产出效率。

案例：遵循“40小时工作制”（XP原则），防止团队倦怠导致后期返工。

（9）追求技术卓越

核心：通过重构、代码评审提升代码质量，降低技术债务。

方法：结对编程（Pair Programming）、测试驱动开发（TDD）减少缺陷率。

（10）保持简洁

核心：以最小化设计满足当前需求，避免过度工程化。

案例：社交平台初期仅支持文字发布，后续逐步扩展图片、视频功能。

（11）自组织团队

核心：团队自主决策实现路径，管理者提供目标而非具体方案。

实践：Scrum Master负责移除障碍，而非直接指派任务。

（12）定期反思改进

核心：通过回顾会议（Retrospective）优化流程。

方法：使用“Start/Stop/Continue”模板分析迭代问题，制定改进计划。

上述这些原则共同构建了敏捷开发的适应性框架，企业需根据自身场景（如团队规模、行业特性）选择适配实践，而非机械套用流程。

例如，医疗软件需强化文档合规性（原则7补充文档），而互联网产品更侧重快速迭代（原则3加速交付）。

Scrum框架

如果说敏捷占 PMP 一半的考点、那么 SCRUM 占敏捷的 90% ：

推荐阅读 3355 框架：www.scrum.cn/26797.html

1、流程与角色

Scrum 框架的核心流程围绕固定周期（通常2-4周）的冲刺（Sprint）展开，包含三大角色：

（1）产品负责人（Product Owner） 负责定义需求优先级并维护产品待办列表（Product Backlog），确保交付价值最大化；

（2）Scrum Master 作为流程引导者，负责消除团队障碍并确保Scrum规则执行；

（3）跨职能开发团队（5-9人）自组织完成冲刺目标。

image.png

流程上：

（1）冲刺计划会议（Sprint Planning）

• 始于冲刺计划会议（Sprint Planning）选定本周期任务形成冲刺待办列表（Sprint Backlog）

3、故事点

这里有一个很重要的考点就是：故事点，故事点作为相对工作量单位，通过量化用户故事复杂度帮助团队预估冲刺代办列表的容量。

在执行中，故事点附着于代办任务形成可视化优先级排序，并通过燃尽图跟踪进度偏差，最终为冲刺评审提供数据支撑（承诺故事点vs实际完成数），驱动团队持续校准估算精度并优化工作流程。

故事点如同"敏捷标尺"

• 敏捷估算故事点方法的对比表格：

（2）每日站会（Daily Scrum）

• 每日通过15分钟站会（Daily Scrum）同步进展

（3）评审会议（Sprint Review）

• 冲刺结束时举行评审会议（Sprint Review）演示增量成果并获取反馈

（4）回顾会议（Retrospective）

• 最后通过回顾会议（Retrospective）优化协作方式

整个过程强调迭代交付、快速响应变化，角色职责清晰但协作灵活。

2、工程实践

在实践中，持续集成（CI）、测试驱动开发（TDD）和看板（Kanban）是三个相互关联却各有侧重的核心工具。

（1）CI

• 开发者每次提交代码时，自动化流水线会立即触发编译、单元测试和集成测试，确保主干代码始终处于可部署状态。避免传统开发中集中合并引发的“集成地狱”。

（2）TDD

• 测试驱动开发（TDD）则从需求源头重塑了编码逻辑。开发者先根据用户故事编写失败的测试用例（红阶段），再编写刚好能通过测试的最简代码（绿阶段），最后重构优化代码结构。

（3）Kanban

• 看板与Scrum的结合也颇为常见，例如在冲刺周期内用看板管理每日任务流动，冲刺回顾时分析看板数据优化流程。是流程优化的可视化镜子，能暴露瓶颈。

TDD产出的测试用例成为CI流水线的质量关卡，而看板则实时反馈CI/TDD实施中的流程阻塞点。

但是，敏捷没有固定的银弹，只有当你理解其内核是‘快速反馈’和‘持续改进’时，就能灵活裁剪出适合团队的敏捷武器库。

所以，传统瀑布开发与敏捷开发，常常不是非此即彼，而是混合起来的：如何平衡计划驱动与灵活响应（如变更管理流程的设计）是另外一个核心考点。

易错点

1、概念混淆

• 迭代 vs 增量 迭代是固定时间周期内完成特定任务（如两周冲刺），增量是逐步交付的功能模块（如分阶段上线功能）。一次迭代可能包含多个增量。
• 敏捷教练 vs Scrum Master 敏捷教练是方法论专家，协助团队优化流程；Scrum Master是Scrum框架的守护者，确保流程执行。
• 预测型（瀑布） vs 混合型方法 预测型需预先规划完整流程（如建筑项目），混合型结合预测和敏捷（如分阶段交付+迭代开发），易混淆适用场景。

2、场景误判

• 错用敏捷场景 高合规性项目（如医药审批）需严格文档和流程，敏捷的灵活性可能不适用。
• 忽略团队自组织前提 自组织要求成员能力均衡且经验丰富，新手团队需外部引导（如Scrum Master介入）。
• 需求不明确时坚持预测型方法 PMP的计划驱动模式依赖明确需求，若需求模糊仍强行使用，易导致范围蔓延和失败。

3、工具与术语

• 燃尽图（Burn-down Chart） 用于跟踪剩余工作量，若曲线上升可能任务蔓延或估算错误，而非进度良好。
• 故事点估算 采用斐波那契数列（1,2,3,5,8）衡量相对复杂度，非实际工时，误用会导致进度偏差。
• 关键路径法（CPM） vs 关键链法（CCM） CPM仅考虑任务依赖关系，CCM加入资源限制，混淆二者易导致资源分配错误。
• WBS vs 产品待办列表（Product Backlog） WBS是层级化任务分解（如建楼分地基、结构），产品待办列表是动态需求池（按优先级排序），结构差异易被忽视。

4、流程与规范

• 变更请求 vs 缺陷修复 变更请求包含功能新增或修改，缺陷修复仅针对已发现问题，混淆可能导致流程混乱（如未经评审直接修复）。
• 质量保证（QA） vs 质量控制（QC） QA是过程导向（如审计流程），QC是产品检测（如测试输出），误用可能影响质量目标。

• 案例1：在医疗软件开发中，误将用户故事点直接换算为工时（如1故事点=8小时），导致迭代周期严重超支。
• 案例2：建筑项目使用燃尽图跟踪进度，但未发现曲线上升是因新增任务未经变更控制，最终延误交付。

总结

PMP考试需区分术语细微差别，并结合实际场景选择方法论。工具使用需理解底层逻辑（如燃尽图反映剩余任务量），避免形式化套用。