從一個項目談XP在國内的應用

曲俊生（來自IBM DW中國）　　　　2003年05月03日

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