敏捷开发，Agile Development，就是指能够在需求迅速变化的情况下快速开发软件。我们接触最多敏捷实践方式有：极限编程（XP）、结对编程、测试驱动开发（TDD）等。

追究敏捷的历史，就必须要提到著名的敏捷开发宣言，2001年，17位业界专家（其中包括我们非常熟悉的Martin, Martin Fowler）组成了一个敏捷联盟，并且创建了一份敏捷联盟宣言，宣扬了4条核心价值观：

1， Individuals and interactions over processes and tools（人和交互重于过程和工具）

2，Working software over comprehensive documentation（可以工作的软件重于易于理解的文档）

3，Customer collaboration over contract negotiation（客户合作重于合同谈判）

4，Responding to change over following a plan（响应变化重于遵照计划）

此外，还有公开了12条敏捷软件开发的规则。

1，Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

尽早地、持续地交付有价值的软件来满足客户的需求

2，Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

欢迎需求的变化，即使是项目后期的变更。敏捷过程能够驾驭变化，为客户带来竞争优势

3，Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

经常交付可以工作的软件，时间间隔越短越好

4，Business people and developers must work together daily throughout the project.

整个项目开发期间，业务人员与开发人员应该工作在一起

5，Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

围绕斗志高昂的人构建项目，给他们提供所需的环境，满足他们的需要，并信任他们

6，The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

最有效的信息传达方式和与团队相处的方法是面对面交流

7，Working software is the primary measure of progress.

可以工作的软件是进度主要的度量标准

8，Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

敏捷过程提倡可持续开发。投资方、开发者和用户应该总是保持一致的步伐

9，Continuous attention to technical excellence and good design enhances agility.

不断追求卓越技术和良好设计有助于加强敏捷性

10，Simplicity--the art of maximizing the amount of work not done--is essential.

简单--尽量减少工作量是非常重要的

11，The best architectures, requirements, and designs emerge from self-organizing teams.

最好的架构、需求和设计都出自于自我组织的团队

12，At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

每隔一段时间，团队都要反思如何更有效率，并相应地调整自己的行为

更详细可参照敏捷联盟的官方网站（http://www.agilealliance.org/）和敏捷开发宣言网站（http://www.agilemanifesto.org/）。

从以上的4条价值观和12条敏捷开发的规则中，我们可以得出敏捷开发更强调的是，人与人之间的交互,包括程序员之间，程序员和客户之间的沟通，程序员不再是我们经常形容的代码工人等机械式的个体，受控于大量的规则文档和各种强大的工具。敏捷开发注重的是程序员的个人能力和沟通协作能力，一个具有良好沟通能力的程序员组成的团队更有可能获得成功，结对编程的方式就是利用两个人的紧密协作达到1+1>2的效果。敏捷开发不在受制于庞大笨重的工具，合适的工具对成功来说是很重要的，但是过于庞大笨重的工具就和缺少工具一样，都是不好的。项目中最常用的就是源代码管理工具，实际使用过程中发现昂贵的工具未必能体现其价值，有些免费开源的工具已经足够适用于项目的需求了。

传统的软件开发，非常注重文档的作用，文档有助于软件的后续维护，有助于客户对产品的理解。但是过多的文档比过少的文档更糟，文档太多就需要花费大量的时间去编写和维护。对于需求经常变更的项目，维护庞大的文档本身就是一场噩梦。在敏捷开发中，编写和维护一份简短的系统和结构方面的文档已经足够了。对于后续维护，更细致的说明，应该体现在代码中，设计简单良好、可读性强的代码对程序员来说是比设计文档更直观更容易理解的文档，软件技术专家Jack Reeves曾经说过：“实际上满足工程设计标准的唯一软件文档，就是源代码清单”。所以在项目中，直到迫切需要时才编制文档，按照需求开发可运行的软件才是敏捷开发的重点。

一般的软件项目合同中规定的都是整体的要求，但是我们知道软件开发中有太多的不确定性，这就会带来大量的需求变更，大的变更在项目开发过程总也是很正常的。经常有这样的案例：客户给我们需求，开发团队埋头苦干数月后完成交付客户，但是客户非常不满意，更有甚者，和客户的理解相差太大而导致项目失败。所以敏捷开发强调在开发过程中，保持和客户的沟通，面对面的沟通，完成模块时，应该马上请客户进行验收，这样项目结束的时候，验收的工作也基本完成了，极大地降低了项目失败的风险。敏捷中，强调随时应对变化的能力也会让开发团队有意识地设计和开发可扩展性好、可维护性好的软件。

敏捷开发强调了程序员的能力，极大地发掘程序员个体的潜力和整体的协作来保证项目的成功，而不是靠文档、制度、工具等。

我非常推崇敏捷软件开发模式，这样的方式可以极大地调动程序员的积极性、极大地加强团队的凝聚力。

如果你对敏捷软件开发有兴趣，请关注敏捷开发相关的各种实践，给大家推荐一本敏捷开发的图书，由Robert C. Marting（敏捷宣言发起者之一）编写的经典著作：

如果想深入关注敏捷的动态，也请关注发起敏捷宣言的各位大师们的著作，他们是：

Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas。