理想的一个迭代周期为2周，每6次迭代形成一个可发行版本。因此，迭代粒度的大小是RUP和XP本质的区别之一。
RUP更适合大型的开发项目，因为针对每一个项目，从跨越整个项目的广度上来讲，它制定了九大规程，每个规程对应若干个角色，每个角色需要产生若干个制品;从每一次迭代的深度上来讲，它强调把项目开发分成若干次迭代，每一次迭代都分成初始阶段、细化阶段、编码构建阶段和移交用户阶段，每一个阶段都强调形成若干制品，都对应多种不同的角色。初始阶段要求生成项目计划、风险评估、需求模型等制品，这个阶段基本不需要经历几次阶段本身的迭代;细化阶段主要进行分析设计工作，需要生成分析模型、设计模型、迭代计划等制品，这个阶段可以根据项目情况进行1～3次小的迭代;编码构建阶段主要是进行编码，需要生成测试计划、本次迭代的可运行版本等制品，这个阶段也可以根据项目情况进行1～3次小的迭代;移交用户阶段主要是进行测试并提交给用户试用的阶段，需要生成产品测试文档、用户支持文档等制品，这个阶段可能由于性能测试不通过、出现bug、用户不满意，会有1～3次小的迭代。
从上面可以看到，如果要完全实现RUP的项目管理流程相当繁琐。这是它的一个缺点。但如果是大型项目，比如一个项目组超过30人，我们按照XP的做法，更多地强调人与人之间的沟通来代替RUP的各种制品和文档，它的沟通成本可能会远远高于撰写各种制品和文档的成本。所以这种情况下我们必须更多地采用RUP的方式来进行项目组织管理。
但如果一个比较小的项目组，XP的开发方法学就比较适用。国外某著名研究机构的研究数据表明，如果一个开发团队小于或等于12人，团队将能够保证成员间充分的沟通。在开发过程中分析设计文档非常重要，但如果迭代的粒度足够细，比如，XP创始人Kent Beck研究认为，一个15人的项目组其迭代粒度为2～4周比较合理，按照这么细的粒度，就像前面讲的建房子的隐喻一样，那么，我们所需要的前期准备工作，包括分析设计的工作量肯定会大大减少。
在XP的“穿刺”过程中，如果按照现在采用的RUP的“用例驱动原则”，我们可以抽出里面对用户具有足够价值的若干个用例形成第一次迭代的内容。因为该次迭代涉及到的业务逻辑相对比较简单，开发人员可以更好地理解，因此在做分析设计时，我们完全可以更加简化各种文档，并通过迭代过程中人员之间的良好沟通，“隐喻”的运用，在迭代中对简化了的分析设计模型的逐步修改，来减少编码之前的工作量。
三、用例须正确和稳定
不过这里有两个问题：第一，在每一次迭代期间，我们必须对所选择的用例进行详细分析，尽量保证它的正确性。《代码大全》中讲到，IBM、HP公司发表的研究文章表明，在需求阶段的一个缺陷没有被发现，在设计阶段的修复成本会是需求阶段发现该缺陷的3倍，在构建阶段会是5～10倍，在用户移交阶段会是10～100倍。
可见随着时间的推移，不正确的用例的修复成本会越来越高。第二，迭代期间用例必须保持稳定。因为本次迭代的计划、人员任务分配都是根据它来制定的，迭代期间的用例如果任意改变，就会使得计划无法完成。采用粗粒度的迭代无法保证迭代期间用例的稳定性，因为需求总会不断改变，但细粒度的迭代比如以两周为周期的迭代则完全可以做到这一点。另外，在迭代期间出于优化程序结构、增强程序扩展性等目的，设计模型应该是允许修改的，代码是允许重构的，因为它对我们迭代计划的完成影响较小。
四、知识库
隐喻是让项目参与人员都必须对一些抽象的概念理解一致，也即我们常说的行业术语。因为业务本身的术语开发人员不熟悉，软件开发的术语客户不理解，因此要先明确双方使用的隐喻，避免歧义。
瀑布模型(Waterfall Model)是Royce在1970年提出的，他把大型软件开发分为分析与编程两部分。像工厂流水线一样，把软件开发过程分成各种工序，并且每个工序可以根据软件产品的规模、参与人员的多少，进一步细分成更细的工序。该模型非常符合软件工程学的分层设计思路，所以成为软件开发企业使用最多的开发模型。
敏捷软件开发是一个开发软件的管理新模式，它也称轻量级开发方法，用来替代以文件驱动开发的瀑布开发模式。极限编程要求加强开发者与用户的沟通，让客户全面参与软件的开发设计过程，保证变化的需求及时得到修正。