软件开发模型系列五敏捷开发 —— 从按计划行事到拥抱变化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 Manifesto2001 年 2 月由 17 位软件从业者在犹他州雪鸟滑雪场共同签署。这 17 位签署者包括 Kent BeckXP 创始人、Ken Schwaber 和 Jeff SutherlandScrum 联合创始人、Ward CunninghamWiki 发明人、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流驱动的可视化方法强调限制 WIPExtreme 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 Agile7、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 —— 当敏捷有了具体的实施框架