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