Can you summarize the following document?
        
  極限程式設計的創始者是肯特·貝克、沃德·坎寧安和羅恩·傑弗里斯,他們在為克萊斯勒綜合報酬系統的薪水冊專案工作時提出了極限程式設計方法。肯特·貝克在1996年3月成為克萊斯勒系統的專案負責人,開始對專案的開發方法學進行改善。他寫了一本關於這個改善後的方法學的書,並且於1999年10月將之發行,這就是《極限程式設計解析》(2005第二版出版)。克萊斯勒在2000年2月取消了實質上並未成功的克萊斯勒系統,但是這個方法學卻一直流行在軟體工程領域中。直到2006年,很多軟體開發專案都一直以極限程式設計做為他們的指導方法學。  該書闡述瞭如下的極限程式設計的哲學思想:  把極限程式設計一般化並用於其它型別的專案稱為極限專案管理。  極限程式設計的推廣之一為把不同的敏捷軟體實踐和傳統實踐節奏地結合起來,彈性地合用於不同企業開發環境。這就是軟體開發節奏(Software Development Rhythms)的中心思想

  極限程式設計的主要目標在於降低因需求變更而帶來的成本。在傳統系統開發方法中,系統需求是在專案開發的開始階段就確定下來,並在之後的開發過程中保持不變的。這意味著專案開發進入到之後的階段時出現的需求變更(而這樣的需求變更在一些發展極快的領域中是不可避免的)將導致開發成本急速增加。  極限程式設計透過引入基本價值、原則、方法等概念來達到降低變更成本的目的。一個應用了極限程式設計方法的系統開發專案在應對需求變更時將顯得更為靈活。

  極限程式設計實踐作業的核心可以被區分為以下四個範圍(12個實踐作業):

  在第二版的《極限程式設計解析》中,在主要實踐之外,還列出了一系列延伸的實踐。  核心實踐源自被廣泛接受的最佳實踐,並且被推向極致:

  

  極限程式設計描述了在軟體開發過程中四種基本的行為,包括 極限程式設計的提倡者爭辯說在系統開發過程的產物中真正重要的只有編碼,並認為沒有經過測試的程式碼什麼都不是。如果你沒有測試,客戶可能感覺不到,很多軟體在釋出的時候沒有經過完整的測試,它們還都在工作(或多或少的工作)。極限程式設計認為,在軟體開發程式中,如果一個函式沒有經過測試就不能認為它可以工作。

  極限程式設計技術以溝通、簡單、回饋、勇氣和尊重為價值標準。

  構建一個軟體系統的基本任務之一就是與系統的開發者交流以明確系統的具體需求。在一些正式的軟體開發方法中,這一任務是通過文件來完成的。  極限程式設計技術可以被看成是在開發小組的成員之間迅速構建與傳播制度上的認識的一種方法。它的目標是向所有開發人員提供一個對於系統的共享的視角,而這一視角又是與系統的終端使用者的視角相吻合的。為了達到這一目標,極限程式設計支援設計、抽象、還有使用者-程式設計師間交流的簡單化,鼓勵經常性的口頭交流與回饋。

  極限程式設計鼓勵從最簡單的解決方式入手再通過不斷重構達到更好的結果。這種方法與傳統系統開發方式的不同之處在於,它只關注於對當前的需求來進行設計、編碼,而不去理會明天、下週或者下個月會出現的需求。極限程式設計的擁護者承認這樣的考慮是有缺陷的,即有時候在修改現有的系統以滿足未來的需求時不得不付出更多的努力。然而他們主張“不對將來可能的需求上投入精力”所得到的好處可以彌補這一點,因為將來的需求在他們還沒提出之前是很可能發生變化的。為了將來不確定的需求進行設計以及編碼意味著在一些可能並不需要的方面浪費資源。而與之前提到的“交流”這一價值相關聯來看,設計與程式碼上的簡化可以提高交流的質量。一個由簡單的編碼實現的簡單的設計可以更加容易得被小組中的每個程式設計師所理解。

  在極限程式設計中,“回饋”是和系統開發的很多不同方面相關聯的:  回饋是與“交流”、“簡單”這兩條價值緊密聯絡的。為了溝通系統中的缺陷,可以通過編寫單元測試,簡單的證明某一段程式碼存在問題。來自系統的直接回饋資訊將提醒程式設計師注意這一部分。使用者可以以定義好的功能需求為依據,對系統進行週期性的測試。用Kent Beck的話來說:“程式設計中的樂觀主義是危險的,而及時回饋則是解決它的方法。”

  極限程式設計理論中的“系統開發中的勇氣”最好用一組實踐來詮釋。其中之一就是“只為目前的需求設計以及編碼,別為不可預期的未來做太多考慮”這條戒律。這是努力避免陷入設計的泥潭、而在其他問題上花費了太多不必要的精力。勇氣使得開發人員在需要重構他們的程式碼時能感到舒適。這意味著重新審查現有系統並完善它會使得以後出現的變化需求更容易被實現。另一個勇氣的例子是瞭解什麼時候應該完全丟棄現有的程式碼。每個程式設計師都有這樣的經歷:他們花了一整天的時間糾纏於自己設計和程式碼中的一個複雜的難題卻無所得,而第二天回來以一個全新而清醒的角度來考慮,在半小時內就輕鬆解決了問題。

  尊重的價值體現在很多方面。在極限程式設計中,團隊成員間的互相尊重體現在每個人保證提交的任何改變不會導致編譯無法通過、或者導致現有的測試案例失敗、或者以其他方式導致工作延期。團隊成員對於他們工作的尊重體現在他們總是堅持追求高質量,堅持通過重構的手段來為手頭的工作找到最好的解決設計方案。

  組成極限程式設計基礎的原則,正是基於上面描述的那幾條價值。在系統開發專案中,這些原則被用來為決策做出指導。與價值相比,原則被描述的更加具體化,以便在實際應用中更為簡單的轉變為具體的指導意見。

  當回饋能做到及時、迅速,將發揮極大的作用。一個事件和對這一事件做出回饋之間的時間,一般被用來掌握新情況以及做出修改。與傳統開發方法不同,與客戶的發生接觸是不斷反覆出現的。客戶能夠清楚地洞察開發中系統的狀況。他/她能夠在整個開發過程中及時給出回饋意見,並且在需要的時候能夠掌控系統的開發方向。  單元測試同樣對貫徹回饋原則起到作用。在編寫程式碼的過程中,應需求變更而做出修改的系統將出現怎樣的反應,正是通過單元測試來給出直接回饋的。比如,某個程式設計師對系統中的一部分程式碼進行了修改,而假如這樣的修改影響到了系統中的另一部分(超出了這個程式設計師的可控範圍),則這個程式設計師不會去關注這個缺陷。往往這樣的問題會在系統進入生產環節時暴露出來。

  假設簡單認為任何問題都可以"極度簡單"地解決。傳統的系統開發方法要考慮未來的變化,要考慮程式碼的可重用性。極限程式設計拒絕這樣做。

  可以肯定地是,不確定因素總是存在的。“包容變化”這一原則就是強調不要對變化採取反抗的態度,而應該包容它們。比如,在一次階段性會議中客戶提出了一些看來戲劇性的需求變更。作為程式設計師,必須包容這些變化,並且擬定計劃使得下一個階段的產品能夠滿足新的需求。

  

  在極限程式設計中主要的策劃程式稱為策劃遊戲,本節將通過程式模型介紹這個程式。  策劃程式分為兩部分:

  這一階段涉及成本、利潤和計劃影響這三個因素,包含四個部分:

  業務方按照商業價值為使用者故事排序。它們會被分為三類:

  程式設計師按照風險對使用者故事進行排序。他/她們將使用者故事的風險劃分成三類:低、中、高。以下是這種方式的一個範例:  為每個使用者故事增加所有這些索引後,給這些使用者故事指定一個風險索引:低(0–1),中(2–4),高(5–6)。

  在作業階段開發人員和業務人員可以「操縱」整個程式。這意味著,他們可以做出改變。個體的使用者故事,或是不同使用者故事的相對優先等級,都有可能改變;預估時間也可能出現誤差。這是做出相應調整的機會。

  反覆計劃中的探索階段是關於建立任務和預估實施時間。

  在反覆計劃的約定階段以不同使用者故事作為參考的任務被指派到程式設計師。

  各個任務是在反覆計劃的作業階段中一步步實作的。

  結對程式設計的意思是所有的程式碼都是由兩個人坐在一臺電腦前一起完成的。一個程式設計師控制電腦並且主要考慮編碼細節。另外一個人主要關注整體結構,不斷的對第一個程式設計師寫的程式碼進行評審。  結對不是固定的:我們甚至建議程式設計師儘量交叉結對。這樣,每個人都可以知道其它人的工作,每個人都對整個系統熟悉,結對程式設計加強了團隊內的溝通。(這與程式碼集體所有制是息息相關的).

  集體所有制意味著每個人都對所有的程式碼負責;這一點,反過來又意味著每個人都可以更改程式碼的任意部分。結隊程式設計對這一實踐貢獻良多:藉由在不同的結隊中工作,所有的程式設計師都能看到完全的程式碼。集體所有制的一個主要優勢是提升了開發程式的速度,因為一旦程式碼中出現錯誤,任何程式設計師都能修正它。  在給予每個開發人員修改程式碼的許可權的情況下,可能存在程式設計師引入錯誤的風險,他/她們知道自己在做什麼,卻無法預見某些依賴關係。完善的單元測試可以解決這個問題:如果未被預見的依賴產生了錯誤,那麼當單元測試執行時,它必定會失敗。

  在極限程式設計中,「客戶」並不是為系統付賬的人,而是真正使用該系統的人。極限程式設計認為客戶應該時刻在現場解決問題。例如:在團隊開發一個財務管理系統時,開發小組內應包含一位財務管理人員。

  單元測試是用以測試一小段程式碼的自動測試(例如:類,方法)。在極限程式設計中,在程式碼編輯前就編輯單元測試。這種方式的目的是激勵程式設計師設想他/她的程式碼在何種條件下會出錯。極限程式設計認為當程式設計師無法再想出更多能使他/她的程式碼出錯的情況時,這些程式碼便算完成。

  由於極限程式設計教條提倡編輯程式時只滿足目前的需求,並且以儘可能簡單的方式實作。有時會碰上一套僵硬的系統,所謂僵硬的系統,表現之一是需要雙重(或多重)維護:功能變化需要對多份同樣(或類似)的程式碼進行修改;另一種表現是對程式碼的一部分進行修改時會影響其它很多部分。XP教條認為當這種情況發生時,意味著系統正告訴你通過改變系統架構以重構程式碼,使它更簡單、更泛用。參見重構。

  極限程式設計方法的基本特徵是:

  極限程式設計也有其被爭論的一面:  絕大多數設計活動都匆匆而過,並漸進式的,開始一個「最簡單的可能工作的東西」並當其需要時(測試失敗)才增加複雜性。單元測試促成為了設計紀律。
極限程式設計(英語:Extreme programming,縮寫為英語:XP),是一種軟體工程方法學,是敏捷軟體開發的一種方式。如同其他敏捷方法學,極限程式設計和傳統方法學的本質不同在於它更強調可適應性而不是可預測性。極限程式設計的支持者認為軟體需求的不斷變化是很自然的現象,是軟體專案開發中不可避免的、也是應該欣然接受的現象;他們相信,和傳統的在專案起始階段定義好所有需求再費盡心思的控制變化的方法相比,有能力在專案週期的任何階段去適應變化,將是更加現實更加有效的方法。