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