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

來源:互聯網
上載者:User
項目 目前國內對於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在系統實現初期不需要進行詳細的架構設計,而是在迭代周期中不斷的細化架構。對於小型的系統或者架構設計的分析會延遲整個項目的計劃的情況下,逐步細化系統架構倒是可以的;但是,對於大型系統或者是希望採用新架構的系統,就需要在項目初期進行相信的系統架構設計,並在第一個迭代周期中進行驗證,同時在後續迭代周期中逐步進行細化。 

  項目: Team Dev在設計初期,決定參照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的修複。 

  在目前,國內的軟體開發組織,可以在一定程度上實施該實踐,但是同時需要注意一定要有嚴格的代碼控制管理。 

  項目: 我們在項目開發初期,首先向Team Dev進行"代碼全體擁有"的教育,同時要求開發人員不僅要瞭解系統的架構、自己的代碼,同時也要瞭解其它開發人員的工作以及代碼情況。這個實踐與同儕審查有一定的互補作用,從而保證人員的變動不會對項目的進度造成很大的影響。 

  在項目執行中,有一個開發人員由於參加培訓,缺席項目執行一周,由於實行了"代碼全體擁有"的實踐,其它的開發人員成功地分擔了該成員的測試與開發工作單位,從而保證項目的如期交付。 

持續整合 ( 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對於執行者的要求是比較高的,因為它要求Team Dev必須具備熟練的代碼設計技能和嚴格的測試保障技術,瞭解物件導向和模式,掌握了重構和OO測試技術,習慣了測試先行的開發方式等等。 

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

  

相關文章

Cloud Intelligence Leading the Digital Future

Alibaba Cloud ACtivate Online Conference, Nov. 20th & 21st, 2019 (UTC+08)

Register Now >

Starter Package

SSD Cloud server and data transfer for only $2.50 a month

Get Started >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。