目前國內對于XP方面的研究和應用此起彼伏，各種關于XP的書籍爭相出版，對于以XP為代表的"敏捷軟件工程"方法的爭論也在網絡上隨處可見。之所以出現這樣的情況，是因為國內的用戶在軟件項目的實施過程中遇到了很多問題，例如項目的交付時間推遲、用戶需求變更頻繁等，我們的軟件工程師迫切的希望能夠找到解決問題的"銀彈"。對于高度動態(tài)、通過非常短的迭代周期來應對需求變化的極限編程方法論來講，確實能夠從一定程度上解決問題。但是，對于國內的軟件開發(fā)項目來說，XP并非"銀彈"，它的一些實踐不是都適合國內的情況。本文結合一個具體的軟件開發(fā)項目，討論一下XP 在國內的應用情況。
XP簡介
傳統軟件開發(fā)方法
在最近的數十年中，很多企業(yè)的CEO們都面臨著增加盈利的壓力，因此，他們采用各種方法，例如裁員、業(yè)務外包、BPR、ERP、CRM等等。以上種種，使得世界500強的大部分企業(yè)在20世紀90年代的后期一直保持者二位數的利潤增長。但是很多跡象表明，在傳統的企業(yè)業(yè)務模型中已經沒有多少可供削減開支的地方，因此，需要進行徹底的改革。在軟件開發(fā)領域，情況更是如此。
自上個世紀60年代以來，軟件工程思想逐漸形成與發(fā)展，也出現了很多軟件開發(fā)模型與方法，例如瀑布模型、快速原型、增量模型和螺旋模型等[1]。而在90年代以后，卡耐基梅隆軟件學院推出的CMM，更是對于軟件開發(fā)的過程管理，提出了確切的衡量指標。但是，最近的研究表明，有50％的項目會拖延交付，有30％以上的項目會超出預算，軟件開發(fā)領域的項目情況比軟件工程剛剛提出的時候相比，只是有很小的提高。詳細的數據[4]（數據來自美國GSM研究機構, Michael Mah）如下表所示：
傳統的軟件開發(fā)過程，以RUP為代表，強調項目的可控性，是一個用例驅動的基于UML和構件式架構的迭代增量式開發(fā)過程。RUP定義了初始、細化、實現和部署4個階段，分別對應著關鍵里程碑的劃分。RUP對于角色、流程、工件和活動的要求是靈活、可配置的，所以它廣泛的適用于各種類型的項目。但是，在RUP的各個流程碑，都規(guī)定了要交付的成果，尤其是對于需求的變更以及文檔，它強調及時的更新與同步。以上這些都決定了RUP是一種重量級的軟件開發(fā)方法，比較適合大中型的項目和產品開發(fā)。
XP以及其核心價值
最近，出現了很多輕量型的軟件開發(fā)方法，例如水晶模型、適應模型以及極限編程等。它們都強調，軟件開發(fā)是人與人合作進行的過程，因此成功的軟件開發(fā)過程應該充分利用人的優(yōu)勢，而弱化人的缺點，突出了人在軟件開發(fā)過程中的作用[2]。
Kent Beck在XP的開篇之作《Extreme Programming Explained - Embrace Change》中提出了極限編程這一創(chuàng)新的軟件過程方法論。極限編程是一種高度動態(tài)的過程，它通過非常短的迭代周期來應對需求的變化。在極限編程中，包括四個基本活動：編碼、測試、聆聽與反饋，XP項目的狀態(tài)變遷如下圖所示[3][4]：
Kent Beck指出，XP有四個核心價值是我們應該注意的[3][4]：
· 溝通：項目中發(fā)現的問題往往是由于開發(fā)人員與設計人員、設計人員與客戶之間的溝通不暢造成的，因此，在XP項目中沒有溝通是不可能的。
· 簡單：XP認為應該盡量保持代碼的簡單，只要它能工作就可以。Kent Beck指出與其實現一個復雜的的系統，不如設計一個能夠滿足目前需要的、簡單的系統，因為你所考慮的情況可能永遠都不會發(fā)生。
· 反饋：盡快獲得用戶的反饋，并且越詳細越好，使得開發(fā)人員能夠保證自己的成果符合用戶的需要。
· 勇氣：這是最重要的核心價值。因為XP強調要"擁抱變化"，因此對于用戶的反饋，要勇于對自己的代碼進行修改，丟掉壞的代碼。
下面我們將要談到的XP的實踐就體現了上述四個核心價值。實際上，XP中并沒有多少新的觀點，它的一些實踐也都是長久以來都在使用中的。
XP的適用環(huán)境
從XP項目狀態(tài)圖以及它的核心價值中我們可以看到，XP弱化針對未來需求的設計，非常注重當前的簡化。它的實踐，有一個非常關鍵的假設就是開發(fā)人員只注重眼前需求而依賴重構來適應需求的變動所帶來的風險與開銷要小于需求變化使得事先充分設計失效的代價；反之，實施XP就是不明智的[5]。
因此，XP適合規(guī)模小、進度緊、需求變化大、質量要求嚴的項目。它希望以的效率和質量來解決用戶目前的問題，以的靈活性和最小的代價來滿足用戶未來的需求，XP在平衡短期和長期利益之間做了巧妙的選擇。
我們可以看到，XP并不是解決問題的"銀彈"，它也有不適合的情況。Beck曾經建議在以下情況下不宜采用XP：
· 中大型的項目（項目團隊超過10人）；
· 重構會導致大量開銷的應用；
· 需要很長的編譯或者測試周期的系統；
· 不容易進行測試的應用；
· 團隊人員異地分布的項目；
· 不能接收XP文化的組織和團隊；
項目概況及背景
我們公司是亞洲的電子商務解決方案供應商，在J2EE架構的項目執(zhí)行方面有豐富的經驗，結合RUP形成了自己的一套電子商務項目實施方法論，并在多個項目中成功進行實施。同時，由于具體項目時間和成本的限制，也出現了許多問題，主要有以下兩點：
項目交付后，用戶提出很多的修改意見，有些甚至涉及系統架構的修改：出現這種情況的主要原因是很多項目雖然是采用增量迭代式的開發(fā)周期，但是在部署前才發(fā)布版本，用戶只是在項目部署后才看到真正的系統，因此會發(fā)現很多界面、流程等方面的問題；
對于用戶提交BUG的修改周期過長：開發(fā)人員在作開發(fā)的時候，對于單元測試的重視程度不夠，模塊開發(fā)結束后就提交給測試人員進行測試，而測試人員由于時間的關系，并不能發(fā)現所有的問題；在用戶提交BUG后，開發(fā)人員由于項目接近尾聲，對于代碼的修改產生惰性，同時又沒有形成有效的回歸測試方法，因此，修改的周期比較長。
針對XP的核心價值，可以看到，如果我們能夠加強與用戶的溝通、增加項目中測試實施的力度、提高開發(fā)人員的勇氣，就可以從一定程度上解決上述問題。
從2001年開始，公司內部展開對于XP等敏捷方法的研究，希望能夠借鑒一些做法，來完善項目方法論。
2002年5月，我們決定在公司的一個新的項目中啟用XP的一些實踐，來檢驗其效果。該項目是為一家國際知名手機生產廠商的合作伙伴提供手機配件定購、申請、回收等服務，項目的情況如下表所示：
從上表中可以看出，該項目是一個小型項目，而且項目小組成員對于XP在項目開始之前都有一定的了解，另一方面，客戶要求的項目周期比我們預期估計的時間有一定的余地，因此我們決定利用這個項目進行XP的試驗性實踐。
XP的實踐以及在項目中的應用
在項目執(zhí)行過程中，我們基本上還是采用RUP的軟件過程，而沒有死板的套用XP 的做法，例如：在需求分析階段，我們還是采用Use Case來對需求進行描述，而不是XP規(guī)定的CRC卡片；在系統分析與設計階段，首先進行系統的架構設計，而不是簡單的套用XP的"簡單設計"實踐。
下面我們結合項目的具體情況，討論一下XP的12個實踐。
現場客戶 ( On-site Customer )
· XP： 要求至少有一名實際的客戶代表在整個項目開發(fā)周期在現場負責確定需求、回答團隊問題以及編寫功能驗收測試。
· 評述：現場用戶可以從一定程度上解決項目團隊與客戶溝通不暢的問題，但是對于國內用戶來講，目前階段還不能保證有一定技術層次的客戶常駐開發(fā)現場。解決問題的方法有兩種：一是可以采用在客戶那里現場開發(fā)的方式；二是采用有效的溝通方式。
· 項目：首先，我們在項目合同簽署前，向客戶進行項目開發(fā)方法論的介紹，使得客戶清楚項目開發(fā)的階段、各個階段要發(fā)布的成果以及需要客戶提供的支持等；其次，由項目經理每周向客戶匯報項目的進展情況，提供目前發(fā)布版本的位置，并提示客戶系統相應的反饋與支持。
代碼規(guī)范 ( Code Standards )
· XP： 強調通過指定嚴格的代碼規(guī)范來進行溝通，盡可能減少不必要的文檔。
· 評述： XP對于代碼規(guī)范的實踐，具有雙重含義：一是希望通過建立統一的代碼規(guī)范，來加強開發(fā)人員之間的溝通，同時為代碼走查提供了一定的標準；二是希望減少項目開發(fā)過程中的文檔，XP認為代碼是的文檔。
對于目前國內的大多數項目團隊來說，建立有效的代碼規(guī)范，加強團隊內代碼的統一性，是理所當然的；但是，認為代碼可以代替文檔卻是不可取的，因為代碼的可讀性與規(guī)范的文檔相比合適由一定的差距。
同時，如果沒有統一的代碼規(guī)范，代碼全體擁有就無從談起。
· 項目： 在項目實施初期，就由項目的技術經理建立代碼規(guī)范，并將其作為代碼審查的標準。
每周40小時工作制 ( 40-hour Week )
· XP： 要求項目團隊人員每周工作時間不能超過40小時，加班不得連續(xù)超過兩周，否則反而會影響生產率。
· 評述： 該實踐充分體現了XP的"以人為本"的原則。但是，如果要真正的實施下去，對于項目進度和工作量合理安排的要求就比較高。
· 項目： 由于項目的工期比較充裕，因此，很幸運的是我們并沒有違反該實踐。
計劃博弈 ( Planning Game )
XP： 要求結合項目進展和技術情況，確定下一階段要開發(fā)與發(fā)布的系統范圍。
· 評述： 項目的計劃在建立起來以后，需要根據項目的進展來進行調整，一成不變的計劃是不存在。因此，項目團隊需要控制風險、預見變化，從而制定有效、可行的項目計劃。
· 項目： 在系統實現前，我們首先按照需求的優(yōu)先級做了迭代周期的劃分，將高風險的需求優(yōu)先實現；同時，項目團隊每天早晨參加一個15分鐘的項目會議，確定當天以及目前迭代周期中每個成員要完成的任務。
XP簡介
傳統軟件開發(fā)方法
在最近的數十年中，很多企業(yè)的CEO們都面臨著增加盈利的壓力，因此，他們采用各種方法，例如裁員、業(yè)務外包、BPR、ERP、CRM等等。以上種種，使得世界500強的大部分企業(yè)在20世紀90年代的后期一直保持者二位數的利潤增長。但是很多跡象表明，在傳統的企業(yè)業(yè)務模型中已經沒有多少可供削減開支的地方，因此，需要進行徹底的改革。在軟件開發(fā)領域，情況更是如此。
自上個世紀60年代以來，軟件工程思想逐漸形成與發(fā)展，也出現了很多軟件開發(fā)模型與方法，例如瀑布模型、快速原型、增量模型和螺旋模型等[1]。而在90年代以后，卡耐基梅隆軟件學院推出的CMM，更是對于軟件開發(fā)的過程管理，提出了確切的衡量指標。但是，最近的研究表明，有50％的項目會拖延交付，有30％以上的項目會超出預算，軟件開發(fā)領域的項目情況比軟件工程剛剛提出的時候相比，只是有很小的提高。詳細的數據[4]（數據來自美國GSM研究機構, Michael Mah）如下表所示：
傳統的軟件開發(fā)過程，以RUP為代表，強調項目的可控性，是一個用例驅動的基于UML和構件式架構的迭代增量式開發(fā)過程。RUP定義了初始、細化、實現和部署4個階段，分別對應著關鍵里程碑的劃分。RUP對于角色、流程、工件和活動的要求是靈活、可配置的，所以它廣泛的適用于各種類型的項目。但是，在RUP的各個流程碑，都規(guī)定了要交付的成果，尤其是對于需求的變更以及文檔，它強調及時的更新與同步。以上這些都決定了RUP是一種重量級的軟件開發(fā)方法，比較適合大中型的項目和產品開發(fā)。
XP以及其核心價值
最近，出現了很多輕量型的軟件開發(fā)方法，例如水晶模型、適應模型以及極限編程等。它們都強調，軟件開發(fā)是人與人合作進行的過程，因此成功的軟件開發(fā)過程應該充分利用人的優(yōu)勢，而弱化人的缺點，突出了人在軟件開發(fā)過程中的作用[2]。
Kent Beck在XP的開篇之作《Extreme Programming Explained - Embrace Change》中提出了極限編程這一創(chuàng)新的軟件過程方法論。極限編程是一種高度動態(tài)的過程，它通過非常短的迭代周期來應對需求的變化。在極限編程中，包括四個基本活動：編碼、測試、聆聽與反饋，XP項目的狀態(tài)變遷如下圖所示[3][4]：
Kent Beck指出，XP有四個核心價值是我們應該注意的[3][4]：
· 溝通：項目中發(fā)現的問題往往是由于開發(fā)人員與設計人員、設計人員與客戶之間的溝通不暢造成的，因此，在XP項目中沒有溝通是不可能的。
· 簡單：XP認為應該盡量保持代碼的簡單，只要它能工作就可以。Kent Beck指出與其實現一個復雜的的系統，不如設計一個能夠滿足目前需要的、簡單的系統，因為你所考慮的情況可能永遠都不會發(fā)生。
· 反饋：盡快獲得用戶的反饋，并且越詳細越好，使得開發(fā)人員能夠保證自己的成果符合用戶的需要。
· 勇氣：這是最重要的核心價值。因為XP強調要"擁抱變化"，因此對于用戶的反饋，要勇于對自己的代碼進行修改，丟掉壞的代碼。
下面我們將要談到的XP的實踐就體現了上述四個核心價值。實際上，XP中并沒有多少新的觀點，它的一些實踐也都是長久以來都在使用中的。
XP的適用環(huán)境
從XP項目狀態(tài)圖以及它的核心價值中我們可以看到，XP弱化針對未來需求的設計，非常注重當前的簡化。它的實踐，有一個非常關鍵的假設就是開發(fā)人員只注重眼前需求而依賴重構來適應需求的變動所帶來的風險與開銷要小于需求變化使得事先充分設計失效的代價；反之，實施XP就是不明智的[5]。
因此，XP適合規(guī)模小、進度緊、需求變化大、質量要求嚴的項目。它希望以的效率和質量來解決用戶目前的問題，以的靈活性和最小的代價來滿足用戶未來的需求，XP在平衡短期和長期利益之間做了巧妙的選擇。
我們可以看到，XP并不是解決問題的"銀彈"，它也有不適合的情況。Beck曾經建議在以下情況下不宜采用XP：
· 中大型的項目（項目團隊超過10人）；
· 重構會導致大量開銷的應用；
· 需要很長的編譯或者測試周期的系統；
· 不容易進行測試的應用；
· 團隊人員異地分布的項目；
· 不能接收XP文化的組織和團隊；
項目概況及背景
我們公司是亞洲的電子商務解決方案供應商，在J2EE架構的項目執(zhí)行方面有豐富的經驗，結合RUP形成了自己的一套電子商務項目實施方法論，并在多個項目中成功進行實施。同時，由于具體項目時間和成本的限制，也出現了許多問題，主要有以下兩點：
項目交付后，用戶提出很多的修改意見，有些甚至涉及系統架構的修改：出現這種情況的主要原因是很多項目雖然是采用增量迭代式的開發(fā)周期，但是在部署前才發(fā)布版本，用戶只是在項目部署后才看到真正的系統，因此會發(fā)現很多界面、流程等方面的問題；
對于用戶提交BUG的修改周期過長：開發(fā)人員在作開發(fā)的時候，對于單元測試的重視程度不夠，模塊開發(fā)結束后就提交給測試人員進行測試，而測試人員由于時間的關系，并不能發(fā)現所有的問題；在用戶提交BUG后，開發(fā)人員由于項目接近尾聲，對于代碼的修改產生惰性，同時又沒有形成有效的回歸測試方法，因此，修改的周期比較長。
針對XP的核心價值，可以看到，如果我們能夠加強與用戶的溝通、增加項目中測試實施的力度、提高開發(fā)人員的勇氣，就可以從一定程度上解決上述問題。
從2001年開始，公司內部展開對于XP等敏捷方法的研究，希望能夠借鑒一些做法，來完善項目方法論。
2002年5月，我們決定在公司的一個新的項目中啟用XP的一些實踐，來檢驗其效果。該項目是為一家國際知名手機生產廠商的合作伙伴提供手機配件定購、申請、回收等服務，項目的情況如下表所示：
從上表中可以看出，該項目是一個小型項目，而且項目小組成員對于XP在項目開始之前都有一定的了解，另一方面，客戶要求的項目周期比我們預期估計的時間有一定的余地，因此我們決定利用這個項目進行XP的試驗性實踐。
XP的實踐以及在項目中的應用
在項目執(zhí)行過程中，我們基本上還是采用RUP的軟件過程，而沒有死板的套用XP 的做法，例如：在需求分析階段，我們還是采用Use Case來對需求進行描述，而不是XP規(guī)定的CRC卡片；在系統分析與設計階段，首先進行系統的架構設計，而不是簡單的套用XP的"簡單設計"實踐。
下面我們結合項目的具體情況，討論一下XP的12個實踐。
現場客戶 ( On-site Customer )
· XP： 要求至少有一名實際的客戶代表在整個項目開發(fā)周期在現場負責確定需求、回答團隊問題以及編寫功能驗收測試。
· 評述：現場用戶可以從一定程度上解決項目團隊與客戶溝通不暢的問題，但是對于國內用戶來講，目前階段還不能保證有一定技術層次的客戶常駐開發(fā)現場。解決問題的方法有兩種：一是可以采用在客戶那里現場開發(fā)的方式；二是采用有效的溝通方式。
· 項目：首先，我們在項目合同簽署前，向客戶進行項目開發(fā)方法論的介紹，使得客戶清楚項目開發(fā)的階段、各個階段要發(fā)布的成果以及需要客戶提供的支持等；其次，由項目經理每周向客戶匯報項目的進展情況，提供目前發(fā)布版本的位置，并提示客戶系統相應的反饋與支持。
代碼規(guī)范 ( Code Standards )
· XP： 強調通過指定嚴格的代碼規(guī)范來進行溝通，盡可能減少不必要的文檔。
· 評述： XP對于代碼規(guī)范的實踐，具有雙重含義：一是希望通過建立統一的代碼規(guī)范，來加強開發(fā)人員之間的溝通，同時為代碼走查提供了一定的標準；二是希望減少項目開發(fā)過程中的文檔，XP認為代碼是的文檔。
對于目前國內的大多數項目團隊來說，建立有效的代碼規(guī)范，加強團隊內代碼的統一性，是理所當然的；但是，認為代碼可以代替文檔卻是不可取的，因為代碼的可讀性與規(guī)范的文檔相比合適由一定的差距。
同時，如果沒有統一的代碼規(guī)范，代碼全體擁有就無從談起。
· 項目： 在項目實施初期，就由項目的技術經理建立代碼規(guī)范，并將其作為代碼審查的標準。
每周40小時工作制 ( 40-hour Week )
· XP： 要求項目團隊人員每周工作時間不能超過40小時，加班不得連續(xù)超過兩周，否則反而會影響生產率。
· 評述： 該實踐充分體現了XP的"以人為本"的原則。但是，如果要真正的實施下去，對于項目進度和工作量合理安排的要求就比較高。
· 項目： 由于項目的工期比較充裕，因此，很幸運的是我們并沒有違反該實踐。
計劃博弈 ( Planning Game )
XP： 要求結合項目進展和技術情況，確定下一階段要開發(fā)與發(fā)布的系統范圍。
· 評述： 項目的計劃在建立起來以后，需要根據項目的進展來進行調整，一成不變的計劃是不存在。因此，項目團隊需要控制風險、預見變化，從而制定有效、可行的項目計劃。
· 項目： 在系統實現前，我們首先按照需求的優(yōu)先級做了迭代周期的劃分，將高風險的需求優(yōu)先實現；同時，項目團隊每天早晨參加一個15分鐘的項目會議，確定當天以及目前迭代周期中每個成員要完成的任務。