軟件開發的過程是：需求分析、設計、編碼和測試。
需求分析：不僅僅是用戶需求，應該是開發中遇到的所有的需求。比如，妳首先要知道做這個項目是為了解決什麽問題；測試案例中應該輸入什麽數據……為了清楚地知道這些需求，妳經常要和客戶、項目經理等交流。
設計：編碼前，肯定有個計劃告訴妳要做什麽，結構是怎樣等等。妳壹定要按照這個來做，否則可能會壹團糟。
編碼：如果在項目截止日，妳的程序不能跑起來或達不到客戶的要求，妳就拿不到錢。
測試：目的是讓妳知道，什麽時候算是完成了。如果妳聰明，妳就應該先寫測試，這樣可以及時知道妳是否真地完成了。否則，妳經常會不知道，到底有哪些功能是真正完成了，離預期目標還差多遠。 定義每個用戶需求的商業優先級；
制訂總體計劃，包括用多少投資、經過多長時間、達到什麽目的；
在項目開發過程中的每個工作周，都能讓投資獲得最大的收益；
通過重復運行妳所指定的功能測試，準確地掌握項目進展情況；
能隨時改變需求、功能或優先級，同時避免昂貴的再投資；能夠根據各種變化及時調整項目計劃；
能夠隨時取消項目；項目取消時，以前的開發工作不是壹堆垃圾，已開發完的功能是合乎要求的，正在進行或未完成的的工作則應該是不難接手的。 知道要做什麽，以及要優先做什麽；
工作有效率；
有問題或困難時，能得到客戶、同事、上級的回答或幫助；
對工作做評估，並根據周圍情況的變化及時重新評估；
積極承擔工作，而不是消極接受分配；
壹周40小時工作制，不加班。 靈巧的輕量級軟件開發方法
壹套軟件開發方法是由壹系列與開發相關的規則、規範和慣例。重量級的開發方法嚴格定義了許多的規則、流程和相關的文檔工作。靈巧的輕量級開發方法，其規則和文檔相對較少，流程更加靈活，實施起來相對較容易。
在軟件工程概念出現以前，程序員們按照自己喜歡的方式開發軟件。程序的質量很難控制，調試程序很繁瑣，程序員之間也很難讀懂對方寫的代碼。1968年，Edsger Dijkstra給CACM寫了壹封題為GOTO Statement Considered Harmful的信，軟件工程的概念由此誕生。程序員們開始摒棄以前的做法，轉而使用更系統、更嚴格的開發方法。為了使控制軟件開發和控制其它產品生產壹樣嚴格，人們陸續制定了很多規則和做法，發明了很多軟件工程方法，軟件質量開始得到大幅度提高。隨著遇到的問題更多，規則和流程也越來越精細和復雜。
到了今天，在實際開發過程中，很多規則已經難於遵循，很多流程復雜而難於理解，很多項目中文檔的制作過程正在失去控制。人們試圖提出更全面更好的壹攬子方案，或者寄希望於更復雜的、功能更強大的輔助開發工具（CaseTools），但總是不能成功，而且開發規範和流程變得越來越復雜和難以實施。
為了趕進度，程序員們經常跳過壹些指定的流程，很少人能全面遵循那些重量級開發方法。
失敗的原因很簡單，這個世界沒有萬能藥。因此，壹些人提出，將重量級開發方法中的規則和流程進行刪減、重整和優化，這樣就產生了很多適應不同需要的輕量級流程。在這些流程中，合乎實際需要的規則被保留下來，不必要的復雜化開發的規則被拋棄。而且，和傳統的開發方法相比，輕量級流程不再象流水生產線，而是更加靈活。
ExtremeProgramming（XP）就是這樣壹種靈巧的輕量級軟件開發方法。
為什麽稱為“Extreme”（極限）
“Extreme”（極限）是指，對比傳統的項目開發方式，XP強調把它列出的每個方法和思想做到極限、做到最好；其它XP所不提倡的，則壹概忽略（如開發前期的整體設計等）。壹個嚴格實施XP的項目，其開發過程應該是平穩的、高效的和快速的，能夠做到壹周40小時工作制而不拖延項目進度。