7.3.7 敏捷方法
本课核心知识点整理
敏捷为什么出现
前面的很多模型都担心需求变化：瀑布尤其怕变化，V 模型虽然提前考虑测试，但本质仍偏线性。现实项目中，需求变化、客户反馈、市场节奏和技术不确定性都很常见。敏捷方法用“小步快跑”的方式应对变化：短周期交付、客户直接参与、团队快速沟通、计划随变化调整。
课堂也指出：敏捷在有些教材中归为开发方法，有些归为开发模型；在软件设计师这门课中，把它放在开发模型部分复习即可。
敏捷的统一思想
| 思想 | 解释 |
|---|---|
| 小步快跑 | 以短周期迭代交付可运行版本 |
| 客户参与 | 谁使用系统，谁配合开发反馈 |
| 合作为重 | 团队内部、团队与客户都要沟通合作 |
| 适应性计划 | 一旦需求变化，快速调整计划 |
| 自动化测试 | 用自动化提高反馈速度和回归效率 |
| 持续集成 | 小版本按日甚至按小时集成和交付 |
敏捷不是“没有计划”，而是计划要能随着反馈不断调整。
XP：软考常考的敏捷方法
XP 是 Extreme Programming，极限编程，不是 Windows XP。课堂强调软件设计师中常考 XP，它有四大价值观、五大原则和十二项最佳实践。
四大价值观
| 价值观 | 含义 |
|---|---|
| 沟通 | 团队内部、团队与客户持续沟通 |
| 简单 | 尽可能用简单设计满足当前需求 |
| 反馈 | 有问题尽早反馈，快速调整 |
| 勇气 | 有勇气面对变化、重构和修改 |
五大原则
| 原则 | 含义 |
|---|---|
| 快速反馈 | 尽早发现问题 |
| 简单性假设 | 不为未确认的未来复杂性过度设计 |
| 逐步修改 | 小步调整，而不是一次性大爆炸修改 |
| 提倡更改 | 把变化看作正常输入 |
| 优质工作 | 保持质量和可持续节奏 |
十二项最佳实践
| 实践 | 解释 |
|---|---|
| 计划游戏 | 快速制定和调整计划，应对变化 |
| 小型发布 | 尽早向用户交付可运行版本 |
| 隐喻 | 用共同理解的比喻帮助沟通 |
| 简单设计 | 只处理当前需求，保持设计简单 |
| 测试先行 | 先写测试，再写程序 |
| 重构 | 重新审视并改进设计和代码结构 |
| 结对编程 | 两人协作，一人写一人看，快速发现问题并降低人员流失风险 |
| 集体代码所有制 | 团队成员都可以理解和修改代码 |
| 持续集成 | 频繁集成，按日甚至按小时提供可运行版本 |
| 每周 40 小时工作制 | 保持优质工作和可持续效率 |
| 现场客户 | 用户代表全程配合开发团队 |
| 编码标准 | 统一代码风格，降低沟通和维护成本 |
敏捷实践为什么替代旧做法的一部分
| 传统痛点 | 敏捷实践的回应 |
|---|---|
| 需求变更反馈慢，等几天才确认 | 现场客户和客户协作 |
| 缺陷发现晚 | 测试先行、自动化测试、持续集成 |
| 一个人离职导致代码没人懂 | 结对编程、集体代码所有制 |
| 版本交付周期太长 | 小型发布、短迭代 |
| 设计越来越乱 | 重构、简单设计、编码标准 |
敏捷不是银弹。它更适合小团队、变化快、客户能持续参与的项目；如果项目必须严格强文档审批、客户无法参与、监管流程极重，就需要结合传统过程管理。
例题
敏捷方法的典型思想是：
软件开发模型中的 XP 指：
先写测试代码，再编写具体程序，属于 XP 的：
自查要点
- 敏捷为什么能更好适应需求变化？
- XP 的四大价值观是什么？
- 结对编程除了发现问题，还能降低什么风险？
- 测试先行和持续集成分别解决什么问题？
- 敏捷适合什么样的团队和项目？