敏捷开发是软件开发的一种重要方法。
通过浏览网站，我对于敏捷开发有了更多的认识。所谓的敏捷，指的是在软件开发过程中，能够敏捷地灵活地响应变化。在软件开发过程中，变化不断地在发生。比如新需求的提出，原需求的更新，团队接受了一种新方法，采纳了一项新技术等等都会造成变化。这些变化都会对开发的软件产品以及项目本身造成影响。我们必须接受变化，因为它是软件的心脏与灵魂。应对这些变化，我们就需要考虑所需的成本费用。传统方法（engineering methodologies）在项目规模比较小时，能够比较容易地适应变化。随着项目的进行，在经过了一段时间的开发后，项目发展到了后期，此时要应对某一变化需要的时间和费用会陡增。于是，敏捷开发应运而生。
敏捷开发不是预测变化。它是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
在敏捷开发中，人的因素要远远大于过程和技术。人决定着敏捷开发的成败。
人是有缺陷的：
1、 容易犯错误，因此必须在错误扩散之前找到并改正错误
2、 当觉得可能失去较多的时候，不愿意冒险
3、 重新构造而不愿意重复使用已有的东西
4、 难于坚持一个习惯
所以，”个体和交互”胜过“过程和工具”，个体交互既包括开发人员与开发人员之间，也包括发开人员与用户之间。在一个团队之间，交流是最重要的，实践证明面对面的实时的交流是最有效的，对交流的延误会损失信息，白板是最好的交流工具，交流工具的先进并不能提高交流效果。文档的作用是记录和备忘，不能通过文档交流。
软件开发的主要目标是以有效的方式，制造出满足project stakeholder需要的软件，而不是制造无关的文档，无关的用于管理的artifact，甚至无关的模型。任何一项活动，如果不符合这项原则，不能有助于目标实现的，都应该受到审核，甚至取消。采用传统的开发方法，一个开发团队在开发项目并维护时，需要一份详细的需求文档，一组详细的分析模型，再加上一组详细的架构模型，以及一组详细的设计模型。这样做的话，开发人员大部分的时间不是花在写源代码上，而是花在了更新文档上。敏捷型与传统方法的一个显而易见的区别就是，敏捷方法不是很面向文档，对于一项任务，它们通常只要求尽可能少的文档，从许多方面来看，它们更像是“面向源码”（code-oriented）。事实上，它们认为最根本的文档应该是源码。
在网站中，作者还提到了极限编程（eXtreme Programming，XP）。它是敏捷软件开发使用最广泛的一个方法。为什么称为“Extreme”？对比传统的项目开发方式，我们可以发现。XP强调把它列出的每个方法和思想做到极限、做到最好；其它XP所不提倡的，则一概忽略（如开发前期的整体设计等）。
它使用快速的反馈，大量而迅速的交流，经过保证的测试来最大限度的满足用户的需求。XP强调用户满意，开发人员可以对用户需求的变化作出快速的反应。XP强调团队工作。项目管理者，用户，开发人员都处于同一个项目中，他们之间的关系不是对立的，而是互相协作的，具有共同的目标：提交正确的软件。XP强调4个因素：
1、 交流(communication)：XP要求程序员之间以及和用户之间有大量而迅速的交流
2、 简单（simplicity），XP要求设计和实现简单和干净
3、 反馈（feedback）通过测试得到反馈，尽快提交软件并根据反馈修改
4、 勇气（courage）。勇敢的面对需求和技术上的变化
XP也饱受争议。这存在多方面原因，这里不一一列举。但是，XP主张用发展的眼光去看待一个design。这一点在上文关于软件开发过程中的变化所产生的费用已经详细解释了，不再赘述。
当然，光具备理论知识是远远不够的。实践出真知，要想真正地掌握敏捷开发，理解敏捷开发的精髓，还需要我们在实践中不断摸索，不断学习！