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