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