备考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加速交付）。
| 原则分类 | 关键实践工具 | 典型场景示例 |
|---|---|---|
| 需求响应（2,3,4） | 用户故事、看板、冲刺评审 | 政策变化导致需求优先级调整 |
| 团队协作（5,6,11） | 每日站会、自组织任务分配 | 跨职能团队协作开发复杂模块 |
| 质量保障（7,9,10） | TDD、持续集成、代码重构 | 高频交付中维持代码可维护性 |
| 流程优化（1,8,12） | 迭代回顾、可持续节奏规划 | 避免项目后期因疲劳导致延期 |
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人）自组织完成冲刺目标。
流程上：
（1）冲刺计划会议（Sprint Planning）
- 始于冲刺计划会议（Sprint Planning）选定本周期任务形成冲刺待办列表（Sprint Backlog）
3、故事点
这里有一个很重要的考点就是：故事点，故事点作为相对工作量单位，通过量化用户故事复杂度帮助团队预估冲刺代办列表的容量。
在执行中，故事点附着于代办任务形成可视化优先级排序，并通过燃尽图跟踪进度偏差，最终为冲刺评审提供数据支撑（承诺故事点vs实际完成数），驱动团队持续校准估算精度并优化工作流程。
故事点如同"敏捷标尺"
- 敏捷估算故事点方法的对比表格：
| 方法名称 | 流程要点 | 适用场景 | 核心优势/特点 |
|---|---|---|---|
| 计划扑克 | 使用斐波那契数列卡片(1,2,3,5,8,13)，PO澄清需求后独立选牌→同步亮牌→差异大时讨论重估 | 需求复杂度高、需多视角讨论的团队 | 结合专家意见/类比/分解方法，通过同步亮牌机制避免"专家主导"偏差 |
| 敏捷估算2.0 | 采用相对排序法：T恤尺码(XS/S/M/L/XL)或动物尺寸分组→转换为数值范围 | 大规模待办列表的初期优先级划分 | 减少细节争论，通过类比提升效率（比绝对数值快3-5倍） |
| 亲和估算 | 故事卡视觉化归类→移动卡片至"小/中/大"或数值范围→达成共识后分配故事点 | 分布式团队/远程协作场景 | 利用群体智慧快速收敛意见（平均收敛时间比传统会议缩短40%） |
| 理想人天 | 估算无干扰状态下的理想完成时间→转化为故事点（需校准团队基准） |
（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考试需区分术语细微差别，并结合实际场景选择方法论。工具使用需理解底层逻辑（如燃尽图反映剩余任务量），避免形式化套用。
