摘 要: 通過XP在一個外貿管理信息系統的實際開發應用,闡述XP方法的主要特點。
關鍵詞: 極限編程 用戶故事 測試先行
XP(Extreme Programing)是敏捷編程方法的代表,適用于需求經常發生變化的中小型項目的開發。大多數用戶在系統發布之前,對系統功能往往只有一個模糊的想法,系統實際功能很難確定,且系統經常改變。XP是一種高度動態的過程,它通過非常短的迭代周期來應對需求的變化。某外貿公司欲開發一套外貿管理信息系統(FTMIS)軟件,但面臨時間緊迫、開發人員不足二個問題。基于此,這里利用極限編程方法XP進行系統開發,以求在最短的時間內獲得客戶最滿意的結果。
1 XP方法特點
XP運作項目的方法是將項目分成多次迭代,每一次迭代交付一個通過質量檢驗、可投入使用、包含了一些新實現的用戶故事(User stories,即用戶素材,定義一些小的功能模塊)軟件。圖1為一個XP項目狀態變遷的過程。
圖1中用戶故事同時產生需求和測試場景。從需求定義開始,XP省略了常規的系統和架構的設計步驟,在進行初步架構探索后,就從簡短的計劃發布直接進入編碼的迭代循環。測試場景則用來進行功能測試。編碼和設計是同時進行的,而且特別強調測試的重要性,提倡測試驅動。測試驅動的編碼方式實際是一個循環:寫對應新功能的測試→運行測試發現錯誤→編寫代碼→運行測試成功→寫對應新功能的測試。最后,測試完成并得到用戶認可后進行小型發布。
XP方法具有如下特點:
(1)重視客戶滿意度:XP的宗旨是開發滿足客戶需要的軟件。XP讓開發人員即使是在開發周期的后期也能自信地面對需求變化。
(2)強調團隊合作:項目經理、用戶和開發工程師共同組成一個完整的開發團隊,目的是開發出高質量的軟件。
(3)開發原則:XP從四個基本的方面改變原有的開發方式,即交流、簡單、反饋和勇氣,其目的在于克服由人為因素帶來的項目失敗。開發人員要與用戶、同事交流;系統設計必須簡單、明晰;通過不間斷的測試和發布得到用戶反饋;根據用戶的要求修改代碼,并爭取盡早地將軟件交付給用戶。在此基礎上,開發人員將會有足夠的勇氣面對需求和技術的變化。
(4)輕量級過程:XP認為重量級方法有些本末倒置,讓開發人員遠離了自己的專業,做了他們既不擅長、也不喜歡的事情。因此需要改變,讓開發人員提高效率。
2 XP在外貿管理信息系統開發中的應用
2.1 發布計劃
很多項目都會在前期消耗過多的時間,只有等所有的需求完成之后才開始設計工作。而采用XP方法,只需進行短時間的需求分析就可以開始設計工作。在經過一段時間的需求分析后,FTMIS的幾個管理模塊就基本確定了,如圖2所示,各個模塊之間的數據交換一般建立在共享數據庫上。
XP要求結合業務和技術情況,快速確定下一次發布的范圍,即小型發布。一個版本的發布周期一般以1～3個月合適。客戶代表確定系統的核心內容。甲方外貿公司主要做的是出口產品,所以該客戶代表制定了第一次發布需要實現的內容:商品管理、客戶管理、報價單管理、訂單管理、出口合同管理、業務報表,并將這些模塊細化為各個用戶故事(User stories),加上程序員對這些故事的估算,定下第一個發布計劃的時間是6周。客戶對每個發布版本的選擇在技術上可能不是最有效的,但可以確保每個版本都給企業帶來最大的收益。商業價值重于技術效率。在進行第一個版本的開發過程中,客戶繼續計劃了第二個版本和第三個版本要實現的內容,整個開發周期的發布計劃如表1所示。
小型發布的形式可以讓系統最快地投入生產。用戶的意見也可以迅速地得到反饋,及時在系統中得到解決。
2.2 迭代計劃
系統的一個版本被分解為若干個為時一周的迭代,以便盡快地從客戶代表處得到反饋意見。迭代長度在項目開始時即已選定,并且以后保持不變。客戶代表為用戶故事定下優先級后,程序員將這些故事分解為任務,每個任務執行的時間一般不超過一、二天。用戶故事根據迭代的時間適當進行合并或拆分或移到下一迭代周期。FRMIS的第一個版本的迭代計劃如表2所示。
XP提倡模塊間的松藕合,它可使系統因變更所受的影響最少。通常開發MIS的步驟都是先做用戶界面,再進行數據庫設計,最后制作報表。由于XP強調現場客戶的參與,該客戶代表從用戶角度考慮,在制定用戶故事時定下了報表故事的優先級最高的要求。根據客戶這一需求,先設計數據庫,用實驗數據或客戶提供的業務數據加以填充,然后制作報表。這樣當報表模塊開發出來并通過客戶驗收后,數據庫結構就非常確定了。這時再進行界面的開發,整體速度就提高很多。現場客戶的參與保證了開發出來的系統具備用戶最需要的功能。
2.3 開 發
XP方法的一個重要開發原則就是結對編程。結對編程是由二個開發人員在同一臺電腦上共同編寫解決同一問題的代碼。通常一個人負責寫代碼,另一個負責保證代碼的正確性和可讀性。結對編程的優點是:重要的設計決策至少由二個人決定,不易出現大的失誤;至少有二個人熟悉系統的每一部分,二人同時離開的可能性比較小,保證了開發的延續;二人可以很好地交流工具的使用,學習新的技巧,提高很快。但并不是任何時候結對編程都是絕對高效的。
XP還提倡在實現功能代碼之前,先編寫單元測試。由于系統需求的不斷變化,程序的測試也要頻繁地進行。為了降低開發成本,測試的自動化變得非常重要。系統采用DELPHI進行開發,所以將適于DELPHI的測試框架DUNIT集成到開發環境中。DUNIT使用很簡單,例如在開發中為編寫一個加密解密的類TCipher的測試單元TestCipher,首先在單元TestCipher中引用測試框架單元TestFramework,新建測試框架的主類TtestCase的子類TCipherTestCase,并重載TtestCase類的Setup和TearDown過程,這二個過程分別在測試之前和之后被調用。接下來在過程TCipherTestCase.TestEncryption中就可以編寫測試代碼,主要代碼及注解如下:
即可在程序初始化時對本測試類進行注冊。之后在工程源文件引用單元TestCipher,并將APPLICATION.RUN;改為GUITestRunner.RunRegisteredTests;即可運行已注冊的類。
編寫非GUI類的自動化測試單元所花費的時間不多,所帶來的好處顯而易見。但對有些GUI類的編寫測試就比較復雜,費時費力。所以在實際運用中應只選擇一定的合適的類來編寫單元測試,避免得不償失。
除了程序員編寫的單元測試外,在每個迭代完成時還應由客戶代表進行功能測試。實際用戶和開發人員看問題的角度有所不同,尤其在需求不完善的情況下。每周的迭代完成后的用戶測試使得意見反饋迅速而高效,減少了錯誤積累帶來的項目失敗風險,需要返工重構的工作量也不至太多。
整個FTMIS開發周期經過18周的迭代,到最后第三個版本發布時,系統已經穩定地為企業服務多時。同時因為開發過程比較嚴格地遵守代碼規范,大幅度減少了后期開發人員所不愿意寫的技術文檔。迭代周期及用戶故事制訂得比較合適也使開發人員始終工作在松緊有度的環境中。最終客戶和開發人員都得到了比較滿意的結果。
3 結束語
XP方法在FTMIS項目中的成功實施證明了以代碼設計為中心的自底向上過程的合理性和有效性。國內諸多中小型項目開發時都是時間緊迫、需求分析過于簡單,此時XP比重量級開發過程顯得更有優勢,并且易于實施。但對于XP的一些原則和方法,不能生搬硬套,應該靈活進行一些修剪補充,使項目獲得最大的成功。
參考文獻
1 Beck K.解析極限編程:擁抱變化.北京:人民郵電出版社,2002
2 Jeffries R,Anderson A,Hendrickson C.極限編程實施.北京:人民郵電出版社,2002
3 張恂.XP的價值和局限.非程序員,2002;(15)
4 Newkirk J,Martin R.極限編程實踐.北京:人民郵電出版社,2002