|
目前國(guó)內(nèi)對(duì)于XP方面的研究和應(yīng)用此起彼伏，各種關(guān)于XP的書籍爭(zhēng)相出版，對(duì)于以XP為代表的"敏捷軟件工程"方法的爭(zhēng)論也在網(wǎng)絡(luò)上隨處可見。之所以出現(xiàn)這樣的情況，是因?yàn)閲?guó)內(nèi)的用戶在軟件項(xiàng)目的實(shí)施過程中遇到了很多問題，例如項(xiàng)目的交付時(shí)間推遲、用戶需求變更頻繁等，我們的軟件工程師迫切的希望能夠找到解決問題的"銀彈"。對(duì)于高度動(dòng)態(tài)、通過非常短的迭代周期來應(yīng)對(duì)需求變化的極限編程方法論來講，確實(shí)能夠從一定程度上解決問題。但是，對(duì)于國(guó)內(nèi)的軟件開發(fā)項(xiàng)目來說，XP并非"銀彈"，它的一些最佳實(shí)踐不是都適合國(guó)內(nèi)的情況。本文結(jié)合一個(gè)具體的軟件開發(fā)項(xiàng)目，討論一下XP 在國(guó)內(nèi)的應(yīng)用情況。 XP簡(jiǎn)介 傳統(tǒng)軟件開發(fā)方法 在最近的數(shù)十年中，很多企業(yè)的CEO們都面臨著增加盈利的壓力，因此，他們采用各種方法，例如裁員、業(yè)務(wù)外包、BPR、ERP、CRM等等。以上種種，使得世界500強(qiáng)的大部分企業(yè)在20世紀(jì)90年代的后期一直保持者二位數(shù)的利潤(rùn)增長(zhǎng)。但是很多跡象表明，在傳統(tǒng)的企業(yè)業(yè)務(wù)模型中已經(jīng)沒有多少可供削減開支的地方，因此，需要進(jìn)行徹底的改革。在軟件開發(fā)領(lǐng)域，情況更是如此。 自上個(gè)世紀(jì)60年代以來，軟件工程思想逐漸形成與發(fā)展，也出現(xiàn)了很多軟件開發(fā)模型與方法，例如瀑布模型、快速原型、增量模型和螺旋模型等[1]。而在90年代以后，卡耐基梅隆軟件學(xué)院推出的CMM，更是對(duì)于軟件開發(fā)的過程管理，提出了確切的衡量指標(biāo)。但是，最近的研究表明，有50％的項(xiàng)目會(huì)拖延交付，有30％以上的項(xiàng)目會(huì)超出預(yù)算，軟件開發(fā)領(lǐng)域的項(xiàng)目情況比軟件工程剛剛提出的時(shí)候相比，只是有很小的提高。詳細(xì)的數(shù)據(jù)[4]（數(shù)據(jù)來自美國(guó)GSM研究機(jī)構(gòu), Michael Mah）如下表所示： 傳統(tǒng)的軟件開發(fā)過程，以RUP為代表，強(qiáng)調(diào)項(xiàng)目的可控性，是一個(gè)用例驅(qū)動(dòng)的基于UML和構(gòu)件式架構(gòu)的迭代增量式開發(fā)過程。RUP定義了初始、細(xì)化、實(shí)現(xiàn)和部署4個(gè)階段，分別對(duì)應(yīng)著關(guān)鍵里程碑的劃分。RUP對(duì)于角色、流程、工件和活動(dòng)的要求是靈活、可配置的，所以它廣泛的適用于各種類型的項(xiàng)目。但是，在RUP的各個(gè)流程碑，都規(guī)定了要交付的成果，尤其是對(duì)于需求的變更以及文檔，它強(qiáng)調(diào)及時(shí)的更新與同步。以上這些都決定了RUP是一種重量級(jí)的軟件開發(fā)方法，比較適合大中型的項(xiàng)目和產(chǎn)品開發(fā)。 XP以及其核心價(jià)值 最近，出現(xiàn)了很多輕量型的軟件開發(fā)方法，例如水晶模型、適應(yīng)模型以及極限編程等。它們都強(qiáng)調(diào)，軟件開發(fā)是人與人合作進(jìn)行的過程，因此成功的軟件開發(fā)過程應(yīng)該充分利用人的優(yōu)勢(shì)，而弱化人的缺點(diǎn)，突出了人在軟件開發(fā)過程中的作用[2]。 Kent Beck在XP的開篇之作《Extreme Programming Explained - Embrace Change》中提出了極限編程這一創(chuàng)新的軟件過程方法論。極限編程是一種高度動(dòng)態(tài)的過程，它通過非常短的迭代周期來應(yīng)對(duì)需求的變化。在極限編程中，包括四個(gè)基本活動(dòng)：編碼、測(cè)試、聆聽與反饋，XP項(xiàng)目的狀態(tài)變遷如下圖所示[3][4]： Kent Beck指出，XP有四個(gè)核心價(jià)值是我們應(yīng)該注意的[3][4]： 溝通：項(xiàng)目中發(fā)現(xiàn)的問題往往是由于開發(fā)人員與設(shè)計(jì)人員、設(shè)計(jì)人員與客戶之間的溝通不暢造成的，因此，在XP項(xiàng)目中沒有溝通是不可能的。 簡(jiǎn)單：XP認(rèn)為應(yīng)該盡量保持代碼的簡(jiǎn)單，只要它能工作就可以。Kent Beck指出與其實(shí)現(xiàn)一個(gè)復(fù)雜的的系統(tǒng)，不如設(shè)計(jì)一個(gè)能夠滿足目前需要的、簡(jiǎn)單的系統(tǒng)，因?yàn)槟闼紤]的情況可能永遠(yuǎn)都不會(huì)發(fā)生。 反饋：盡快獲得用戶的反饋，并且越詳細(xì)越好，使得開發(fā)人員能夠保證自己的成果符合用戶的需要。 勇氣：這是最重要的核心價(jià)值。因?yàn)閄P強(qiáng)調(diào)要"擁抱變化"，因此對(duì)于用戶的反饋，要勇于對(duì)自己的代碼進(jìn)行修改，丟掉壞的代碼。 下面我們將要談到的XP的最佳實(shí)踐就體現(xiàn)了上述四個(gè)核心價(jià)值。實(shí)際上，XP中并沒有多少新的觀點(diǎn)，它的一些最佳實(shí)踐也都是長(zhǎng)久以來都在使用中的。 XP的適用環(huán)境 從XP項(xiàng)目狀態(tài)圖以及它的核心價(jià)值中我們可以看到，XP弱化針對(duì)未來需求的設(shè)計(jì)，非常注重當(dāng)前的簡(jiǎn)化。它的實(shí)踐，有一個(gè)非常關(guān)鍵的假設(shè)就是開發(fā)人員只注重眼前需求而依賴重構(gòu)來適應(yīng)需求的變動(dòng)所帶來的風(fēng)險(xiǎn)與開銷要小于需求變化使得事先充分設(shè)計(jì)失效的代價(jià)；反之，實(shí)施XP就是不明智的[5]。 因此，XP適合規(guī)模小、進(jìn)度緊、需求變化大、質(zhì)量要求嚴(yán)的項(xiàng)目。它希望以最高的效率和質(zhì)量來解決用戶目前的問題，以最大的靈活性和最小的代價(jià)來滿足用戶未來的需求，XP在平衡短期和長(zhǎng)期利益之間做了巧妙的選擇。 我們可以看到，XP并不是解決問題的"銀彈"，它也有不適合的情況。Beck曾經(jīng)建議在以下情況下不宜采用XP： 中大型的項(xiàng)目（項(xiàng)目團(tuán)隊(duì)超過10人）； 重構(gòu)會(huì)導(dǎo)致大量開銷的應(yīng)用； 需要很長(zhǎng)的編譯或者測(cè)試周期的系統(tǒng)； 不容易進(jìn)行測(cè)試的應(yīng)用； 團(tuán)隊(duì)人員異地分布的項(xiàng)目； 不能接收XP文化的組織和團(tuán)隊(duì)； 項(xiàng)目概況及背景 我們公司是亞洲領(lǐng)先的電子商務(wù)解決方案供應(yīng)商，在J2EE架構(gòu)的項(xiàng)目執(zhí)行方面有豐富的經(jīng)驗(yàn)，結(jié)合RUP形成了自己的一套電子商務(wù)項(xiàng)目實(shí)施方法論，并在多個(gè)項(xiàng)目中成功進(jìn)行實(shí)施。同時(shí)，由于具體項(xiàng)目時(shí)間和成本的限制，也出現(xiàn)了許多問題，主要有以下兩點(diǎn)： 項(xiàng)目交付后，用戶提出很多的修改意見，有些甚至涉及系統(tǒng)架構(gòu)的修改：出現(xiàn)這種情況的主要原因是很多項(xiàng)目雖然是采用增量迭代式的開發(fā)周期，但是在部署前才發(fā)布版本，用戶只是在項(xiàng)目部署后才看到真正的系統(tǒng)，因此會(huì)發(fā)現(xiàn)很多界面、流程等方面的問題； 對(duì)于用戶提交BUG的修改周期過長(zhǎng)：開發(fā)人員在作開發(fā)的時(shí)候，對(duì)于單元測(cè)試的重視程度不夠，模塊開發(fā)結(jié)束后就提交給測(cè)試人員進(jìn)行測(cè)試，而測(cè)試人員由于時(shí)間的關(guān)系，并不能發(fā)現(xiàn)所有的問題；在用戶提交BUG后，開發(fā)人員由于項(xiàng)目接近尾聲，對(duì)于代碼的修改產(chǎn)生惰性，同時(shí)又沒有形成有效的回歸測(cè)試方法，因此，修改的周期比較長(zhǎng)。 針對(duì)XP的核心價(jià)值，可以看到，如果我們能夠加強(qiáng)與用戶的溝通、增加項(xiàng)目中測(cè)試實(shí)施的力度、提高開發(fā)人員的勇氣，就可以從一定程度上解決上述問題。 從2001年開始，公司內(nèi)部展開對(duì)于XP等敏捷方法的研究，希望能夠借鑒一些做法，來完善項(xiàng)目方法論。 2002年5月，我們決定在公司的一個(gè)新的項(xiàng)目中啟用XP的一些最佳實(shí)踐，來檢驗(yàn)其效果。該項(xiàng)目是為一家國(guó)際知名手機(jī)生產(chǎn)廠商的合作伙伴提供手機(jī)配件定購(gòu)、申請(qǐng)、回收等服務(wù)，項(xiàng)目的情況如下表所示： 從上表中可以看出，該項(xiàng)目是一個(gè)小型項(xiàng)目，而且項(xiàng)目小組成員對(duì)于XP在項(xiàng)目開始之前都有一定的了解，另一方面，客戶要求的項(xiàng)目周期比我們預(yù)期估計(jì)的時(shí)間有一定的余地，因此我們決定利用這個(gè)項(xiàng)目進(jìn)行XP的試驗(yàn)性實(shí)踐。 XP的最佳實(shí)踐以及在項(xiàng)目中的應(yīng)用 在項(xiàng)目執(zhí)行過程中，我們基本上還是采用RUP的軟件過程，而沒有死板的套用XP 的做法，例如：在需求分析階段，我們還是采用Use Case來對(duì)需求進(jìn)行描述，而不是XP規(guī)定的CRC卡片；在系統(tǒng)分析與設(shè)計(jì)階段，首先進(jìn)行系統(tǒng)的架構(gòu)設(shè)計(jì)，而不是簡(jiǎn)單的套用XP的"簡(jiǎn)單設(shè)計(jì)"實(shí)踐。 下面我們結(jié)合項(xiàng)目的具體情況，討論一下XP的12個(gè)最佳實(shí)踐。 現(xiàn)場(chǎng)客戶 ( On-site Customer ) XP： 要求至少有一名實(shí)際的客戶代表在整個(gè)項(xiàng)目開發(fā)周期在現(xiàn)場(chǎng)負(fù)責(zé)確定需求、回答團(tuán)隊(duì)問題以及編寫功能驗(yàn)收測(cè)試。 評(píng)述：現(xiàn)場(chǎng)用戶可以從一定程度上解決項(xiàng)目團(tuán)隊(duì)與客戶溝通不暢的問題，但是對(duì)于國(guó)內(nèi)用戶來講，目前階段還不能保證有一定技術(shù)層次的客戶常駐開發(fā)現(xiàn)場(chǎng)。解決問題的方法有兩種：一是可以采用在客戶那里現(xiàn)場(chǎng)開發(fā)的方式；二是采用有效的溝通方式。 項(xiàng)目：首先，我們?cè)陧?xiàng)目合同簽署前，向客戶進(jìn)行項(xiàng)目開發(fā)方法論的介紹，使得客戶清楚項(xiàng)目開發(fā)的階段、各個(gè)階段要發(fā)布的成果以及需要客戶提供的支持等；其次，由項(xiàng)目經(jīng)理每周向客戶匯報(bào)項(xiàng)目的進(jìn)展情況，提供目前發(fā)布版本的位置，并提示客戶系統(tǒng)相應(yīng)的反饋與支持。 代碼規(guī)范 ( Code Standards ) XP： 強(qiáng)調(diào)通過指定嚴(yán)格的代碼規(guī)范來進(jìn)行溝通，盡可能減少不必要的文檔。 評(píng)述： XP對(duì)于代碼規(guī)范的實(shí)踐，具有雙重含義：一是希望通過建立統(tǒng)一的代碼規(guī)范，來加強(qiáng)開發(fā)人員之間的溝通，同時(shí)為代碼走查提供了一定的標(biāo)準(zhǔn)；二是希望減少項(xiàng)目開發(fā)過程中的文檔，XP認(rèn)為代碼是最好的文檔。 對(duì)于目前國(guó)內(nèi)的大多數(shù)項(xiàng)目團(tuán)隊(duì)來說，建立有效的代碼規(guī)范，加強(qiáng)團(tuán)隊(duì)內(nèi)代碼的統(tǒng)一性，是理所當(dāng)然的；但是，認(rèn)為代碼可以代替文檔卻是不可取的，因?yàn)榇a的可讀性與規(guī)范的文檔相比合適由一定的差距。 同時(shí)，如果沒有統(tǒng)一的代碼規(guī)范，代碼全體擁有就無從談起。 項(xiàng)目： 在項(xiàng)目實(shí)施初期，就由項(xiàng)目的技術(shù)經(jīng)理建立代碼規(guī)范，并將其作為代碼審查的標(biāo)準(zhǔn)。 每周40小時(shí)工作制 ( 40-hour Week ) XP： 要求項(xiàng)目團(tuán)隊(duì)人員每周工作時(shí)間不能超過40小時(shí)，加班不得連續(xù)超過兩周，否則反而會(huì)影響生產(chǎn)率。 評(píng)述： 該實(shí)踐充分體現(xiàn)了XP的"以人為本"的原則。但是，如果要真正的實(shí)施下去，對(duì)于項(xiàng)目進(jìn)度和工作量合理安排的要求就比較高。 項(xiàng)目： 由于項(xiàng)目的工期比較充裕，因此，很幸運(yùn)的是我們并沒有違反該實(shí)踐。 計(jì)劃博弈 ( Planning Game ) XP： 要求結(jié)合項(xiàng)目進(jìn)展和技術(shù)情況，確定下一階段要開發(fā)與發(fā)布的系統(tǒng)范圍。 評(píng)述： 項(xiàng)目的計(jì)劃在建立起來以后，需要根據(jù)項(xiàng)目的進(jìn)展來進(jìn)行調(diào)整，一成不變的計(jì)劃是不存在。因此，項(xiàng)目團(tuán)隊(duì)需要控制風(fēng)險(xiǎn)、預(yù)見變化，從而制定有效、可行的項(xiàng)目計(jì)劃。 項(xiàng)目： 在系統(tǒng)實(shí)現(xiàn)前，我們首先按照需求的優(yōu)先級(jí)做了迭代周期的劃分，將高風(fēng)險(xiǎn)的需求優(yōu)先實(shí)現(xiàn)；同時(shí)，項(xiàng)目團(tuán)隊(duì)每天早晨參加一個(gè)15分鐘的項(xiàng)目會(huì)議，確定當(dāng)天以及目前迭代周期中每個(gè)成員要完成的任務(wù)。 系統(tǒng)隱喻 ( System Metaphor ) XP： 通過隱喻來描述系統(tǒng)如何運(yùn)作、新的功能以何種方式加入到系統(tǒng)。它通常包含了一些可以參照和比較的類和設(shè)計(jì)模式。XP不需要事先進(jìn)行詳細(xì)的架構(gòu)設(shè)計(jì)。 評(píng)述： XP在系統(tǒng)實(shí)現(xiàn)初期不需要進(jìn)行詳細(xì)的架構(gòu)設(shè)計(jì)，而是在迭代周期中不斷的細(xì)化架構(gòu)。對(duì)于小型的系統(tǒng)或者架構(gòu)設(shè)計(jì)的分析會(huì)推遲整個(gè)項(xiàng)目的計(jì)劃的情況下，逐步細(xì)化系統(tǒng)架構(gòu)倒是可以的；但是，對(duì)于大型系統(tǒng)或者是希望采用新架構(gòu)的系統(tǒng)，就需要在項(xiàng)目初期進(jìn)行相信的系統(tǒng)架構(gòu)設(shè)計(jì)，并在第一個(gè)迭代周期中進(jìn)行驗(yàn)證，同時(shí)在后續(xù)迭代周期中逐步進(jìn)行細(xì)化。 項(xiàng)目： 開發(fā)團(tuán)隊(duì)在設(shè)計(jì)初期，決定參照STRUTS框架，結(jié)合項(xiàng)目的情況，構(gòu)建了針對(duì)工作流程處理的項(xiàng)目框架。首先，團(tuán)隊(duì)決定在第一個(gè)迭代周期實(shí)現(xiàn)配件申請(qǐng)的工作流程，在實(shí)際項(xiàng)目開發(fā)中驗(yàn)證了基本的程序框架；而后，又在其它迭代周期中，對(duì)框架逐漸精化。 簡(jiǎn)單設(shè)計(jì) ( Simple Design ) XP： 認(rèn)為代碼的設(shè)計(jì)應(yīng)該盡可能的簡(jiǎn)單，只要滿足當(dāng)前功能的要求，不多也不少。 評(píng)述： 傳統(tǒng)的軟件開發(fā)過程，對(duì)于設(shè)計(jì)是自頂而下的，強(qiáng)調(diào)設(shè)計(jì)先行，在代碼開始編寫之前，要有一個(gè)完美的設(shè)計(jì)模型。它的前提是需求不變化，或者很少變化；而XP認(rèn)為需求是會(huì)經(jīng)常變化的，因此設(shè)計(jì)不能一蹴而就，而應(yīng)該是一項(xiàng)持續(xù)進(jìn)行的過程。 Kent Beck認(rèn)為對(duì)于XP來說，簡(jiǎn)單設(shè)計(jì)應(yīng)該滿足以下幾個(gè)原則： 1.成功執(zhí)行所有的測(cè)試； 2.不包含重復(fù)的代碼； 3.向所有的開發(fā)人員清晰地描述編碼以及其內(nèi)在關(guān)系； 4.盡可能包含最少的類與方法。 對(duì)于國(guó)內(nèi)大部分的軟件開發(fā)組織來說，應(yīng)該首先確定一個(gè)靈活的系統(tǒng)架構(gòu)，而后在每個(gè)迭代周期的設(shè)計(jì)階段可以采用XP的簡(jiǎn)單設(shè)計(jì)原則，將設(shè)計(jì)進(jìn)行到底。 項(xiàng)目： 在項(xiàng)目的系統(tǒng)架構(gòu)經(jīng)過驗(yàn)證后的迭代周期內(nèi)，我們始終堅(jiān)持簡(jiǎn)單設(shè)計(jì)的原則，并按照Kent Beck的四項(xiàng)原則來進(jìn)行有效的驗(yàn)證。對(duì)于新的迭代周期中出現(xiàn)需要修改既有設(shè)計(jì)與代碼的情況，首先對(duì)原有系統(tǒng)進(jìn)行"代碼重構(gòu)"，而后再增加新的功能。 測(cè)試驅(qū)動(dòng) ( Test-driven ) XP： 強(qiáng)調(diào)"測(cè)試先行"。在編碼開始之前，首先將測(cè)試寫好，而后再進(jìn)行編碼，直至所有的測(cè)試都得以通過。 評(píng)述： RUP與XP對(duì)測(cè)試都是非常的重視，只是兩者對(duì)于測(cè)試在整個(gè)項(xiàng)目開發(fā)周期內(nèi)首先出現(xiàn)的位置處理不同。XP是一項(xiàng)測(cè)試驅(qū)動(dòng)的軟件開發(fā)過程，它認(rèn)為測(cè)試先行使得開發(fā)人員對(duì)自己的代碼有足夠的信心，同時(shí)也有勇氣進(jìn)行代碼重構(gòu)。測(cè)試應(yīng)該實(shí)現(xiàn)一定的自動(dòng)化，同時(shí)能夠清晰的給出測(cè)試成功或者失敗的結(jié)果。在這方面，xUnit測(cè)試框架做了很多的工作，因此很多實(shí)施XP的團(tuán)隊(duì)，都采用它們進(jìn)行測(cè)試工作。 項(xiàng)目： 我們?cè)陧?xiàng)目初期就對(duì)JUNIT進(jìn)行了一定的研究工作，在項(xiàng)目編碼中，采用JBUILDER6提供的測(cè)試框架進(jìn)行測(cè)試類的編寫。但是，不是對(duì)所有的方法與用例都編寫，而只是針對(duì)關(guān)鍵方法類、重要業(yè)務(wù)邏輯處理類等進(jìn)行。 代碼重構(gòu) ( Refactoring ) XP： 強(qiáng)調(diào)代碼重構(gòu)在其中的作用，認(rèn)為開發(fā)人員應(yīng)該經(jīng)常進(jìn)行重構(gòu)，通常有兩個(gè)關(guān)鍵點(diǎn)應(yīng)該進(jìn)行重構(gòu)：對(duì)于一個(gè)功能實(shí)現(xiàn)和實(shí)現(xiàn)后。 評(píng)述： 代碼重構(gòu)是指在不改變系統(tǒng)行為的前提下，重新調(diào)整、優(yōu)化系統(tǒng)的內(nèi)部結(jié)構(gòu)以減少?gòu)?fù)雜性、消除冗余、增加靈活性和提高性能。重構(gòu)不是XP所特有的行為，在任何的開發(fā)過程中都可能并且應(yīng)該發(fā)生。 在使用代碼重構(gòu)的時(shí)候要注意，不要過分的依賴重構(gòu)，甚至輕視設(shè)計(jì)，否則，對(duì)于大中型的系統(tǒng)而言，將設(shè)計(jì)推遲或者干脆不作設(shè)計(jì)，會(huì)造成一場(chǎng)災(zāi)難。 項(xiàng)目： 我們?cè)陧?xiàng)目中將JREFACTORY工具部署到JBuilder中進(jìn)行代碼的重構(gòu)，重構(gòu)的時(shí)間是在各個(gè)迭代周期的前后。代碼重構(gòu)在項(xiàng)目中的作用是改善既有設(shè)計(jì)，而不是代替設(shè)計(jì)。 成對(duì)編程 ( Pair Programming ) XP： 認(rèn)為在項(xiàng)目中采用成對(duì)編程比獨(dú)自編程更加有效。成對(duì)編程是由兩個(gè)開發(fā)人員在同一臺(tái)電腦上共同編寫解決同一問題的代碼，通常一個(gè)人負(fù)責(zé)寫編碼，而另一個(gè)負(fù)責(zé)保證代碼的正確性與可讀性。 評(píng)述： 其實(shí)，成對(duì)編程是一種非正式的同級(jí)評(píng)審 ( Peer Review )。它要求成對(duì)編程的兩個(gè)開發(fā)人員在性格和技能上應(yīng)該相互匹配，目前在國(guó)內(nèi)還不是十分適合推廣。成對(duì)編程只是加強(qiáng)開發(fā)人員溝通與評(píng)審的一種方式，而非唯一的方式。具體的方式可以結(jié)合項(xiàng)目的情況進(jìn)行。 項(xiàng)目： 我們?cè)陧?xiàng)目中并沒有采用成對(duì)編程的實(shí)踐，而是在項(xiàng)目實(shí)施的各個(gè)階段，加強(qiáng)了走查以及同級(jí)評(píng)審的力度。需求獲取、設(shè)計(jì)與分析都有多人參與，在成果提交后，交叉進(jìn)行走查；而在編碼階段，開發(fā)人員之間也要在每個(gè)迭代周期后進(jìn)行同時(shí)評(píng)審。 XP： 認(rèn)為開發(fā)小組的每個(gè)成員都有更改代碼的權(quán)利，所有的人對(duì)于全部代碼負(fù)責(zé)。 評(píng)論： 代碼全體擁有并不意味者開發(fā)人員可以互相推委責(zé)任，而是強(qiáng)調(diào)所有的人都要負(fù)責(zé)。如果一個(gè)開發(fā)人員的代碼有錯(cuò)誤，另外一個(gè)開發(fā)人員也可以進(jìn)行BUG的修復(fù)。 在目前，國(guó)內(nèi)的軟件開發(fā)組織，可以在一定程度上實(shí)施該實(shí)踐，但是同時(shí)需要注意一定要有嚴(yán)格的代碼控制管理。 項(xiàng)目： 我們?cè)陧?xiàng)目開發(fā)初期，首先向開發(fā)團(tuán)隊(duì)進(jìn)行"代碼全體擁有"的教育，同時(shí)要求開發(fā)人員不僅要了解系統(tǒng)的架構(gòu)、自己的代碼，同時(shí)也要了解其它開發(fā)人員的工作以及代碼情況。這個(gè)實(shí)踐與同級(jí)評(píng)審有一定的互補(bǔ)作用，從而保證人員的變動(dòng)不會(huì)對(duì)項(xiàng)目的進(jìn)度造成很大的影響。 在項(xiàng)目執(zhí)行中，有一個(gè)開發(fā)人員由于參加培訓(xùn)，缺席項(xiàng)目執(zhí)行一周，由于實(shí)行了"代碼全體擁有"的實(shí)踐，其它的開發(fā)人員成功地分擔(dān)了該成員的測(cè)試與開發(fā)任務(wù)，從而保證項(xiàng)目的如期交付。 持續(xù)集成 ( Continuous Integration ) XP： 提倡在一天中集成系統(tǒng)多次，而且隨著需求的改變，要不斷的進(jìn)行回歸測(cè)試。因?yàn)?，這樣可以使得團(tuán)隊(duì)保持一個(gè)較高的開發(fā)速度，同時(shí)避免了一次系統(tǒng)集成的惡夢(mèng)。 評(píng)述： 持續(xù)集成也不是XP專有的最佳實(shí)踐，著名的微軟公司就有每日集成 ( Daily Build ) 的成功實(shí)踐。但是，要注意的是，持續(xù)集成也需要良好的軟件配置變更管理系統(tǒng)的有效支持。 項(xiàng)目： 使用VSS作為軟件配置管理系統(tǒng)，堅(jiān)持每天進(jìn)行一次的系統(tǒng)集成，將已經(jīng)完成的功能有效地結(jié)合起來，進(jìn)行測(cè)試。 小型發(fā)布 ( Small Release ) XP： 強(qiáng)調(diào)在非常短的周期內(nèi)以遞增的方式發(fā)布新版本，從而可以很容易地估計(jì)每個(gè)迭代周期的進(jìn)度，便于控制工作量和風(fēng)險(xiǎn)；同時(shí)，也可以及時(shí)處理用戶的反饋。 評(píng)論： 小型發(fā)布突出體現(xiàn)了敏捷方法的優(yōu)點(diǎn)。RUP強(qiáng)調(diào)迭代式的開發(fā)，對(duì)于系統(tǒng)的發(fā)布并沒有作出過多的規(guī)定。用戶在提交需求后，只有在部署時(shí)才能看到真正的系統(tǒng)，這樣就不利于迅速獲得用戶的反饋。 如果能夠保證測(cè)試先行、代碼重構(gòu)、持續(xù)集成等最佳實(shí)踐，實(shí)現(xiàn)小型發(fā)布也不是一件困難的事情，在有條件的組織可以考慮使用。 項(xiàng)目： 項(xiàng)目在籌備階段就配置了一臺(tái)測(cè)試與發(fā)布服務(wù)器，在項(xiàng)目實(shí)施過程中，平均每?jī)芍埽ㄒ粋€(gè)迭代周期結(jié)束后）進(jìn)行一個(gè)小型發(fā)布；用戶在發(fā)布后兩個(gè)工作日內(nèi)，向項(xiàng)目小組提交"用戶接收測(cè)試報(bào)告"，由項(xiàng)目經(jīng)理評(píng)估測(cè)試報(bào)告，將有效的BUG提交至Rational Clear Case，并分配給相應(yīng)的開發(fā)人員。項(xiàng)目小組應(yīng)該在下一個(gè)迭代周期結(jié)束前修復(fù)所有用戶提交的問題。 以上是XP的最佳實(shí)踐在項(xiàng)目中的應(yīng)用情況，讓我們查看以下該項(xiàng)目的詳細(xì)統(tǒng)計(jì)數(shù)據(jù)： 其中，項(xiàng)目執(zhí)行過程中提交了一個(gè)"用戶需求變更"，該變更對(duì)于項(xiàng)目周期的影響為6個(gè)工作日。 項(xiàng)目實(shí)施后，在用戶接收測(cè)試中，只提交了2個(gè)BUG，而且在提交當(dāng)天就得到了解決。目前，項(xiàng)目運(yùn)行平穩(wěn)，并得到了用戶的好評(píng)。因此，我們認(rèn)為，XP在該項(xiàng)目中的實(shí)施有效地保證了項(xiàng)目質(zhì)量和項(xiàng)目周期。 總結(jié) RUP與XP 都是在總結(jié)了很多項(xiàng)目實(shí)踐的過程中發(fā)展起來的軟件開發(fā)過程， 只是它們?cè)谔幚硇枨笞兏姆椒ú煌?。其?shí)它們還是有很多相似之處，例如，它們的基礎(chǔ)都是面向?qū)ο蠓椒?，都重視代碼、文檔的最小化和設(shè)計(jì)的簡(jiǎn)化，采用動(dòng)態(tài)適應(yīng)變化的演進(jìn)式迭代周期等等。 目前，國(guó)內(nèi)執(zhí)行XP的理想情況應(yīng)該是：在保持組織既有的開發(fā)過程和生命周期模型的情況下，根據(jù)應(yīng)用類型、項(xiàng)目特點(diǎn)和組織文化，借鑒、采取個(gè)別對(duì)項(xiàng)目有效的XP做法，將RUP進(jìn)行一定的剪裁，形成自己的軟件開發(fā)過程。 在項(xiàng)目的實(shí)施過程中，我們感覺到XP對(duì)于執(zhí)行者的要求是比較高的，因?yàn)樗箝_發(fā)團(tuán)隊(duì)必須具備熟練的代碼設(shè)計(jì)技能和嚴(yán)格的測(cè)試保障技術(shù)，了解面向?qū)ο蠛湍Ｊ?，掌握了重?gòu)和OO測(cè)試技術(shù)，習(xí)慣了測(cè)試先行的開發(fā)方式等等。 因此，對(duì)于目前國(guó)內(nèi)的軟件開發(fā)組織來說，應(yīng)該首先加強(qiáng)對(duì)于軟件開發(fā)過程化和系統(tǒng)架構(gòu)設(shè)計(jì)的掌握，然后，才是利用XP等敏捷方法來完善軟件開發(fā)過程。 參考文獻(xiàn) [1] Software Engineering a Practitioner‘s Approach ( Fifth Edition) Roger S. Pressman [2] Is Design Dead Martin Fowler [3] XP Explored William C. Wake [4] XP Distilled Christopher T. Collins, Roy W. Miller [5] XP的價(jià)值和局限 X-Programmer 15 張恂 作者簡(jiǎn)介： 曲俊生，Ion Global 軟件工程師。有近5年的軟件開發(fā)經(jīng)驗(yàn)，尤其擅長(zhǎng)網(wǎng)絡(luò)應(yīng)用程序的開發(fā)。目前他的研究與開發(fā)興趣在J2EE, XP, Refactoring 以及Design Pattern。目前居住在上海，喜歡爬山、旅游等休閑活動(dòng)。 |
|
|
