軟件大師Robert C.Martin在他的《敏捷軟件開發(fā)—原則、模式與實踐》中提到，XP理想的一個迭代周期為2周，每6次迭代形成一個可發(fā)行版本。因此，迭代粒度的大小是RUP和XP本質的區(qū)別之一。RUP更適合大型的開發(fā)項目，因為針對每一個項目，從跨越整個項目的廣度上來講，它制定了九大規(guī)程，每個規(guī)程對應若干個角色，每個角色需要產生若干個制品;從每一次迭代的深度上來講，它強調把項目開發(fā)分成若干次迭代，每一次迭代都分成初始階段、細化階段、編碼構建階段和移交用戶階段，每一個階段都強調形成若干制品，都對應多種不同的角色。
初始階段要求生成項目計劃、風險評估、需求模型等制品，這個階段基本不需要經歷幾次階段本身的迭代;細化階段主要進行分析設計工作，需要生成分析模型、設計模型、迭代計劃等制品，這個階段可以根據項目情況進行1～3次小的迭代;編碼構建階段主要是進行編碼，需要生成測試計劃、本次迭代的可運行版本等制品，這個階段也可以根據項目情況進行1～3次小的迭代;移交用戶階段主要是進行測試并提交給用戶試用的階段，需要生成產品測試文檔、用戶支持文檔等制品，這個階段可能由于性能測試不通過、出現bug、用戶不滿意，會有1～3次小的迭代。
從上面可以看到，如果要完全實現RUP的項目管理流程相當繁瑣。這是它的一個缺點。但如果是大型項目，比如一個項目組超過30人，我們按照XP的做法，更多地強調人與人之間的溝通來代替RUP的各種制品和文檔，它的溝通成本可能會遠遠高于撰寫各種制品和文檔的成本。所以這種情況下我們必須更多地采用RUP的方式來進行項目組織管理。但如果一個比較小的項目組，XP的開發(fā)方法學就比較適用。國外某著名研究機構的研究數據表明，如果一個開發(fā)團隊小于或等于12人，團隊將能夠保證成員間充分的溝通。
在開發(fā)過程中分析設計文檔非常重要，但如果迭代的粒度足夠細，比如，XP創(chuàng)始人Kent Beck研究認為，一個15人的項目組其迭代粒度為2～4周比較合理，按照這么細的粒度，就像前面講的建房子的隱喻一樣，那么，我們所需要的前期準備工作，包括分析設計的工作量肯定會大大減少。
在XP的“穿刺”過程中，如果按照現在采用的RUP的“用例驅動原則”，我們可以抽出里面對用戶具有足夠價值的若干個用例形成第一次迭代的內容。因為該次迭代涉及到的業(yè)務邏輯相對比較簡單，開發(fā)人員可以更好地理解，因此在做分析設計時，我們完全可以更加簡化各種文檔，并通過迭代過程中人員之間的良好溝通，“隱喻”的運用，在迭代中對簡化了的分析設計模型的逐步修改，來減少編碼之前的工作量。
三、用例須正確和穩(wěn)定
不過這里有兩個問題：第一，在每一次迭代期間，我們必須對所選擇的用例進行詳細分析，盡量保證它的正確性。《代碼大全》中講到，IBM、HP公司發(fā)表的研究文章表明，在需求階段的一個缺陷沒有被發(fā)現，在設計階段的修復成本會是需求階段發(fā)現該缺陷的3倍，在構建階段會是5～10倍，在用戶移交階段會是10～100倍。
可見隨著時間的推移，不正確的用例的修復成本會越來越高。第二，迭代期間用例必須保持穩(wěn)定。因為本次迭代的計劃、人員任務分配都是根據它來制定的，迭代期間的用例如果任意改變，就會使得計劃無法完成。采用粗粒度的迭代無法保證迭代期間用例的穩(wěn)定性，因為需求總會不斷改變，但細粒度的迭代比如以兩周為周期的迭代則完全可以做到這一點。
另外，在迭代期間出于優(yōu)化程序結構、增強程序擴展性等目的，設計模型應該是允許修改的，代碼是允許重構的，因為它對我們迭代計劃的完成
影響較小。
四、知識庫
隱喻是讓項目參與人員都必須對一些抽象的概念理解一致，也即我們常說的行業(yè)術語。因為業(yè)務本身的術語開發(fā)人員不熟悉，軟件開發(fā)的術語客戶不理解，因此要先明確雙方使用的隱喻，避免歧義。
瀑布模型(Waterfall Model)是Royce在1970年提出的，他把大型軟件開發(fā)分為分析與編程兩部分。像工廠流水線一樣，把軟件開發(fā)過程分成各種工序，并且每個工序可以根據軟件產品的規(guī)模、參與人員的多少，進一步細分成更細的工序。該模型非常符合軟件工程學的分層設計思路，所以成為軟件開發(fā)企業(yè)使用最多的開發(fā)模型。
極限編程要求加強開發(fā)者與用戶的溝通，讓客戶全面參與軟件的開發(fā)設計過程，保證變化的需求及時得到修正?！∶艚蒈浖_發(fā)是一個開發(fā)軟件的管理新模式，用來替代以文件驅動開發(fā)的瀑布開發(fā)模式。它也稱輕量級開發(fā)方法。