一、敏捷宣言核心（必考基础）
1. 四大核心价值观（灵魂）
敏捷宣言的本质是倡导一种"敏捷思维模式"，而非具体实践，四条价值观需精准记忆：
- 个体和交互 胜于 流程和工具
- 可用的软件 胜于 完备的文档
- 客户协作 胜于 合同谈判
- 响应变化 胜于 遵循计划
- 关键原则：价值观是指导思想，实践（如Scrum、看板）是落地方式，不可本末倒置。
2. 十二条敏捷原则（行动准则）
核心原则提炼（高频考点）：
- 早期和持续交付有价值的软件，让客户满意；
- 欢迎变化的需求，通过敏捷流程拥抱变化；
- 频繁交付可工作软件（迭代周期通常2-4周）；
- 业务人员与开发人员每天一起工作；
- 围绕激励个体构建项目，给予信任和支持；
- 面对面沟通是最高效的信息传递方式；
- 可工作的软件是进度的主要衡量标准；
- 敏捷过程倡导可持续的开发节奏；
- 持续关注技术卓越和良好设计；
- 简洁（最小化不必要工作）是关键；
- 自组织团队能产出最佳架构、需求和设计；
- 团队定期反思如何提高效率，并调整行为。
二、敏捷核心角色与职责（高频考点）
敏捷团队角色分工明确，核心是"各司其职、协作高效"，避免角色混淆：
1. 产品负责人（PO）
- 核心职责：管理产品待办列表（优先级排序、需求澄清、验收标准定义）；
- 关键动作：与客户/相关方对齐愿景，确保团队开发"正确的产品"；
- 易错点：PO负责优先级，不负责技术实现；需求变更需通过待办列表调整，而非直接命令团队。
2. Scrum Master（敏捷教练/主管）
- 核心职责：移除团队障碍、保护团队自组织、引导敏捷实践落地；
- 关键动作：辅导团队遵守敏捷原则，解决协作/资源障碍，优化会议效率；
- 易错点：Scrum Master是"服务型领导"，不分配任务、不做技术决策，而是赋能团队。
3. 敏捷团队
- 核心特征：自组织（自主分配任务、解决内部问题）、跨职能（具备交付完整功能的所有技能）、通才型（T型人才，精通1-2领域+掌握其他领域基础）；
- 关键动作：迭代内交付潜在可交付增量，持续协作、自我改进；
- 易错点：自组织≠无纪律，团队需对交付结果负责；集中办公不是必需（分布式敏捷可通过工具协作）。
三、敏捷核心会议管理（避坑重点）
敏捷会议强调"高效、聚焦、产出导向"，避免形式化，核心会议如下：
| 会议名称 | 核心目的 | 时间盒 | 关键注意事项 |
|---|---|---|---|
| 每日站会 | 同步进度、识别障碍、规划当日工作 | 15分钟 | 不讨论技术细节、不解决问题（障碍会后单独处理）；聚焦"做了什么/要做什么/阻碍是什么" |
| 迭代规划会 | 确定迭代目标、挑选待办项、分解任务 | 2小时/迭代周 | PO澄清需求优先级，团队估算工作量；目标需可达成、可验证 |
| 迭代评审会 | 演示增量成果、收集客户/相关方反馈 | 1小时/迭代周 | 聚焦"成果是否符合期望"，不纠结细节；反馈需记录到待办列表 |
| 迭代回顾会 | 反思迭代过程、识别改进点、制定行动项 | 1小时/迭代周 | 对事不对人，聚焦流程改进；行动项需明确责任人与期限 |
易错点避坑
- 会议超时：需严格遵守时间盒，偏离主题时Scrum Master及时引导；
- 相关方参与不足：评审会必须邀请客户/关键相关方，确保反馈及时；
- 回顾会无效：避免"只说不做"，行动项需跟踪落地。
四、敏捷核心实践（高频考点）
1. 变更管理（拥抱变化的落地）
- 核心逻辑：变更不是风险，而是优化机会，通过"优先级调整+渐进明细"应对；
- 实践方式：
- 变更需由PO评估业务价值，更新产品待办列表优先级；
- 迭代内尽量不引入重大变更（避免打乱节奏），重大变更可调整迭代目标或启动新迭代；
- 易错点：拥抱变化≠无底线接受，需平衡"价值与成本"，通过待办列表优先级筛选高价值变更。
2. 范围管理（渐进明细）
- 核心逻辑：敏捷不追求前期固定完整范围，而是"渐进明细、持续澄清"；
- 实践方式：
- 初期明确产品愿景和MVP（最小可行产品），迭代中逐步细化需求；
- 范围通过产品待办列表管理，按优先级分批交付；
- 易错点：前期不定义完整范围≠不规划，需明确核心价值和大致方向，避免盲目开发。
3. 风险管理（透明化+早应对）
- 核心逻辑：风险可视化、早识别、团队协作解决；
- 实践方式：
- 风险纳入产品待办列表或看板，确保全员可见；
- 每日站会同步风险状态，小风险团队自行解决，重大风险上报并调整优先级；
- 易错点：不依赖专门风险登记册，而是融入日常协作；避免"事后补救"，强调"事前识别+事中响应"。
4. 产品待办列表（Backlog）管理
- 核心逻辑：唯一的工作来源，动态调整、优先级驱动；
- 关键要求：
- 条目需清晰、可估算、可验收（符合INVEST原则）；
- PO负责持续梳理（Refinement），确保待办项足够细化供团队挑选；
- 易错点：待办列表不仅包含用户故事，还可包含缺陷、技术债务、风险应对任务。
五、敏捷常见易错点（避坑指南）
- 敏捷宣言是"价值观/思维模式"，不是具体实践（如每日站会、用户故事是实践，不是宣言本身）；
- 自组织团队≠无领导，Scrum Master是"障碍清除者"，不是"管理者"；
- 集中办公是"加分项"，不是"必需项"（分布式敏捷可通过协作工具实现高效沟通）；
- PO负责"做什么/优先级"，团队负责"怎么做/何时做"，不可混淆；
- 迭代评审会聚焦"成果反馈"，不是"计划讨论"；回顾会聚焦"流程改进"，不是"成果批判"；
- 敏捷不排斥文档，而是"精简必要文档"，优先交付可工作软件。
六、补充核心知识（互联网必备）
1. 敏捷框架区分（文档未详述，补充高频）
- Scrum：最常用，强调迭代交付、角色明确（PO/SM/团队）、会议固定；
- 看板：聚焦"可视化工作流+限制在制品（WIP）"，适合需求稳定、流程优化场景；
- XP（极限编程）：强调技术卓越（持续集成、测试驱动开发），适合软件开发类项目；
- 混合型：整体预测型（如瀑布）+ 局部敏捷（如核心功能迭代开发），适合范围部分明确的项目。
2. INVEST原则（用户故事编写标准）
- Independent（独立）、Negotiable（可协商）、Valuable（有价值）、Estimable（可估算）、Small（小规模）、Testable（可测试）；
- 核心作用：确保用户故事清晰、可执行，减少迭代中的歧义。
结尾
敏捷的核心是"以客户价值为导向，通过协作与变化实现持续交付"，掌握以上知识点可覆盖考试80%相关考题。