對于目前企業應用開發競爭日益激烈，需求變更頻繁，各個系統集成商都面臨巨大的生存壓力。其中有兩個方面表現尤其突出： 沒有統一的軟件開發過程或者照搬重量級的軟件開發過程，例如RUP等，但是往往由于時間等壓力的影響，并不能切實執行； 大部分企業仍然沒有擺脫手工作坊期間的做法，每個項目或者產品由于管理人員或者團隊的不同，重新設計系統框架，浪費大量的時間在結構驗證與調整上。
企業應用系統的開發中，需求的變更是項目中不變的東西，而且，為了保持開發的一致性和利益大化，系統集成商需要與客戶保持長期的合作。因此，采取演進式敏捷軟件開發，可以更好的保證項目質量。在所有的敏捷軟件開發方法中，XP是目前應用為廣泛的一種。它是一種高度動態的過程，它通過非常短的迭代周期來應對需求的變化；溝通、簡單、反饋和勇氣是它的四大核心價值。同時，它集中了業界的很多佳實踐，目前已經有18條之多，XP強調通過嚴格執行全部的佳實踐來獲得"極限"效果。
同時，出于復用和效率的考慮，尤其是對于系統集成商，企業應用系統應該具有自己的框架和結構。擁有具有良好性能、經過項目驗證的系統框架，結合有效的軟件開發過程，系統集成商可以快速、成功地開發企業應用系統。
為了更好的開發成功的系統，系統集成商們可以試著從以下兩個方面著手解決問題： 結合開源工具的支持，在組織內部實施"敏捷軟件開發方法"； 為核心業務領域建立靈活、有效的Framework。
由于目前很多企業應用是采用基于J2EE技術的網絡應用程序開發，因此，下面主要介紹基于JAVA的開源項目、工具的應用。
1、開源工具與XP
XP的12條佳實踐，對于所有的企業應用開發商而言，由于組織和文化的不同，不可能全部應用，但是，下面幾個實踐是有條件逐步實施的：
代碼規范：CODE STANDARD
測試驅動開發：TEST-DRIVEN DEVELOPMENT
日構建：DAILY BUILDING
持續集成：CONTINUOUS INTEGRATION
小步發布：SMALL RELEASE
每日晨會：DAILY MEETING
每周40小時工作：40-HOURS A WEEK
其中，CODE STANDARD和TDD是CONTINUOUS INTEGRATION、DAILY BUILDING和SMALL RELEASE的基礎；而DAILY MEETING和40-HOURS A WORK是單獨的實踐過程，可以與其他的實踐想結合，增強項目小組的溝通，激發士氣。
需要說明的是以上佳實踐并非XP所獨有，而是被多的軟件開發方法所應用，其中"日構建"在微軟的軟件開發方法中正式出現過。
1）代碼規范
雖然大部分的企業在一定程度上推行代碼標準與規范，而且對于使用JAVA的應用程序開發，也有SUN的推薦編碼規范，但是，實際的情況并不理想。
主要的原因在于：一方面，開發人員的習慣勢力很大；另一方面，代碼審查的力度不夠。如果能夠借助工具，從一定程度上幫助進行代碼標準的執行情況檢查，那么代碼審查可以著重檢查程序的邏輯和性能等方面。
開源產品CheckStyle (http://sourceforge.net/projects/checkstyle) 可以幫助開發組織解決代碼標準審查的問題。
目前的新版本為3.0，它提供了兩種運行方式：一種是命令行；一種是與Ant結合(Ant自1.5以后提供的OPTIONAL TASKS中有對于CheckStyle的支持)。同時，SourceForge中有對于JBuilder等流行IDE的插件支持，可以定義Global、Project級別上的屬性文件， 但是，目前只是支持2.42版本。
在3.x版本之前，CheckStyle的配置信息寫在Property File中；而在3.x之后，配置信息為XML文件，配置更加靈活。3.0的發布版本中提供了針對Sun Code Conventions的特定Check File，可以參考使用。
建議執行情況：
手動執行：開發人員在IDE中手動觸發CheckStyle檢查或者代碼審查時由審查者手動執行；
自動執行：將CheckStyle與源碼控制系統(CVS)結合，在源碼Checkin的時候進行規則判斷，如果不符合，則不允許代碼進入系統。
2）測試驅動開發
測試先行或者測試驅動是XP的基本實踐之一，同時測試在軟件開發中的重要作用正越來越得到人們的重視。審查和測試作為系統確認和驗證的有效方式，是項目質量保證的重要措施。
