說到爲什麼我喜歡在實驗室推廣XP，我們先來看看幾個軟件過程
首先是RUP，RUP有什麼特點呢？迭代性開發，用例驅動，使用UML對軟件建模，提倡事先設計好以組件爲核心的體系結構(以體系結構爲中心)，不斷的評估和測試軟件質量，（使用用例）控制軟件的變化。在這些原則的基礎上，把軟件人員分成各種角色(分析，開發，管理，測試，工具支持，配置)等等，在軟件開發過程中的各種產品叫做工件(Artifact)。
再看TSP，TSP把人員分成小組領導者、開發經理、計劃經理、質量／生產經理，以及技術支持經理(注意這點和RUP的雷同）,要求各個人員嚴格記錄在軟件開發過程中的每一步，比如程序的Bug率，使用的時間等等。
最後一個是XP，XP的特點，雙人編程，簡單用例(User Story)，Refactoring，以周爲基礎的迭代。持續集成，現場客戶，測試驅動，自動化測試，代碼同步。同樣的，XP也把人員分成測試，交流人員，設計師，技術作者，客戶，程序員等等。
OK，說了這麼多長篇大論，是爲了把幾個軟件過程拿出來比較。所有的軟件過程無非是爲了避免風險，保證項目的成功。
拿交通工具做比方的話，TSP就好比坐火車，由於TSP是CMM那幫子人搞的，所以TSP不強調迭代性開發。TSP強調的是質量管理和控制，通過每個人自覺自願的記錄每天的行爲，從而的得到嚴格的項目的數據，缺乏了這種嚴格控制，TSP就好比火車沒有軌道，一點用處也沒有。而在我們實驗室一幫懶懶散散的學生中搞數據，要他們每天填表，從而知道項目消耗了多少人時，Bug率爲多少，不要做夢了吧，所以TSP那套方式肯定是行不通的。
再看XP和RUP的差別，迭代性開發，兩者都強調，不過兩者的含義不同，在RUP中，每次迭代，強調產生的是一個個工件，比如完成了用例。而在XP中，產生的是可用的軟件。爲什麼RUP的迭代裏面可能沒有產生可用的軟件呢？因爲RUP強調的是用例驅動和體系結構爲中心，所以RUP花在設計體系結構和用例上的時間會比較多，這樣帶來的好處是軟件的後期變更會比較少。而XP本身強調的是擁抱變化，不管三七二十一，先開發出來一個能用的再說，如果客戶不滿意（別忘了，XP是現場客戶），Refactoring之。所以在XP的開頭的時候，根本就不提倡太複雜的用例（客戶在現場嘛，不懂客戶的意思，現場交流啊），也不提倡過多的設計（測試驅動嘛，通不過的話Refactoring之）。
然而RUP沒有現場客戶的概念，所以清晰的用例描述是RUP中很重要的一環。只有這些用例在客戶和團隊之間達成了共識，才能做下一步的工作，同樣的，需求的變更也必須通過用例來體現，RUP很強調變更管理，就是這個意思。
而在我們實驗室做現在這個項目，不是和客戶交流的問題，而是沒有客戶！！！
所以，在這種程度下，我們的用例，不是要讓客戶理解，而是我們自己理解就足夠了。而體系結構，由於你們現在不用考慮分佈式，併發，事務等等一系列東西。這些東西都由J2EE做了。
此外RUP在我們實驗室很難辦的一件事情是對各個階段產生的工件的質量監控，同學們互相哈哈哈，很難對一個文檔性的東西進行評價。
那麼要改善我們現在做的項目，最重要的是做什麼呢？第一是，小迭代，我們現在整個軟件開發週期太長了，應該縮短到2－6周以內。第二，測試，我們現在的測試很多都是手動的，需要自動化這個測試過程。第三是，快速構建，持續集成。整個軟件的部署週期不能像現在這麼長，不能由同學們手工構建，而必須是自動化的部署。這些都是在XP中強調的。
RUP的不同就好比是做BUS和自己開小汽車的不同，儘管細微，但是，開小汽車更需要小心翼翼的調整方向，而公交車畢竟有線路。
如果在一個大公司做部門經理的話，我更願意採用RUP那套方式，輔之於XP的各種實踐，然而在實驗室，我只有退而求其次，因地制宜，XP能推廣多少是多少，一些很難推廣的東西比如風險管理，BUG管理只能暫時放棄了。