極限編程包含的活動有哪些

1. Junit工具的作用和優勢有哪些

JUnit是一個Java語言的單元測試框架。它由Kent Beck和Erich Gamma建立，逐漸成為源於Kent Beck的sUnit的xUnit家族中最為成功的一個。 JUnit有它自己的JUnit擴展生態圈。多數Java的開發環境都已經集成了JUnit作為單元測試的工具
另外junit是在極限編程和重構（refactor）中被極力推薦使用的工具，因為在實現自動單元測試的情況下可以大大的提高開發的效率，但是實際上編寫測試代碼也是需要耗費很多的時間和精力的，那麼使用這個東東好處到底在哪裡呢？筆者認為是這樣的：
極限編程
要求在編寫代碼之前先寫測試，這樣可以強制你在寫代碼之前好好的思考代碼（方法）的功能和邏輯，否則編寫的代碼很不穩定，那麼你需要同時維護測試代碼和實際代碼，這個工作量就會大大增加。因此在極限編程中，基本過程是這樣的：構思－> 編寫測試代碼－> 編寫代碼－> 測試，而且編寫測試和編寫代碼都是增量式的，寫一點測一點，在編寫以後的代碼中如果發現問題可以較快的追蹤到問題的原因，減小回歸錯誤的糾錯難度。
重構
其好處和極限編程中是類似的，因為重構也是要求改一點測一點，減少回歸錯誤造成的時間消耗。
其他情況
我們在開發的時候使用junit寫一些適當的測試也是有必要的，因為一般我們也是需要編寫測試的代碼的，可能原來不是使用的junit，如果使用junit，而且針對介面（方法）編寫測試代碼會減少以後的維護工作，例如以後對方法內部的修改（這個就是相當於重構的工作了）。另外就是因為junit有斷言功能，如果測試結果不通過會告訴我們哪個測試不通過，為什麼，而如果是像以前的一般做法是寫一些測試代碼看其輸出結果，然後再由自己來判斷結果是否正確，使用junit的好處就是這個結果是否正確的判斷是它來完成的，我們只需要看看它告訴我們結果是否正確就可以了，在一般情況下會大大提高效率。

2. 什麼是極限編程

極限編程(Extreme Programming，XP)是一門針對業務和軟體開發的規則，它的作用在於將兩者的力量集中在共同的、可以達到的目標上。它是以符合客戶需要的軟體為目標而產生的一種方法論，XP使開發者能夠更有效的響應客戶的需求變化，哪怕是在軟體生命周期的後期。它強調，軟體開發是人與人合作進行的過程，因此成功的軟體開發過程應該充分利用人的優勢，而弱化人的缺點，突出了人在軟體開發過程中的作用。極端編程屬於輕量級的方法，認為文檔、架構不如直接編程來的直接。

3. 敏捷開發、極限編程和結對編程這三者什麼關系啊

敏捷開發是十幾種開發方法的統稱，極限編程就是這十幾種開發方法之一。
極限編程包括了十幾種實踐（就是一些具體做法），結對編程是極限編程的一種實踐。

4. 極限編程的核心價值

極限編程中有四個核心價值是我們在開發中必須注意的：溝通（Communication）、簡單（Simplicity）、反饋（Feedback）、勇氣（Courage）、此外還擴展了第五個價值觀：謙遜（Modesty）。 XP用「溝通、簡單、反饋、勇氣和謙遜」來減輕開發壓力和包袱；無論是術語命名、專著敘述內容和方式、過程要求，都可以從中感受到輕松愉快和主動奮發的態度和氣氛。這是一種幫助理解和更容易激發人的潛力的手段。XP用自己的實踐，在一定范圍內成功地打破了軟體工程「必須重量」才能成功的傳統觀念。
XP精神可以啟發我們如何學習和對待快速變化、多樣的開發技術。成功學習XP的關鍵，是用「溝通、簡單、反饋、勇氣和謙遜」的態度來對待XP；輕松愉快地來感受XP的實踐思想；自己認真實踐後，通過對真實反饋的分析，來決定XP對自己的價值；有勇氣接受它，或改進它。

5. 極限編程的相關概念

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