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

　　其中，項目執(zhí)行過程中提交了一個"用戶需求變更"，該變更對于項目周期的影響為6個工作日。
　　項目實施后，在用戶接收測試中，只提交了2個BUG，而且在提交當天就得到了解決。目前，項目運行平穩(wěn)，并得到了用戶的好評。因此，我們認為，XP在該項目中的實施有效地保證了項目質量和項目周期。
總結
　　RUP與XP 都是在總結了很多項目實踐的過程中發(fā)展起來的軟件開發(fā)過程， 只是它們在處理需求變更的方法不同。其實它們還是有很多相似之處，例如，它們的基礎都是面向對象方法，都重視代碼、文檔的最小化和設計的簡化，采用動態(tài)適應變化的演進式迭代周期等等。
　　目前，國內執(zhí)行XP的理想情況應該是：在保持組織既有的開發(fā)過程和生命周期模型的情況下，根據應用類型、項目特點和組織文化，借鑒、采取個別對項目有效的XP做法，將RUP進行一定的剪裁，形成自己的軟件開發(fā)過程。
　　在項目的實施過程中，我們感覺到XP對于執(zhí)行者的要求是比較高的，因為它要求開發(fā)團隊必須具備熟練的代碼設計技能和嚴格的測試保障技術，了解面向對象和模式，掌握了重構和OO測試技術，習慣了測試先行的開發(fā)方式等等。
　　因此，對于目前國內的軟件開發(fā)組織來說，應該首先加強對于軟件開發(fā)過程化和系統(tǒng)架構設計的掌握，然后，才是利用XP等敏捷方法來完善軟件開發(fā)過程。
參考文獻
　　[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年的軟件開發(fā)經驗，尤其擅長網絡應用程序的開發(fā)。目前他的研究與開發(fā)興趣在J2EE, XP, Refactoring 以及Design Pattern。目前居住在上海，喜歡爬山、旅游等休閑活動。

【?發(fā)表評論?0條?】