考点频率 ：★★★★★（选择题必考，下午题案例分析也常出现）
难度 ：⭐⭐⭐
建议：重点掌握敏捷宣言的四项价值观和十二条原则、Scrum的"3355"框架、XP的核心实践，以及Scrum与XP的本质区别
1️⃣ 为什么需要敏捷开发？
前面我们讲了瀑布模型、增量模型、迭代模型、螺旋模型。这些模型有一个共同点：都是"计划驱动"的------先做详细的计划，再按计划执行。
但现实中的软件开发往往不是这样的：用户自己也不知道想要什么，等到看到东西才说"不对，我要的不是这个"；市场竞争瞬息万变，半年前的需求今天已经过时了。
于是，2001年，17位软件开发领域的专家聚集在美国犹他州的雪鸟滑雪胜地，共同签署了敏捷软件开发宣言（Agile Manifesto） 。从此，一种全新的开发理念诞生了：与其试图预测一切，不如拥抱变化。
2️⃣ 敏捷宣言：四项价值观
敏捷宣言的核心是四项价值观，这是敏捷开发的"宪法"：
| 左项（更重视） | 右项（也有价值） |
|---|---|
| 个体和互动 | 高于 流程和工具 |
| 可工作的软件 | 高于 详尽的文档 |
| 客户合作 | 高于 合同谈判 |
| 响应变化 | 高于 遵循计划 |
注意：敏捷不是不要文档、不要流程、不要计划------而是更重视左边的内容。文档"够用就好"，计划"能应对变化就好"。
3️⃣ 敏捷十二原则
在四项价值观的基础上，敏捷宣言还提出了十二条原则：
| 序号 | 原则 |
|---|---|
| 1 | 通过及早和持续地交付有价值的软件使客户满意 |
| 2 | 欣然面对需求变化，即使在开发后期也一样 |
| 3 | 经常地交付可工作的软件（周期越短越好） |
| 4 | 业务人员和开发人员每天一起工作 |
| 5 | 以积极的个人为核心，给予他们环境和信任 |
| 6 | 面对面沟通是最高效的信息传递方式 |
| 7 | 可工作的软件是进度的首要度量标准 |
| 8 | 敏捷过程提倡可持续的开发速度 |
| 9 | 持续追求技术卓越和良好设计 |
| 10 | 简洁------最大化未完成工作的艺术 |
| 11 | 最好的架构、需求和设计来自自组织团队 |
| 12 | 团队定期反思如何提高成效，并调整行为 |
软考记忆要点：原则1（早交付）、原则2（拥抱变化）、原则3（频繁交付）、原则7（可工作软件是进度标准）------这四个是选择题中最常考的原则。
4️⃣ Scrum：敏捷的"管理框架"
Scrum是一种轻量级的项目管理框架，它告诉你"什么时候开会、谁该参加、产出什么"，但不规定具体怎么写代码。
4.1 Scrum的"3355"框架
Scrum框架可以概括为 3个角色 + 3个工件 + 5个事件 + 5个价值观。
3个角色：
- 产品负责人（Product Owner）：负责定义和优先级排序产品待办事项列表，确保团队做最有价值的功能
- Scrum主管（Scrum Master）：负责促进Scrum活动，指导团队掌握Scrum框架，消除障碍
- 开发团队（Development Team）：自组织的跨职能团队，负责在每个冲刺结束时交付可用的产品增量
3个工件：
- 产品待办事项列表（Product Backlog）：按优先级排序的所有功能、缺陷和改进的列表
- 冲刺待办事项列表（Sprint Backlog）：团队计划在当前冲刺中完成的工作子集
- 产品增量（Increment）：每个冲刺结束时所有已完成工作的总和
5个事件：
- 冲刺（Sprint）：固定时长的迭代周期，通常2-4周
- 冲刺计划（Sprint Planning）：每个冲刺开始时，团队确定冲刺目标和计划
- 每日站会（Daily Scrum）：每天15分钟，同步进展、识别障碍、规划当日工作
- 冲刺评审（Sprint Review）：冲刺结束时，向利益相关者展示产品增量并获取反馈
- 冲刺回顾（Sprint Retrospective）：冲刺结束后，团队反思并识别改进领域
5个价值观 ：开放、勇气、尊重、专注、承诺
软考速记：Scrum的"3355"------3角色、3工件、5事件、5价值观。
5️⃣ 极限编程（XP）：敏捷的"工程方法"
如果说Scrum管的是"管理节奏"，那极限编程（Extreme Programming，简称XP）管的就是**"代码质量"** 。
XP由Kent Beck于1990年代末提出，强调短周期迭代、持续测试、快速交付可用软件。
5.1 XP的五大价值观
XP围绕五个核心价值观展开：
| 价值观 | 含义 |
|---|---|
| 沟通 | 团队成员与客户之间保持开放透明的沟通 |
| 简单 | 追求最简解决方案，避免过度设计 |
| 反馈 | 通过持续收集反馈及时调整产品方向 |
| 勇气 | 敢于尝试新方法，做出艰难决策 |
| 尊重 | 尊重团队成员和客户，建立互信文化 |
5.2 XP的核心实践（软考重点）
XP包含一系列具体的工程实践：
| 实践 | 说明 |
|---|---|
| 结对编程（Pair Programming） | 两名开发人员共同在一台机器上编码，提高质量、促进知识共享 |
| 测试驱动开发（TDD） | 先写测试用例，再写代码，确保代码通过测试 |
| 持续集成（CI） | 每次代码提交后自动构建和测试，快速发现冲突 |
| 重构（Refactoring） | 持续优化代码结构，提升可维护性 |
| 频繁交付 | 每几周交付一次可用功能 |
| 客户协作 | 与客户保持密切沟通，深入了解需求 |
| 集体代码所有制 | 任何开发人员都可以修改任何代码 |
软考速记 ：XP的核心实践------结对编程、TDD、持续集成、重构，这四个是最常考的。
6️⃣ Scrum vs XP：本质区别（软考核心考点）
这是软考中极易混淆的点，必须搞清楚：
| 对比项 | Scrum | XP |
|---|---|---|
| 本质 | 管理框架（管人、管事、管节奏） | 工程方法（管代码、管技术、管质量） |
| 关注点 | 项目管理流程 | 代码质量与工程技术 |
| 核心内容 | 角色、事件、工件 | 结对编程、TDD、持续集成、重构 |
| 告诉你什么 | 何时开会、谁参与、产出什么 | 如何写代码、如何测试、如何集成 |
| 适用场景 | 需求方向明确，变化频率中等 | 需求模糊，变化极快，对质量要求高 |
| 能否单独使用 | ✅ 可以 | ⚠️ 通常需要与Scrum等框架配合 |
一句话总结 ：Scrum是"管项目的"，XP是"写代码的"。实际项目中，很多团队用Scrum做项目管理，同时在编码环节采用XP的结对编程和TDD。
7️⃣ 敏捷开发的优缺点与适用场景
7.1 优点
| 优点 | 说明 |
|---|---|
| 快速响应变化 | 需求变更不再是噩梦，而是常态 |
| 用户参与度高 | 用户在每个迭代都能看到可运行的软件并提供反馈 |
| 风险可控 | 早期发现问题，早期修正 |
| 团队士气高 | 自组织团队，信任和授权 |
7.2 缺点
| 缺点 | 说明 |
|---|---|
| 管理难度大 | 需要团队高度协作和自组织能力 |
| 文档不充分 | 过度依赖口头沟通，人员变动时知识传承困难 |
| 不适合所有项目 | 对安全关键、合规要求严格的系统（如航天、医疗）不太适用 |
7.3 适用场景
| 适用场景 | 说明 |
|---|---|
| 需求不确定 | 用户需求模糊、经常变化 |
| 市场变化快 | 互联网产品、创业项目 |
| 需要快速试错 | 需要通过用户反馈快速验证产品方向 |
| 团队规模适中 | 通常5-9人的小团队 |
对比记忆：瀑布模型适合"需求明确、变化少"的项目；敏捷开发适合"需求模糊、变化多"的项目。
8️⃣ 经典例题
例题1：以下关于敏捷开发的说法中，正确的是（ ）。
A. 敏捷开发不需要任何文档
B. 敏捷开发的核心是"计划驱动"
C. 敏捷开发强调"响应变化高于遵循计划"
D. 敏捷开发只适用于小项目
解析 ：A错误------敏捷不是不要文档，而是"够用就好"；B错误------敏捷是"适应式"而非"计划驱动"；D错误------敏捷适用于各种规模的项目，但通常小团队更易实施。C正确，这正是敏捷宣言的四项价值观之一。选 C。
例题2：以下哪个实践属于XP（极限编程）而非Scrum？
A. 每日站会
B. 产品待办事项列表
C. 结对编程
D. 冲刺评审
解析 ：每日站会、产品待办事项列表、冲刺评审都是Scrum框架中的事件或工件。结对编程是XP的典型工程实践。选 C。
例题3（判断）：Scrum是一种工程实践方法，主要关注如何编写高质量的代码。（ ）
解析 ：错误。Scrum是管理框架，关注项目管理的节奏和流程；XP才是关注代码质量和工程实践的方法。
9️⃣ 记忆口诀
敏捷宣言四价值：个体互动、工作软件、客户合作、响应变化。
敏捷原则十二条：早交付、拥抱变、频繁交、自组织。
Scrum框架3355：三角色、三工件、五事件、五价值。
XP实践要记牢：结对编程、TDD、持续集成、重构好。
🔟 小测验（评论区对答案）
某互联网创业公司正在开发一款新产品，用户需求不明确，市场变化快。公司希望每个迭代都能让用户试用并反馈。以下哪种开发方式最适合？
A. 瀑布模型
B. 螺旋模型
C. 敏捷开发（Scrum + XP）
D. 增量模型
🔔 本专栏日更，点击头像 → 专栏《软考中级高频考点》订阅，第一时间接收新内容
#软考中级 #软件设计师 #敏捷开发 #Scrum #极限编程 #XP #软件工程