索引：
敏捷产生的契机
——从历史上来讲，敏捷之所以能产生，有三个方面的因素：
软件危机
瀑布模型
互联网的兴起
敏捷的构成——轻量级方法
敏捷的诞生——核心价值和12条原则
敏捷产生的契机
软件危机
20世纪60年代以前，计算机刚刚投入实际使用，软件设计往往只是为了一个特定的应用而在指定的计算机上设计和编制，采用密切依赖于计算机的机器代码或汇编语言，软件的规模比较小，文档资料通常也不存在，很少使用系统化的开发方法，设计软件往往等同于编制程序，基本上是个人设计、个人使用、个人操作、自给自足的私人化的软件生产方式。
60年代中期，大容量、高速度计算机的出现，使计算机的应用范围迅速扩大，软件开发急剧增长。高级语言开始出现；操作系统的发展引起了计算机应用方式的变化；大量数据处理导致第一代数据库管理系统的诞生。软件系统的规模越来越大，复杂程度越来越高，软件可靠性问题也越来越突出。原来的个人设计、个人使用的方式不再能满足要求，迫切需要改变软件生产方式，提高软件生产率，软件危机开始爆发。
1968年，北大西洋公约组织（NATO）在联邦德国的国际学术会议创造软件危机一词。而1960年代中期开始爆发众所周知的软件危机，为了解决问题，在1968、1969年连续召开两次著名的NATO会议，并同时提出软件工程的概念。软件工程的概念也是那个时候提出的，现在仍是计算机相关学科的基础课程。
危机表现：
1. 超预算
2. 超时
3. 低效
4. 低质量
5. 不满足需求
6. 无法管理，难以维护代码
7. 永远无法交付
为了试图解决这个问题，产生过很多过程和方法论，而且在不同角度和程度上，取得一定成功。通常来说，越大型的复杂的不熟悉业务领域的项目，尤其会遭遇更大的难以预测的问题。
瀑布模型为代表的软件开发方法论
瀑布模型是将软件生存周期的各项活动规定为按固定顺序而连接的若干阶段工作，形如瀑布流水，最终得到软件产品。该模型正式第一次提出，是在1970年。在Winston Royce的文章中，他把瀑布模型认做是有瑕疵不工作的一个模型。直到80年代早期，瀑布模型一般被指代为软件开发方法或者过程的典型。
瀑布模型分为五个大的阶段：需求分析——设计——实现——验证——维护。相邻的两个阶段互为唯一的输入输出。能进入下一阶段的要求是，上一阶段严格完成，并得到审查和验证。瀑布模型不鼓励回顾和修订已经完成的流程阶段。如果审查确认到有可能的变化，会有正式的变更流程。
支持瀑布模型的论点
软件开发早期阶段的时间投入会影响到后期阶段的经济支出。越是在软件开发周期早期修复bug所需要的时间和努力乃至经济成本，都要远远低于在后期修复同样这个bug。极端的例子，如果程序设计出了问题，注定无法实现或者集成，如果在设计阶段发现并解决，成本要远远低于把程序都实现出来之后。
这是预先大量设计和瀑布模型的中心思想。在需求分析和设计阶段花的时间都是值得的，会节省大量后期的时间和努力。只要确保前期阶段百分百完成，并绝对正确，就可以进入下一阶段。需求应该在设计之前绝对的不变和稳定，一旦程序员开始实现和编码了，设计就不能变，否则他们就实现了错误的设计，努力白白浪费了。
另外一个支持的观点是，在不彻底设计和文档的方法论中，一旦有团队成员在项目完成之前离开，知识就会丢失，而项目会因此受伤害。瀑布模型要求提供详尽的设计文档，新的团队成员甚至整个团队都可以从中获益。
瀑布模型模型简单、线性、直观、容易理解，甚至有纪律性。提供非常容易识别的里程碑。所以瀑布模型一度成为软件开发过程的首选入门模型。
反对瀑布模型的观点
这是一个完美的模型，当需求稳定，设计者可以完全遇见所有的问题，产生正确的设计，实现者完全遵守设计，精确实现，平滑集成。然而：对于任何一个项目，不可能在进入下一阶段前，完美完成当前阶段。
客户不看见可以工作的软件系统，不会很清楚自己的需求是什么？一旦需求在设计完成之后改变，就意味着设计需要修改，也意味着设计的努力白费。越是在生命周期后期发生需求变化，浪费越大。
另外一个忽视的地方，客户在实现前无法完全感知到新技术的能力，依靠“觉得可能”来定义需求和期望。这对于设计的影响是，他们会简单认为这就是需求，会有简单的设计来复制已有系统，或者没有完全应用新技术的能力。而一旦客户发现新技术的能力，就会倾向于改变需求。一个潜在的解决方案是，有经验的程序员会不断的重构，模块化，抽象来应对可能的变化。但这只是实现层面的，不是方法论和过程层面的。
瀑布模型强调文档的作用，并要求每个阶段都要仔细验证。但是，这种模型的线性过程太理想化，已不再适合现代的软件开发模式。这是敏捷产生的第二个契机。
互联网的兴起
敏捷产生的第三个契机是互联网的兴起。客户面对强大的市场竞争，需要尽快的投放市场，以验证和证实市场需求，并根据用户的反馈及时地调整需求和策略，这需要有能快速实现和帮助验证的软件过程来帮助，传统的响应很慢的瀑布模型显然是不合时宜的。而敏捷提供了一种可能，随时停止项目系统的开发，提交给客户的仍然是个可以工作的软件。
敏捷的构成
轻量级方法
什么叫轻量级方法？相对比重量级方法而言，只有一些规则和实践需要遵守，而且更容易遵守。轻重之分，也是交付频率的分别。从上个世纪90年代开始，一些轻量级方法开始涌现，反对基于瀑布模型的重量级方法，轻量级方法的拥护者开始宣称要回归到软件开发出现早期的开发实践上。
XP极限编程
软件开发在90年代受到两个大的因素影响：对内来说面向对象变成开始取代面向过程编程；对外，互联网泡沫导致快速投向市场以及公司的快速发展成为关键商业因素；快速变化的需求需要短的产品交付周期，这与传统软件开发流程并不兼容。
极限编程旨在提高软件质量，和对客户需求变化的响应性。何谓“极限”？做到极致。举个例子，哪怕是一点点增量的改变，都会先写测试；为了验证哪怕一小块代码的功能，也会编写自动化测试，而仅仅是测试更大尺寸的功能。
因为跟客户交流是好的，所以要推到极致，所以要跟客户坐在一起工作。
因为持续review代码是好的，所以要推到极致，所以要每天都做code reivew，要结对。
因为项目越早集成是好的，所以要推向极致，所以要持续集成，要每一次提交代码都触发集成。
FDD特性驱动开发
特性驱动开发混合众多业界公认的最佳实践，目标在于在有限的时间内，向客户交付切实的价值和可以工作的软件。包括五个过程：整体模型、列表、计划、设计和构建特性。第4和第5阶段是一个迭代的过程，迭代周期一般为2个星期。这样经过不断的迭代，不断的实现功能集中的功能。每一个里程碑的时候进行评估、回顾。并考虑下一个里程碑的继续，直到最后项目的完成。
敏捷的诞生
2001年2月，Martin Fowler(敏捷开发方法的创始人之一，现为ThoughtWorks公司的首席科学家)，Jim Highsmith(2010年加入ThoughtWorks)等17位著名的软件开发专家齐聚在美国犹他州雪鸟滑雪圣地，举行了一次敏捷方法发起者和实践者的聚会。在这次会议中，他们讨论了这些轻量级方法，发现了彼此方法的共性：
团队能力
开发实践
客户协作
过程适应性
最后他们正式提出了Agile(敏捷开发)这个概念，并共同签署了《敏捷宣言》。
敏捷宣言
核心价值
个体和交互胜过过程与工具
人是软件开发中最重要的因素，开发团队要能做到团结协作，人与人面对面的交流、沟通，是最高效的途径。
可以工作的软件胜过面面俱到的文档
比起在客户会议上只是向客户展示文档，时刻可以运行和提交的软件，更有价值更受欢迎。
客户协作胜过合同与谈判
承认需求是无法在软件开发周期的早期阶段完全收集清楚的，所以持续的客户参与和沟通非常重要
响应变化胜过遵循计划
敏捷开发注重快速响应变化，以及持续交付价值
敏捷是一种价值观，“胜过”不是好的意思，是价值观取向的体现。敏捷认为右边的各项有其价值，但敏捷更重视左边各项的价值。
在代表敏捷联盟介绍宣言的时候，Jim Highsmith解释敏捷运动并不是反对方法论：
敏捷运动并不是反方法论的，实际上，我们许多人希望能重新建立方法论这个词的公信力。我们想恢复一种平衡。我们拥抱建模，但不是只为了画些图纸填满落满灰尘的公司仓库。我们拥抱文档，但并不是编写动辄上百页从不维护或者很少试用大部头。我们做计划，但我们意识到在混乱的环境中做计划的限制。那些把XP和Scrum或者其他敏捷方法论的提倡者认做是黑客的人，是对于方法论和黑客这个词的最初定义出于无知。
12条原则
1. 通过快速交付有用的软件让客户满意
2. 欢迎变化的需求，即使变化发生在开发阶段这么晚
3. 频繁交付可以工作的软件（几周而不是几个月）
4. 在业务人员和开发者之间存在每日紧密的沟通
5. 项目由自我驱动的个人共同参与，他们应该得到信任
6. 面对面的对话是沟通的最好形式
7. 可以工作的软件是进度的主要衡量标准
8. 可持续的开发节奏，能够维持不变的步调
9. 对技术卓越和良好设计的持续关注
10. 简单性是本质——最大化未完成工作数量的艺术
11. 自组织团队
12. 对变化的环境有规律的适应
写在后面：
敏捷开发方法的核心思想概括起来，是“以人为本”和“响应变化”。
以人为本
敏捷方法认为，人是软件开发中最重要的因素。敏捷开发的理念是充分的信任团队能够很好的完成任务，它们注重调动团队的能动性，以积极、愉悦、乐观的心态完成软件开发，并致力于提升团队的能力。这是敏捷项目管理的主题。
对于“管理者”——努力“激发”团队:
通过目标来牵引团队自主工作
帮助团队提供资源，排除障碍
营造团队自我管理的工作氛围
作为教练辅导团队进步
基于简单原则的管理，原则简单但必须被遵守
对于团队成员——“全方位的积极参与者”:
共同参与计划制定和任务安排
团队协作贯穿工作始终
提升沟通效率
关注团队目标，共担责任
能力要求更广，主动学习适应岗位要求
响应变化
传统的软件开发强调的是足够清晰的需求，并制定详细的文档，按照预定的计划逐一进行开发、测试。这样的方式在制定好计划之后拒绝变化，无法应对市场的变化和客户对需求的实时更改，后续的维护必将会付出巨大的代价。
而敏捷方法则是以最简的方式来迎接变化，客户在整个开发过程中都是参与者，开发团队能够在最短的时间内得到市场的反馈，不断响应需求的变更，从而使得最终的产品能够充分的符合客户的要求，并持续交付有价值的软件。
ThoughtWorks的敏捷开发通过逐步细化、迭代前进的方式，分阶段地将需求予以实现。比如说，我们先从整体功能规划中定位出一小部分核心功能，打造能基本运转、对用户有价值的最小可用产品（Minimum Viable Product，MVP），然后迅速迭代开发，听取用户反馈，及时调整功能规划。参考阅读：项目管理中的敏捷实践
本文作者万学凡，ThoughtWorks首席咨询师，武汉。作者保留本文一切权利，未经许可请勿转载。