從一個專案談XP在國內的應用

一． XP簡介

1.1 傳統軟體開發方法

在最近的數十年中，很多企業的CEO們都面臨著增加盈利的壓力，因此，他們採用各種方法，例如裁員、業務外包、BPR、ERP、CRM等等。以上種種，使得世界500強的大部分企業在20世紀90年代的後期一直保持者二位數的利潤增長。但是很多跡象表明，在傳統的企業業務模型中已經沒有多少可供削減開支的地方，因此，需要進行徹底的改革。在軟體開發領域，情況更是如此。

自上個世紀60年代以來，軟體工程思想逐漸形成與發展，也出現了很多軟體開發模型與方法，例如瀑布模型、快速原型、增量模型和螺旋模型等[1]。而在90年代以後，卡耐基梅隆軟體學院推出的CMM，更是對於軟體開發的過程管理，提出了確切的衡量指標。但是，最近的研究表明，有50％的專案會拖延交付，有30％以上的專案會超出預算，軟體開發領域的專案情況比軟體工程剛剛提出的時候相比，只是有很小的提高。詳細的資料[4]（資料來自美國GSM研究機構, Michael Mah）如下表所示：

政府資訊部門 ( 1979 )

50% 超出預算60％ 延期交付45％ 不能使用29％ 無法交付2％ 交付後不能使用

來自各個行業的210個專案 ( 1997-1999)

40％ 專案延期交付，平均延期交付時間67%30% 專案超出預算，平均超支167％

傳統的軟體開發過程，以RUP為代表，強調專案的可控性，是一個用例驅動的基於UML和構件式架構的迭代增量式開發過程。RUP定義了初始、細化、實現和部署4個階段，分別對應著關鍵里程碑的劃分。RUP對於角色、流程、工件和活動的要求是靈活、可配置的，所以它廣泛的適用於各種型別的專案。但是，在RUP的各個流程碑，都規定了要交付的成果，尤其是對於需求的變更以及文件，它強調及時的更新與同步。以上這些都決定了RUP是一種重量級的軟體開發方法，比較適合大中型的專案和產品開發。

1.2 XP以及其核心價值

最近，出現了很多輕量型的軟體開發方法，例如水晶模型、適應模型以及極限程式設計等。它們都強調，軟體開發是人與人合作進行的過程，因此成功的軟體開發過程應該充分利用人的優勢，而弱化人的缺點，突出了人在軟體開發過程中的作用[2]。

Kent Beck在XP的開篇之作《Extreme Programming Explained - Embrace Change》中提出了極限程式設計這一創新的軟體過程方法論。極限程式設計是一種高度動態的過程，它通過非常短的迭代週期來應對需求的變化。在極限程式設計中，包括四個基本活動：編碼、測試、聆聽與反饋，XP專案的狀態變遷如下圖所示[3][4]：

　

Kent Beck指出，XP有四個核心價值是我們應該注意的[3][4]：

• 溝通：專案中發現的問題往往是由於開發人員與設計人員、設計人員與客戶之間的溝通不暢造成的，因此，在XP專案中沒有溝通是不可能的。
• 簡單：XP認為應該儘量保持程式碼的簡單，只要它能工作就可以。Kent Beck指出與其實現一個複雜的的系統，不如設計一個能夠滿足目前需要的、簡單的系統，因為你所考慮的情況可能永遠都不會發生。
• 反饋：儘快獲得使用者的反饋，並且越詳細越好，使得開發人員能夠保證自己的成果符合使用者的需要。
• 勇氣：這是最重要的核心價值。因為XP強調要"擁抱變化"，因此對於使用者的反饋，要勇於對自己的程式碼進行修改，丟掉壞的程式碼。

下面我們將要談到的XP的最佳實踐就體現了上述四個核心價值。實際上，XP中並沒有多少新的觀點，它的一些最佳實踐也都是長久以來都在使用中的。

1.3 XP的適用環境

從XP專案狀態圖以及它的核心價值中我們可以看到，XP弱化針對未來需求的設計，非常注重當前的簡化。它的實踐，有一個非常關鍵的假設就是開發人員只注重眼前需求而依賴重構來適應需求的變動所帶來的風險與開銷要小於需求變化使得事先充分設計失效的代價；反之，實施XP就是不明智的[5]。

因此, XP適合規模小、進度緊、需求變化大、質量要求嚴的專案。它希望以最高的效率和質量來解決使用者目前的問題，以最大的靈活性和最小的代價來滿足使用者未來的需求，XP在平衡短期和長期利益之間做了巧妙的選擇。

我們可以看到，XP並不是解決問題的"銀彈"，它也有不適合的情況。Beck曾經建議在以下情況下不宜採用XP：

• 中大型的專案（專案團隊超過10人）；
• 重構會導致大量開銷的應用；
• 需要很長的編譯或者測試周期的系統；
• 不容易進行測試的應用；
• 團隊人員異地分佈的專案；
• 不能接收XP文化的組織和團隊；

二． 專案概況及背景

我們公司是亞洲領先的電子商務解決方案供應商，在J2EE架構的專案執行方面有豐富的經驗，結合RUP形成了自己的一套電子商務專案實施方法論，並在多個專案中成功進行實施。同時，由於具體專案時間和成本的限制，也出現了許多問題，主要有以下兩點：

• 專案交付後，使用者提出很多的修改意見，有些甚至涉及系統架構的修改：出現這種情況的主要原因是很多專案雖然是採用增量迭代式的開發週期，但是在部署前才釋出版本，使用者只是在專案部署後才看到真正的系統，因此會發現很多介面、流程等方面的問題；
• 對於使用者提交BUG的修改週期過長：開發人員在作開發的時候，對於單元測試的重視程度不夠，模組開發結束後就提交給測試人員進行測試，而測試人員由於時間的關係，並不能發現所有的問題；在使用者提交BUG後，開發人員由於專案接近尾聲，對於程式碼的修改產生惰性，同時又沒有形成有效的迴歸測試方法，因此，修改的週期比較長。

針對XP的核心價值，可以看到，如果我們能夠加強與使用者的溝通、增加專案中測試實施的力度、提高開發人員的勇氣，就可以從一定程度上解決上述問題。

從2001年開始，公司內部展開對於XP等敏捷方法的研究，希望能夠借鑑一些做法，來完善專案方法論。

2002年5月，我們決定在公司的一個新的專案中啟用XP的一些最佳實踐，來檢驗其效果。該專案是為一家國際知名手機生產廠商的合作伙伴提供手機配件定購、申請、回收等服務，專案的情況如下表所示：

條目              描述
======================================
專案名稱          合作伙伴管理系統
處理工作流程      9個
專案週期          43個工作日
專案金額          25萬
專案小組人員      5人，其中資深顧問2名
=======================================

從上表中可以看出，該專案是一個小型專案，而且專案小組成員對於XP在專案開始之前都有一定的瞭解，另一方面，客戶要求的專案週期比我們預期估計的時間有一定的餘地，因此我們決定利用這個專案進行XP的試驗性實踐。

三． XP的最佳實踐以及在專案中的應用

在專案執行過程中，我們基本上還是採用RUP的軟體過程，而沒有死板的套用XP 的做法，例如：在需求分析階段，我們還是採用Use Case來對需求進行描述，而不是XP規定的CRC卡片；在系統分析與設計階段，首先進行系統的架構設計，而不是簡單的套用XP的"簡單設計"實踐。

下面我們結合專案的具體情況，討論一下XP的12個最佳實踐。

1. 現場客戶 ( On-site Customer )
   • XP： 要求至少有一名實際的客戶代表在整個專案開發週期在現場負責確定需求、回答團隊問題以及編寫功能驗收測試。
   • 評述：現場使用者可以從一定程度上解決專案團隊與客戶溝通不暢的問題，但是對於國內使用者來講，目前階段還不能保證有一定技術層次的客戶常駐開發現場。解決問題的方法有兩種：一是可以採用在客戶那裡現場開發的方式；二是採用有效的溝通方式。
   • 專案：首先，我們在專案合同簽署前，向客戶進行專案開發方法論的介紹，使得客戶清楚專案開發的階段、各個階段要釋出的成果以及需要客戶提供的支援等；其次，由專案經理每週向客戶彙報專案的進展情況，提供目前釋出版本的位置，並提示客戶系統相應的反饋與支援。
2. 程式碼規範 ( Code Standards )
   • XP： 強調通過指定嚴格的程式碼規範來進行溝通，儘可能減少不必要的文件。
   • 評述： XP對於程式碼規範的實踐，具有雙重含義：一是希望通過建立統一的程式碼規範，來加強開發人員之間的溝通，同時為程式碼走查提供了一定的標準；二是希望減少專案開發過程中的文件，XP認為程式碼是最好的文件。
     對於目前國內的大多數專案團隊來說，建立有效的程式碼規範，加強團隊內程式碼的統一性，是理所當然的；但是，認為程式碼可以代替文件卻是不可取的，因為程式碼的可讀性與規範的文件相比合適由一定的差距。
     同時，如果沒有統一的程式碼規範，程式碼全體擁有就無從談起。
   • 專案： 在專案實施初期，就由專案的技術經理建立程式碼規範，並將其作為程式碼審查的標準。
3. 每週40小時工作制 ( 40-hour Week )
   • XP： 要求專案團隊人員每週工作時間不能超過40小時，加班不得連續超過兩週，否則反而會影響生產率。
   • 評述： 該實踐充分體現了XP的"以人為本"的原則。但是，如果要真正的實施下去，對於專案進度和工作量合理安排的要求就比較高。
   • 專案： 由於專案的工期比較充裕，因此，很幸運的是我們並沒有違反該實踐。
4. 計劃博弈 ( Planning Game )
   • XP： 要求結合專案進展和技術情況，確定下一階段要開發與釋出的系統範圍。
   • 評述： 專案的計劃在建立起來以後，需要根據專案的進展來進行調整，一成不變的計劃是不存在。因此，專案團隊需要控制風險、預見變化，從而制定有效、可行的專案計劃。
   • 專案： 在系統實現前，我們首先按照需求的優先順序做了迭代週期的劃分，將高風險的需求優先實現；同時，專案團隊每天早晨參加一個15分鐘的專案會議，確定當天以及目前迭代週期中每個成員要完成的任務。
5. 系統隱喻 ( System Metaphor )
   • XP： 通過隱喻來描述系統如何運作、新的功能以何種方式加入到系統。它通常包含了一些可以參照和比較的類和設計模式。XP不需要事先進行詳細的架構設計。
   • 評述： XP在系統實現初期不需要進行詳細的架構設計，而是在迭代週期中不斷的細化架構。對於小型的系統或者架構設計的分析會推遲整個專案的計劃的情況下，逐步細化系統架構倒是可以的；但是，對於大型系統或者是希望採用新架構的系統，就需要在專案初期進行相信的系統架構設計，並在第一個迭代週期中進行驗證，同時在後續迭代週期中逐步進行細化。
   • 專案： 開發團隊在設計初期，決定參照STRUTS框架，結合專案的情況，構建了針對工作流程處理的專案框架。首先，團隊決定在第一個迭代週期實現配件申請的工作流程，在實際專案開發中驗證了基本的程式框架；而後，又在其它迭代週期中，對框架逐漸精化。
6. 簡單設計 ( Simple Design )
   • XP： 認為程式碼的設計應該儘可能的簡單，只要滿足當前功能的要求，不多也不少。
   • 評述： 傳統的軟體開發過程，對於設計是自頂而下的，強調設計先行，在程式碼開始編寫之前，要有一個完美的設計模型。它的前提是需求不變化，或者很少變化；而XP認為需求是會經常變化的，因此設計不能一蹴而就，而應該是一項持續進行的過程。
     Kent Beck認為對於XP來說，簡單設計應該滿足以下幾個原則：
     1. 成功執行所有的測試；
     2. 不包含重複的程式碼；
     3. 向所有的開發人員清晰地描述編碼以及其內在關係；
     4. 儘可能包含最少的類與方法。
        對於國內大部分的軟體開發組織來說，應該首先確定一個靈活的系統架構，而後在每個迭代週期的設計階段可以採用XP的簡單設計原則，將設計進行到底。
   • 專案： 在專案的系統架構經過驗證後的迭代週期內，我們始終堅持簡單設計的原則，並按照Kent Beck的四項原則來進行有效的驗證。對於新的迭代週期中出現需要修改既有設計與程式碼的情況，首先對原有系統進行"程式碼重構"，而後再增加新的功能。
7. 測試驅動 ( Test-driven )
   • XP： 強調"測試先行"。在編碼開始之前，首先將測試寫好，而後再進行編碼，直至所有的測試都得以通過。
   • 評述： RUP與XP對測試都是非常的重視，只是兩者對於測試在整個專案開發週期內首先出現的位置處理不同。XP是一項測試驅動的軟體開發過程，它認為測試先行使得開發人員對自己的程式碼有足夠的信心，同時也有勇氣進行程式碼重構。測試應該實現一定的自動化，同時能夠清晰的給出測試成功或者失敗的結果。在這方面，xUnit測試框架做了很多的工作，因此很多實施XP的團隊，都採用它們進行測試工作。
   • 專案： 我們在專案初期就對JUNIT進行了一定的研究工作，在專案編碼中，採用JBUILDER6提供的測試框架進行測試類的編寫。但是，不是對所有的方法與用例都編寫，而只是針對關鍵方法類、重要業務邏輯處理類等進行。詳細的關於JUNIT測試框架的使用，請參見我的同事撰寫的另一篇文章(http://www-900.ibm.com/developerWorks/cn/java/l-junit/index.shtml)
8. 程式碼重構 ( Refactoring )
   • XP： 強調程式碼重構在其中的作用，認為開發人員應該經常進行重構，通常有兩個關鍵點應該進行重構：對於一個功能實現和實現後。
   • 評述： 程式碼重構是指在不改變系統行為的前提下，重新調整、優化系統的內部結構以減少複雜性、消除冗餘、增加靈活性和提高效能。重構不是XP所特有的行為，在任何的開發過程中都可能並且應該發生。
     在使用程式碼重構的時候要注意，不要過分的依賴重構，甚至輕視設計，否則，對於大中型的系統而言，將設計推遲或者乾脆不作設計，會造成一場災難。
   • 專案： 我們在專案中將JREFACTORY工具部署到JBuilder中進行程式碼的重構，重構的時間是在各個迭代週期的前後。程式碼重構在專案中的作用是改善既有設計，而不是代替設計。
9. 9) 成對程式設計 ( Pair Programming )
   • XP： 認為在專案中採用成對程式設計比獨自程式設計更加有效。成對程式設計是由兩個開發人員在同一臺電腦上共同編寫解決同一問題的程式碼，通常一個人負責寫編碼，而另一個負責保證程式碼的正確性與可讀性。
   • 評述： 其實，成對程式設計是一種非正式的同級評審 ( Peer Review )。它要求成對程式設計的兩個開發人員在性格和技能上應該相互匹配，目前在國內還不是十分適合推廣。成對程式設計只是加強開發人員溝通與評審的一種方式，而非唯一的方式。具體的方式可以結合專案的情況進行。
   • 專案： 我們在專案中並沒有採用成對程式設計的實踐，而是在專案實施的各個階段，加強了走查以及同級評審的力度。需求獲取、設計與分析都有多人蔘與，在成果提交後，交叉進行走查；而在編碼階段，開發人員之間也要在每個迭代週期後進行同時評審。
10. 　
    • XP： 認為開發小組的每個成員都有更改程式碼的權利，所有的人對於全部程式碼負責。
    • 評論： 程式碼全體擁有並不意味者開發人員可以互相推委責任，而是強調所有的人都要負責。如果一個開發人員的程式碼有錯誤，另外一個開發人員也可以進行BUG的修復。
      在目前，國內的軟體開發組織，可以在一定程度上實施該實踐，但是同時需要注意一定要有嚴格的程式碼控制管理。
    • 專案： 我們在專案開發初期，首先向開發團隊進行"程式碼全體擁有"的教育，同時要求開發人員不僅要了解系統的架構、自己的程式碼，同時也要了解其它開發人員的工作以及程式碼情況。這個實踐與同級評審有一定的互補作用，從而保證人員的變動不會對專案的進度造成很大的影響。
      在專案執行中，有一個開發人員由於參加培訓，缺席專案執行一週，由於實行了"程式碼全體擁有"的實踐，其它的開發人員成功地分擔了該成員的測試與開發任務，從而保證專案的如期交付。
11. 持續整合 ( Continuous Integration )
    • XP： 提倡在一天中整合系統多次，而且隨著需求的改變，要不斷的進行迴歸測試。因為，這樣可以使得團隊保持一個較高的開發速度，同時避免了一次系統整合的惡夢。
    • 評述： 持續整合也不是XP專有的最佳實踐，著名的微軟公司就有每日整合 ( Daily Build ) 的成功實踐。但是，要注意的是，持續整合也需要良好的軟體配置變更管理系統的有效支援。
    • 專案： 使用VSS作為軟體配置管理系統，堅持每天進行一次的系統整合，將已經完成的功能有效地結合起來，進行測試。
12. 小型釋出 ( Small Release )
    • XP： 強調在非常短的週期內以遞增的方式釋出新版本，從而可以很容易地估計每個迭代週期的進度，便於控制工作量和風險；同時，也可以及時處理使用者的反饋。
    • 評論： 小型釋出突出體現了敏捷方法的優點。RUP強調迭代式的開發，對於系統的釋出並沒有作出過多的規定。使用者在提交需求後，只有在部署時才能看到真正的系統，這樣就不利於迅速獲得使用者的反饋。
      如果能夠保證測試先行、程式碼重構、持續整合等最佳實踐，實現小型釋出也不是一件困難的事情，在有條件的組織可以考慮使用。
    • 專案： 專案在籌備階段就配置了一臺測試與釋出伺服器，在專案實施過程中，平均每兩週（一個迭代週期結束後）進行一個小型釋出；使用者在釋出後兩個工作日內，向專案小組提交"使用者接收測試報告"，由專案經理評估測試報告，將有效的BUG提交至Rational Clear Case，並分配給相應的開發人員。專案小組應該在下一個迭代週期結束前修復所有使用者提交的問題。

以上是XP的最佳實踐在專案中的應用情況，讓我們檢視以下該專案的詳細統計資料：

條 目 描 述
============================ 
專案開始時間       2002/4/25
專案預期結束時間   2002/6/28
專案實際結束日期   2002/7/2
專案預計成本       199080
專案實際成本       177340
CPI                1.155
SPI                1.028
============================

其中，專案執行過程中提交了一個"使用者需求變更"，該變更對於專案週期的影響為6個工作日。

專案實施後，在使用者接收測試中，只提交了2個BUG，而且在提交當天就得到了解決。目前，專案執行平穩，並得到了使用者的好評。因此，我們認為，XP在該專案中的實施有效地保證了專案質量和專案週期。

四． 總結

RUP與XP 都是在總結了很多專案實踐的過程中發展起來的軟體開發過程， 只是它們在處理需求變更的方法不同。其實它們還是有很多相似之處，例如，它們的基礎都是物件導向方法，都重視程式碼、文件的最小化和設計的簡化，採用動態適應變化的演進式迭代週期等等。

目前，國內執行XP的理想情況應該是：在保持組織既有的開發過程和生命週期模型的情況下，根據應用型別、專案特點和組織文化，借鑑、採取個別對專案有效的XP做法，將RUP進行一定的剪裁，形成自己的軟體開發過程。

在專案的實施過程中，我們感覺到XP對於執行者的要求是比較高的，因為它要求開發團隊必須具備熟練的程式碼設計技能和嚴格的測試保障技術，瞭解物件導向和模式，掌握了重構和OO測試技術，習慣了測試先行的開發方式等等。

因此，對於目前國內的軟體開發組織來說，應該首先加強對於軟體開發過程化和系統架構設計的掌握，然後，才是利用XP等敏捷方法來完善軟體開發過程。

 

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14639675/viewspace-582380/，如需轉載，請註明出處，否則將追究法律責任。