现如今，软件的生存周期已经很短了，一些好的想法必须马上实现，否则就有可能被别人先开发出来从而失掉了商机；所以开发一个项目必须就是要快，以最短的时间开发出一个能够满足客户进本需求的软件；有此敏捷开发就应运而生；
敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
敏捷开发是在人们探索中由以前的开发方法中探索和总结出来的，虽然不完美，但是正在逐步适应。
敏捷开发是针对传统的瀑布开发模式的弊端而产生的一种新的开发模式，目标是提高开发效率和响应能力。除了原则和实践，模式也是很重要的，多研究模式及其应用可以使你更深层次的理解敏捷开发。
敏捷建模（AM）定义了一系列的核心原则和辅助原则，它们为软件开发项目中的建模实践奠定了基石。其中一些原则是从XP中借鉴而来，在Extreme Programming Explained中有它们的详细描述。而XP中的一些原则又是源于众所周知的软件工程学。复用的思想随处可见！基本上，本文中对这些原则的阐述主要侧重于它们是如何影响着建模工作；这样，对于这些借鉴于XP的原则，我们可以从另一个角度来看待。
简单，变化，持续性，迭代，成本。。。这是敏捷开发中常见的几个词。
简单：当从事开发工作时，你应当主张最简单的解决方案就是最好的解决方案。不要过分构建（overbuild）你的软件。用AM的说法就是，如果你现在并不需要这项额外功能，那就不要在模型中增加它。要有这样的勇气：你现在不必要对这个系统进行过分的建模（over-model），只要基于现有的需求进行建模，日后需求有变更时，再来重构这个系统。尽可能的保持模型的简单。
变化：需求时刻在变，人们对于需求的理解也时刻在变。项目进行中，Project stakeholder可能变化，会有新人加入，也会有旧人离开。Project stakeholder的观点也可能变化，你努力的目标和成功标准也有可能发生变化。这就意味着随着项目的进行，项目环境也在不停的变化，因此你的开发方法必须要能够反映这种现实。
持续：即便你的团队已经把一个能够运转的系统交付给用户，你的项目也还可能是失败的－－实现Project stakeholder的需求，其中就包括你的系统应该要有足够的鲁棒性（robust ），能够适应日后的扩展。就像Alistair Cockburn常说的，当你在进行软件开发的竞赛时，你的第二个目标就是准备下一场比赛。可持续性可能指的是系统的下一个主要发布版，或是你正在构建的系统的运转和支持。要做到这一点，你不仅仅要构建高质量的软件，还要创建足够的文档和支持材料，保证下一场比赛能有效的进行。你要考虑很多的因素，包括你现有的团队是不是还能够参加下一场的比赛，下一场比赛的环境，下一场比赛对你的组织的重要程度。简单的说，你在开发的时候，你要能想象到未来。
迭代：和建模相关的一个重要概念是你不用在一开始就准备好一切。实际上，你就算想这么做也不太可能。而且，你不用在模型中包容所有的细节，你只要足够的细节就够了。没有必要试图在一开始就建立一个囊括一切的模型，你只要开发一个小的模型，或是概要模型，打下一个基础，然后慢慢的改进模型，或是在不在需要的时候丢弃这个模型。这就是递增的思想。
成本：你的project stakeholder为了开发出满足自己需要的软件，需要投入时间、金钱、设备等各种资源。stakeholder应该可以选取最好的方式投资，也可以要求你的团队不浪费资源。并且，他们还有最后的发言权，决定要投入多少的资源。如果是这些资源是你自己的，你希望你的资源被误用吗。
除此之外，还有一个重要的词是团队，什么是团队，这也是敏捷开发必须需要考虑的，团队不是一群人做一个人的事。
团队中必须有人是领导者，有人是执行者。好比僚机和战斗机的关系。团队的每日站立会议也很重要，团队要变成自己领导自己，从消极的听从指挥变成自己主动，是团队的主导不是个人的主导，向团队利益最大化的方向发展。
而如何较好的实现敏捷开发的团队：
结合敏捷软件开发具体的实施情况，可以总结为以下几点：
(1) 团队成员需要全心投入，积极参入相关的过程。
(2) 时间预留，为迭代过程中突发事件和估算时间不准确的任务预期完成时间。
(3) 工作时间估算精确，避免占用过多的预留时间和在团队协作方面带来延迟。
(4) 团队成员间的相互协作和信任，
(5) 即时、有效的沟通，
(6) 问题即时暴露和即时解决，不要积压问题
(7) 任务跟踪，
(8) 软件开发人员需要对任务负责，对任务完成的目标严格要求。
(9) 团队需要良好的领导力和凝聚力