【Software Engineering】Agile Development，Built for Change
软件开发模型系列（五）：敏捷开发 —— 从"按计划行事"到"拥抱变化"
2001 年 2 月，17 个"软件方法论轻量级选手"在犹他州雪鸟滑雪场开了一次会。他们来自不同的方法论阵营——XP、Scrum、DSDM、Crystal、FDD——但都有一个共同的对手：文档驱动的重型开发流程。这次会议的结果是一份只有 68 个英文单词的宣言。它永久改变了软件行业。
原文如下：
Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan随后还有一句总结：
That is, while there is value in the items on the right, we value the items on the left more.
1、什么是敏捷开发
敏捷开发（Agile Development）不是某一种具体的流程或方法，而是一套价值观和原则体系。它不告诉你"每天几点开会、文档要几页"，而是告诉你在面对选择时，优先考虑什么。
敏捷的核心载体是《敏捷宣言》（Agile Manifesto），2001 年 2 月由 17 位软件从业者在犹他州雪鸟滑雪场共同签署。这 17 位签署者包括 Kent Beck（XP 创始人）、Ken Schwaber 和 Jeff Sutherland（Scrum 联合创始人）、Ward Cunningham（Wiki 发明人）、Martin Fowler（《重构》作者）等。
有意思的是，"Agile"这个名称还有个插曲：此前这群人一直用 “Light” 或 “Lightweight” 来形容自己的方法论。Alistair Cockburn 当时说了一句话：“我不介意我们的方法被叫做轻量级，但我不想被叫做一个参加轻量级方法论大会的轻量级选手。” 于是他们选了 “Agile”。
2、敏捷宣言的四条价值观
敏捷宣言总共只有 68 个英文单词。注意每条表述中的关键措辞——不是"拒绝右边"，而是"更看重左边"：
也就是说，右栏（灰）中的项目固然有价值，但我们更看重左栏（蓝）中的项目。
这四句话的深层含义值得逐一理解：
2.1、个体与互动 高于 流程与工具
不是因为流程和工具不重要，而是因为再好的工具也不能替代面对面的沟通。把 10 个人塞进一个房间、给他们一块白板，往往比给他们配置了最先进项目管理系统的独立工位更高效。
2.2、可工作的软件 高于 详尽的文档
不是因为不要文档，而是因为文档不能替代可运行的系统来展示真实状态。一份 200 页的需求文档描述的用户体验，比不上一个可点击的原型让用户玩 5 分钟。文档够用就好，过度的文档是一种浪费。
2.3、客户合作 高于 合同谈判
不是因为不要合同，而是因为合同不能替代持续的沟通来确保项目成功。签订时的共识随着时间会漂移，唯有持续合作才能保证双方始终在同一方向上。
2.4、响应变化 高于 遵循计划
不是因为不要计划，而是因为计划的精度随着时间推移指数级衰减。一周内的计划可以很精确，一个月后的计划已经相当模糊，半年后的计划基本是科幻小说。与其死守一个失效的计划，不如持续调整方向。
3、敏捷的十二条原则
宣言之下有十二条原则，每一句都有极强的现实指导意义：
- 尽早持续交付有价值的软件，让客户满意——最高优先级
- 欢迎需求变更，即使是在开发后期——把变化视为竞争优势
- 频繁交付可工作的软件，几周到几个月，越短越好
- 业务人员和开发者每天在一起工作
- 围绕有动力的个体构建项目，给他们环境、支持和信任
- 面对面沟通是传递信息最高效的方式
- 可工作的软件是进度的首要度量标准
- 保持可持续的开发节奏，避免 burnout
- 持续关注技术卓越和良好设计——这是敏捷的基础，不是矛盾
- 简洁——少做，做对（最大化"不做"的工作量）
- 最好的架构、需求和设计出自自组织团队
- 定期反思如何更高效，然后调整行为
这十二条中，第 9 条常常被忽视。很多人对敏捷有一个误解：“敏捷就是不要设计、不要文档、快点写代码”。实际上，没有技术卓越和良好设计，敏捷团队撑不过前几个迭代就会陷入代码泥潭。
4、敏捷 vs 瀑布：世界观的根本分歧
瀑布模型的世界观： 需求是可以被事先完整获取的 变更是可以被控制的 计划是可以被严格执行的 成功 = 在规定时间和预算内交付规定范围 敏捷开发的世界观： 需求是在对话中浮现的 变更是不可避免的，应该被拥抱 计划是需要持续调整的 成功 = 交付了对用户最有价值的东西这不是"谁对谁错"的问题。如果你的项目是建一座桥，瀑布思维是对的，物理规律不会变。如果你在做一款社交 APP，用户想要什么连用户自己都说不清，敏捷思维更有用。
5、常见的敏捷落地框架
敏捷是"道"，不是"术"。它告诉你方向，但不告诉你具体怎么做。因此出现了一系列落地框架：
| 框架 | 特点 |
|---|---|
| Scrum | 时间盒驱动的迭代框架，有明确角色和仪式 |
| Kanban | 流驱动的可视化方法，强调限制 WIP |
| Extreme Programming (XP) | 工程实践最极致的敏捷方法（TDD、结对编程、持续集成） |
| Crystal | 轻量级、按项目规模自适应调整的方法族 |
| FDD (Feature-Driven Development) | 以功能特性为单元的计划驱动敏捷方法 |
| DSDM | 强调商业目标对齐的完整敏捷框架 |
Scrum 和 Kanban 是今天最主流的两大框架，本系列后续篇章将分别详细介绍。
6、敏捷的局限与常见误区
误区一：敏捷 = 不要文档
敏捷说的是"可工作的软件高于详尽的文档"，不是"不要文档"。实际敏捷团队依然会写文档——但写的是"刚好够用"的文档（Just Barely Good Enough），而不是为写而写。
误区二：敏捷 = 没有计划
敏捷团队计划得比瀑布团队更频繁——每天的站会是日计划，Sprint Planning 是两周计划，Release Planning 是季度计划。区别在于敏捷计划是基于实际数据的持续调整，而非一次性写完锁死。
误区三：敏捷 = 又快又便宜
敏捷的价值在于做对的事情，而不是更快地做错的事情。如果一个团队声称在实践敏捷但取消了所有测试、Code Review 和设计讨论——<那不是敏捷，那是"仓促开发"。
真正的局限
- 对团队自律要求高：没有外部流程约束，需要内部驱动力 - 不适合固定合同和外包场景：甲方要的是固定价格和交付范围 - 在大型组织中推行困难：需要组织结构、绩效考核、财务流程全面调整 - Scaling Agile 是公认的老大难问题：5 人团队敏捷 ≠ 500 人团队敏捷Scaling Agile
7、AI 时代的敏捷
敏捷宣言写于 2001 年，距离今天的 AI 编程工具已经过去了二十多年。但有趣的是，敏捷的核心原则与 AI 编程的"正确使用姿势"惊人地一致：
敏捷原则 AI 编程中的对应 频繁交付 用 AI 生成小模块，逐块 Review，不要一次丢完整需求 拥抱变化 AI 生成不符合预期 → 调整 Prompt → 再生成 → 循环 面对面沟通 和 AI 的沟通本身就需要"对话式"而非"指令式" 简洁 让 AI 写刚好够用的代码，不要过度工程 持续关注技术卓越 AI 输出需要人 Review，代码质量不能交给概率 定期反思 Review AI 的产出质量，持续改进 Prompt 和流程从这个意义上说，AI 编程工具的"最佳实践"早在 2001 年就已经被写好了——我们需要做的不是发明新东西，而是把敏捷原则应用到人-AI 协作这个新场景上。
Agile + AI ≠ AI 替代敏捷，而是 AI 放大了敏捷。
AI 让每一次"计划 → 编码 → 验证 → 反馈 → 调整"的循环速度从几天缩短到几分钟，因此敏捷开发的核心思想——快速反馈、持续交付、拥抱变化——在 AI Coding 时代变得比以往任何时候都更加重要。
8、本篇要点速记
敏捷开发 = 一套价值观和原则体系，不是具体流程 诞生于 2001 年，17 位方法论先驱在雪鸟滑雪场签署敏捷宣言。 四个价值观：个体互动 > 流程工具，可用软件 > 详尽文档， 客户合作 > 合同谈判，响应变化 > 遵循计划 十二条原则：从持续交付到定期反思，覆盖了敏捷的完整哲学 优点 → 快速响应变化、客户持续参与、持续交付价值 局限 → 需要团队自律、不适合固定合同、大规模推行困难一句话：敏捷不是"做什么"的说明书，而是"怎么选"的指南针。
上一篇：迭代开发
下一篇：Scrum —— 当敏捷有了具体的实施框架