在开始软件项目之前，首先应该选择一种适合项目，且能够配合项目相关人员水平和态度的开发方法。一个软件开发方法就是一系列应用到软件开发流程过程中的最佳实践。软件开发方法能够帮助人们实现并管理项目。

当前存在两种主流的开发模型：传统方法和敏捷方法

一，传统方法：
瀑布模型是最被人们熟悉，也是最传统的方法。在瀑布模型中，软件开发流程会按照绝对的顺序从一个步骤走向下一个步骤。也就是说，只有当第N步已经百分之百完成时候，才能开始第N+1步。

团队完成需求分析之后，即可开始设计架构。接下来开始编写代码、测试，一直到系统交付。

瀑布模型的设计理念和城市规划设计一样，其主要特征是BDUF，也就是说在开始编写代码之前，设计必须全面完成，且不能更改。

瀑布模型是一种简单且纪律性强的方法。不过对于一些项目而言，这种模型有些不切实际，因为你几乎不可能在项目的最开始就得到所有的需求。因此会发生一种不可避免的情况，即你会在某些时候不得不开始下一下工作，但同时上一步中还遗留了一部分没有完成。

考虑到这些，瀑布模型多年以来有了一些改进版本。其中设计和实现这两个步骤中有着一定的重叠，这也引发了我们的思考。

最终我们发现所有的开发方法都有一些共同的特质：一系列需要完成的步骤，一系列创建软件需要的迭代以及每个迭代一般花费的时间等。所有的步骤都需要顺序进行，且在最终交付软件之前，均至少需要一个迭代。

不同的开发方法之间的区别也仅体现在先从哪个步骤开始，需要的迭代次数以及每个迭代的时间上。

考虑到这些，我们就自然而然地走入了敏捷开发方法的世界。

注意：我们甚至可以这样说，敏捷方法不过是一系列较小的瀑布流程，每个瀑布中的工作少一些，时间短一些，不过瀑布会多一些，也许会根据需要添加。与瀑布相比，这更像一个淋浴器。

二，敏捷方法：
作为瀑布模型的改进，迭代开发是一个循环的过程，它主要强调用渐进的方式开发软件。在开始之后，项目将通过一系列的迭代来进行，每个迭代中都包含了设计、编码和测试的过程。每个迭代都会得到一个可交付但尚不完整的系统。在每个迭代中，团队都会遇到设计变化并添加新的功能，直至满足所有的需求。

迭代开发是敏捷开发的基石。“敏捷”这个词的选择非常有深意，用来明确地强调这种方法与那些重量级的方法（比如瀑布模型）之间的不同。敏捷方法将人作为项目中最重要的部分。正如敏捷宣言网站中描述的那样，与编写软件和开发流程相比，敏捷方法更加关注在一起工作，交流的人们。变化和重构是敏捷方法的关键之一。用户反馈将在计划时参与，反馈也由经常性的测试以及频繁的发布来保证。实际上，一条敏捷原则就是“能够正常工作的软件就是进度的最重要的体现”。

不过敏捷方法到底有什么不同呢？其究竟如何实现呢？我们来看一个实例。

在仅仅了解了一小部分需求时，项目就开始了。不过可以保证的是，更多的需求将在项目进行过程中提出。在敏捷方法看来，这并不是问题。从现有需求中拿出一些，即可开始实现第一个迭代，于是就这样进行下去。在迭代过程中，每次只关注并完成一个需求。在迭代结束之后，即可交付一个能够完成部分工作的软件。虽然并不完整，但至少可以工作。

接下来开始另一个迭代，关注另一些已知的需求。若是其间发现某些需求发生了变化，或者有些事情做错，则进行重构。这样不停地进行迭代，直到实现所有需求。

软件开发中较流行的敏捷方法就是极限编程（Extreme Programming,XP）。在XP中，每个迭代的时间都非常短，一般仅有2周的时间。编码和设计要同时进行。