一般我们可以采用RUP的方式来进行开发，即从需求，到分析，到设计，到实现，到测试，RUP从最容易理解的需求开始，然后通过需求导出设计，由设计指导实现…，因此，在使用RUP时，最困难的步骤是需求，只有需求分析清楚了，后面的设计和实现就自然的水到渠成。但是RUP的一个缺点是需求要相对固定，因为需求的改变会导致后期的设计和实现的改变，因此对于一个需求确定的项目RUP是一个不错的选择。
另外一种开发方法是XP，他从测试，到代码实现，到重构，然后返回测试，一直迭代，直到实现所有的功能。XP从另外一个侧面来说，也是从需求入手，只不过，她的需求是通过测试来表现，这样的一个好处就是，能够很直接的把类的published方法，而不是public方法提取出来。特别的，对于分层系统来说，测试起到一个模范的作用，测试在测试下层服务的同时，也相当于把自己设置为一个上层服务的角色，因此上层的服务可以模仿测试的语法来调用下层的服务。
一般情况下，我们都喜欢把RUP和XP摆在一个对立的立场上来进行比较，而更多情况下，我们都要非此即彼的选择一种方法作为我们项目的开发方法。但是，我觉得这样做完全没有必要，而且不合适。首先，这两种方法都是经过了一定项目实践之后提出来的开发方法，因此，理论上他们都有一定的可取性。另外，这两种方法之间存在比较明显的相互补充特性，这表现在RUP的缺点往往是XP的优点，而XP的缺点却正好是RUP的优点上。因此，在选择开发方法时，我们应该适度的把这两种方法进行糅合。
首先，在开始的时候我们可以采用RUP的需求分析策略，它比XP的TDD更加容易入门和上手，因为，在不确实了解需求的情况下，根本不可能提出测试用例。
有了需求文档接下来我们可以开始使用XP中的TDD方法，这里之所以不使用RUP的分析，设计是因为一般来说这两个步骤占用的时间比较长，这就造成了发布时间的延长。而且，相对于文档，代码更有说服力，而且对于程序员来说，代码的意义很多时候比文档要大。再者，对于需求不稳定的项目，测试用例相对于分析，设计文档具有更快的反应速度和更短的反馈线路。因此，在这一步我们采取开发测试用例的方式。
有了测试用例，很自然的接下来的步骤就是代码实现，然后测试，然后重构。标准的TDD方式。
在以上的所有步骤当中，我们都是围绕着程序员在开发，但是，在一个团队当中，除了程序员以外，还有大部分不直接参与编码的管理人员和最终用户，因此，伴随着测试用例还有代码，我们应该根据RUP的方式，提取出对应的分析，设计文档。之所以在这步才完成上述文档主要是基于以下考虑。虽然从需求我们可以导出这些文档，但是由于在那个时候，我们尚未对系统进行任何实现，因此，所有的分析和设计都具有或多或少的猜测和不确定性，因此，在RUP当中，我们需要不停的进行迭代，来对系统进行求精。而使用TDD的方式，一开始我们就从代码出发，而通过测试和重构，我们就能完成系统的求精，因此相对于RUP的文档，代码，文档，代码…的迭代求精方式，TDD只需要在代码一级进行迭代，因此从时间和难易程度上TDD都要比RUP要简单。