XP在很多方面都和我們傳統意義上得 軟件工程不同，同時，它也和傳統的管理和項目計劃的方法不同。這些方法在軟件工程和其他管理活動中都有借鑒意義。
特點如下：
不采用瀑布式得軟件工程方法，而采用原型法。將一個軟件開發項目分為多個迭代周期，每個周期實現部分軟件功能。在每個周期都進行提出需求、設計軟件架構、編碼、測試、發布得軟件開發的全過程。每個周期都進行充分的測試和集成。這樣的好處是可以不斷的從客戶方面得到反饋，更逼近實際的軟件需求。通過頻繁的重新編碼的過程，可以非常適應功能更改的需求，同時增加軟件的易維護性。在不斷的迭代中，避免架構設計的重大失誤造成的軟件不能如期交工，避免了軟件設計的 風險。
在軟件設計中，強調簡單性，就是堅決不作用不到的通用功能。同時，也不刻意避免重新編碼，只有不斷得重新編碼才能保證軟件得合理性。不害怕對整個軟件推倒重做。認為重新編碼是很正常得現象。每次得重新編碼都會大大減少軟件中得熵值。
在專業分工中，提出在開發 團隊中要有全職的客戶人員的參與，同時在軟件團隊中也要有自己的領域專家。這樣，可以和客戶充分交流，徹底了解應用需求。這種軟件需求的提出不是一次性的，而是不斷的交流。
也有專門的軟件架構的設計師，首先進行軟件整體架構的設計。這種設計一般使用UML語言。
在軟件開發的順序上，和傳統方法完全相反。傳統方法是按照整體設計、編寫代碼、進行測試、交付客戶的方法。而XP是按照交付客戶、測試、編碼、設計的順序來開發。首先將要交付客戶的軟件的界面作出來，先讓客戶對軟件有實際體驗，這樣，可以獲得客戶的更多的反饋，使需求可以在開發前確定。在編碼前就先把測試程序做好，這樣，編碼完成后就可以馬上進行測試。通過不斷的測試來保證軟件的質量。在進行軟件架構設計之前就進行編碼，可以使問題更早暴露，可以使最后的軟件設計更體現編碼的特點，更符合實際，更容易實現，也保證了設計的合理，保證了軟件設計的大量決定的正確性。
在項目計劃的實現上，每次的計劃都是技術人員對客戶提出時間表，由最后的開發人員對 項目經理提出編碼的時間表。這種計劃都是從下而上的，不是從上到下的，更容易保證計劃的按時完成。同時，多個迭代周期也使工期的估計越來越精確。
在分工上，強調角色輪換，項目的集體負責，分工的自愿性。分工的自愿性就是每個人的工作內容不是由項目經理分派，而是由每個人自愿領取，這樣保證了每個人可以發揮自己的特長，適應自己的情況。當然，在每個問題上都要有唯一的決策人，同時，也要經過充分的交流和 溝通。角色輪換就是在項目中，一個人在不同的周期中擔任不同的角色，可以保證每個人對項目的整體把握，方便項目中的溝通和理解。項目的集體負責，就是每個人不是完成自己的工作就可以了，要對整個項目的完成負責，任何人都可以對工作的任何部分提出自己的建議。任何人都可以從事任何工作。任何人都要對整個項目熟悉。這樣做的優點是可以充分的鍛煉人、可以發揮每個人的積極性、可以使項目不依賴于某個特定的人，方便今后的軟件的維護，通過工作內容的變換可以提高人工作的興趣。通過角色輪換還可以使每個人都勞逸結合，方便相互理解，避免由于不理解而造成的各種配合問題。
保證8小時工作制，避免加班。
�。ㄎ壹訋讞l：要有充分的 培訓、要有每個人的提升空間、制定報酬要根據對企業的貢獻大小，而不是職位的高低，允許下屬比上級薪酬更高，薪酬的高低取決于績效評定，同時績效評定要盡可能量化。并且推行淘汰制。同時有有效的招聘制度。有強有力的后勤保障制度和輕松的企業文化。）
提出了成對編程的思路，就是每個模塊的編碼都是兩個人一起干，共用一臺電腦。這樣，一個人編碼時，令一個人就可以檢查代碼，或對編碼的思路進行思考，寫文檔等。不再有另外的測試人員，兩個人同時完成代碼的測試，并且使先寫測試程序然后再編程。這樣避免了編程人員和測試人員的矛盾。也解決了一個人自己檢查的局限性。兩個人共同檢查可以避免大多數的錯誤。在共同編程中還可以進行經驗的交流和傳授。也避免了將一個工作一直干下去的無聊，交流增加了情趣。并且兩個人共同工作也增加了工作量的彈性，使項目計劃的瓶頸工作能盡快解決。根據成對編程的思路，開發小組也可以分為兩個小組，一個小組進行開發，另一個小組作改進和bug修正等工作。也有同樣的效果。
在人員的分工上要靈活，要保證軟件開發中的角色的齊全，但每個角色可以由幾個人共同擔任，也可以一個人擔任幾個角色，并且在項目的不同時期，不同角色的人員數量會不斷變化。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
