原文地址：http://zh.wikipedia.org/w/index.php?title=%E6%9E%81%E9%99%90%E7%BC%96%E7%A8%8B&variant=zh-cn
極限編程（XP，eXtreme Programming）是一種軟件工程方法學，是敏捷軟件開發中
最富有成效的幾種方法學之一。如同其他敏捷方法學，極限編程和傳統方法學的本質不同在于它更強調可適應性而不是可預測性。XP的支持者認為軟件需求的不斷
變化是很自然的現象，是軟件項目開發中不可避免的、也是應該欣然接受的現象；他們相信，和傳統的在項目起始階段定義好所有需求再費盡心思的控制變化的方法
相比，有能力在項目周期的任何階段去適應變化，將是更加現實更加有效的方法。
XP為管理人員和開發人員開出了一劑指導日常實踐的良方；這個實踐意味著接受并鼓勵某些特別的有價值的方法。支持者相信，這些在傳統的軟件工程中看來是“極端的”實踐，將會使開發過程比傳統方法更加好的響應用戶需求，因此更加敏捷，更好的構建出高質量軟件。
[編輯] 歷史
極限編程的創始者是肯特·貝克（Kent Beck）、沃德·坎寧安（ Ward Cunningham）和羅恩·杰弗里斯（Ron Jeffries），他們在為克萊斯勒綜合報酬系統（Chrysler Comprehensive Compensation System )(C3) 的薪水冊項目工作時提出了極限編程方法。Kent Beck在1996年3月成為C3的項目負責人，開始對項目的開發方法學進行改善。他寫了一本關于這個改善后的方法學的書，并且于1999年10月將之發行，這就是《極限編程解析》（2005第二版出版）?？巳R斯勒在2000年2月取消了實質上并未成功的C3項目，但是這個方法學卻一直流行在軟件工程領域中。至今2006年，很多軟件開發項目都一直以極限編程做為他們的指導方法學。
該書闡述了如下的極致編程的哲學思想 ：
- 一種社會性的變化機制
- 一種開發模式
- 一種改進的方法
- 一種協調生產率和人性的嘗試
- 一種軟件開發方法
把極致編程一般化并用于其它型別的專案稱為極致專案管理。
[編輯] 背景
The 90s had seen the great promise of object technologies
launch ambitious projects that in many cases ended in failure. Objects
themselves, while conferring numerous advantages of reuse, were not the
panacea
that many had hoped they would be. Fluid, rapidly-changing requirements
demanded shorter lifecycles, and did not go well with more traditional
methods of development, which usually required extensive design up
front and penalized later design changes with higher costs or missed
deadlines.
[編輯] 起源
The Chrysler Comprehensive Compensation project was started in order
to determine the best way to use object technologies, using the payroll
systems at Chrysler as the object of research, with Smalltalk as the language and GemStone as the persistence layer. They brought in Kent Beck, a prominent Smalltalk practitioner, to do performance tuning
on the system, but his role expanded as he noted several issues they
were having with their development process. He took this opportunity to
propose and implement some changes in their practices based on his work
with his frequent collaborator, Ward Cunningham.
- The first time I was asked to lead a team, I asked them to do a
little bit of the things I thought were sensible, like testing and
reviews. The second time there was a lot more on the line. I thought,
"Damn the torpedoes, at least this will make a good article," [and]
asked the team to crank up all the knobs to 10 on the things I thought
were essential and leave out everything else. —[Kent Beck]
Beck invited Ron Jeffries
to the project to help develop and refine these methods. Jeffries
thereafter acted as a kind of coach to instill the practices as habits
in the C3 team.
Information about the principles and practices behind XP was
disseminated to the wider world through discussions on the original WikiWiki, Cunningham's Portland Pattern Repository.
Various contributors dissected and expanded upon the ideas, some
becoming fervent advocates, others becoming critics, and yet others
picking out ideas (see agile software development).
[編輯] 現狀
Beck edited a series of books on XP, beginning with his own Extreme Programming Explained,
spreading his ideas to a much larger yet very receptive audience.
Authors in the series went through various aspects attending XP and its
practices, even a book critical of the practices.
XP created quite a buzz in the late nineties and early two
thousands, seeing adoption in a number of different milieus and
environments radically different from its origins.
[編輯] 未來的方向
The high discipline required by the original practices often went by
the wayside, causing certain practices to be deprecated or left undone
on individual sites. Agile development practices have not stood still,
and XP is still evolving, assimilating more lessons from experiences in
the field. In the second edition of Extreme Programming Explained, Beck added more values and practices, and differentiated between primary and corollary practices.
極限編成的推廣之一為把不同的敏捷軟件實踐和傳統實踐節奏地結合起來，彈性地合用于不同企業開發環境。這就是軟件開發節奏(Software Development Rhythms)的中心思想
[編輯] XP的目標
極限編程的主要目標在于降低因需求變更而帶來的成本。在傳統系統開發方法中（如SDM），系統需求是在專案開發的開始階段就確定下來，并在之后的開發過程中保持不變的。這意味著專案開發進入到之后的階段時出現的需求變更—而這樣的需求變更在一些發展極快的領域中是不可避免的—將導致開發成本急速增加。這一概念可以用下圖來表示：
極限編程透過引入基本價值、原則、方法等概念來達到降低變更成本的目的。一個應用了極限編程方法的系統開發專案在應對需求變更時將顯得更為靈活。下圖展示了這一降低變更成本的目的︰
[編輯] XP 核心的實踐
極致編程實踐作業的核心，正如 Extreme programming explained 所描述的，可以被區分為以下四個范圍（12個實踐作業）:
小規?；仞?/p>
- 測試驅動開發
- 策劃游戲
- 全隊（原名：在場客戶）
- 結對程序設計
反覆性程序而不是批量的
共同認識（共識）
- 簡單的設計
- 系統隱喻
- 集體程序碼所有
- 程序設計標準/程序設計規約
程序設計師的利益
在第二版的Extreme programming explained中，在主要實踐之外，還列出了一系列延伸的實踐。
核心實踐源自被廣泛接受的最佳實踐，并且被推向極至：
- 開發人員和客戶之間的交互是有益的. 因此,一個極致編程的小組從理論上要求需要一個軟件使用者在身邊,這個使用者制定軟件的工作需求和優先等級, 并且盡可能在各種問題出現的時候馬上就能回答(實際工作中，這個角色是由客戶代理商完成的).
- 如果學習是好的, 那么就把它做到底: 這樣減少了開發和回饋周期的長度,測試也能更早完成.
- 簡單的代碼更可能工作。所以極致編程的程序設計師在一個軟件專案中唯寫出能夠滿足目前實際需求的代碼,這樣或多或少降低了代碼的復雜性和重復性.
- 如果簡單的代碼是好的, 那么把變得復雜的代碼改寫成簡單的.
- 代碼評審是好的。因此,極致編程的程序設計師以兩人搭檔的方式工作. 他們共享一個屏幕和鍵盤,增加了隊員之間的交流,也讓代碼在一被寫出的時候就被人評審了.
- 測試代碼是好的。因此,在極致編程中,測試用例在實際代碼之前就被寫出來了. 代碼只有在通過測試的時候才被認為完成了.
(當然,需要進一步分解來降低復雜性). 整個軟件系統用一種周期化的,實時的,被預先變好的自動化測試方式來保證它的確有作用.參看 測試驅動的開發.
- 一般來說，極致編程被認為對于少于12人的小團隊很有用。一些人認為極致編程可以用于大的團隊，但是其它人認為統一軟件程序更適合大的團隊。然
而,極致編程在一些超過100人的開發小組中獲得成功. 并不是極致編程不能夠推廣到更大的團隊,而是很少有更大的團隊來試著用它.
極致編程的人員也拒絕去隨便推測這個問題.
[編輯] XP的價值
最初，極限編程技術只提出了四條價值標準，而在《極限編程解析》的第二版中又加入了第五條。以下就是這五條標準：
構建一個軟件系統的基本任務之一就是與系統的開發者交流以明確系統的具體需求。在一些正式的軟件開發方法中，這一任務是通過文檔來完成的。
極限編程技術可以被看成是在開發小組的成員之間迅速構建與傳播制度上的認識的一種方法（Extreme Programming
techniques can be viewed as methods for rapidly building and
disseminating institutional knowledge among members of a development
team）。它的目標是向所有開發人員提供一個對于系統的共享的視角，而這一視角又是與系統的最終用戶的視角相吻合的。為了達到這一目標，極限編程支持設
計、抽象、還有用戶-程序員間交流的簡單化，鼓勵經常性的口頭交流與反饋。
極限編程鼓勵從最簡單的解決方式入手再通過不斷重構達
到更好的結果。這種方法與傳統系統開發方式的不同之處在于，它只關注于對當前的需求來進行設計、編碼，而不去理會明天、下周或者下個月會出現的需求。極限
編程的擁護者承認這樣的考慮是有缺陷的，即有時候在修改現有的系統以滿足未來的需求時不得不付出更多的努力。然而他們主張“不對將來可能的需求上投入精
力”所得到的好處可以彌補這一點，因為將來的需求在他們還沒提出之前是很可能發生變化的。為了將來不確定的需求進行設計以及編碼意味著在一些可能并不需要
的方面浪費資源。而與之前提到的“交流”這一價值相關聯來看，設計與代碼上的簡化可以提高交流的質量。一個由簡單的編碼實現的簡單的設計可以更加容易得被
小組中的每個程序員所理解。
在極限編程中，“反饋”是和系統開發的很多不同方面相關聯的：
- 來自系統的反饋：通過編寫單元測試，程序員能夠很直觀的得到經過修改后系統的狀態。
- 來自客戶的反饋：功能性測試是由客戶還有測試人員來編寫的。他們能由此得知當前系統的狀態。這樣的評審一般計劃2、3個禮拜進行一次，這樣客戶可以非常容易的了解、掌控開發的進度。
- 來自小組的反饋：當客戶帶著新需求來參加項目計劃會議時，小組可以直接對于實現新需求所需要的時間進行評估然后反饋給客戶。
反饋是與“交流”、“簡單”這兩條價值緊密聯系的。為了溝通系統中的缺陷，可以通過編寫單元測試，簡單的證明某一段代碼存在問題。來自系統的直接反饋信息將提醒程序員注意這一部分。用戶可以以定義好的功能需求為依據，對系統進行周期性的測試。用Kent Beck的話來說：“編程中的樂觀主義是危險的，而及時反饋則是解決它的方法。”
[編輯] 勇氣
極限編程理論中的“系統開發中的勇氣”最好用一組實踐來詮釋。其中之一就是“只為今天的需求設計以及編碼，不要考慮明天”這條戒律。這是努力避免陷入設計的泥潭、而在其他問題上花費了太多不必要的精力。勇氣使得開發人員在需要重構他
們的代碼時能感到舒適。這意味著重新審查現有系統并完善它會使得以后出現的變化需求更容易被實現。另一個勇氣的例子是了解什么時候應該完全丟棄現有的代
碼。每個程序員都有這樣的經歷：他們花了一整天的時間糾纏于自己設計和代碼中的一個復雜的難題卻無所得，而第二天回來以一個全新而清醒的角度來考慮，在半
小時內就輕松解決了問題。
[編輯] 尊重
尊重的價值體現在很多方面。在極限編程中，團隊成員間的互相尊重體現在每個人保證提交的任何改變不會導致編譯無法通過、或者導致現有的測試case
失敗、或者以其他方式導致工作延期。團隊成員對于他們工作的尊重體現在他們總是堅持追求高質量，堅持通過重構的手段來為手頭的工作找到最好的解決設計方
案。
[編輯] 原則
組成極限編程基礎的原則，正是基于上面描述的那幾條價值。在系統開發項目中，這些原則被用來為決策做出指導。與價值相比，原則被描述的更加具體化，以便在實際應用中更為簡單的轉變為具體的指導意見。
[編輯] 快速反饋
當反饋能做到及時、迅速，將發揮極大的作用。一個事件和對這一事件做出反饋之間的時間，一般被用來掌握新情況以及做出修改。與傳統開發方法不同，與
客戶的發生接觸是不斷反復出現的?？蛻裟軌蚯宄囟床扉_發中系統的狀況。他/她能夠在整個開發過程中及時給出反饋意見，并且在需要的時候能夠掌控系統的開
發方向。
單元測試同樣對貫徹反饋原則起到作用。在編寫代碼的過程中，應需求變更而做出修改的系統將出現怎樣的反應，正是通過單元測試來給出直接反饋的。比
如，某個程序員對系統中的一部分代碼進行了修改，而假如這樣的修改影響到了系統中的另一部分（超出了這個程序員的可控范圍），則這個程序員不會去關注這個
缺陷。往往這樣的問題會在系統進入生產環節時暴露出來。
[編輯] 假設簡單
假設簡單認為任何問題都可以"極度簡單"的解決。傳統的系統開發方法要考慮未來的變化，要考慮程序碼的可重用性。極致編程拒絕這樣作。
[編輯] 增量變化
極限編程的提倡者總是說：羅馬不是一天建成的。一次就想進行一個大的改造是不可能的。極限編程采用增量變化的原則。比如說，可能每三個星期發布一個包含小變化的新版本。這樣一小步一小步前進的方式，使得整個開發進度以及正在開發的系統對于用戶來說變得更為可控。
[編輯] 包容變化
可以肯定地是，不確定因素總是存在的。“包容變化”這一原則就是強調不要對變化采取反抗的態度，而應該包容它們。比如，在一次階段性會議中客戶提出了一些看來戲劇性的需求變更。作為程序員，必須包容這些變化，并且擬定計劃使得下一個階段的產品能夠滿足新的需求。
[編輯] 活動
XP 描述了在軟件開發過程中四種基本的行為。 XP describes four basic activities that are performed within the software development process.
XP的提倡者爭辯說在系統開發過程的產物中真正重要的只有編碼（a concept to which they give a
somewhat broader definition than might be given by others）。沒有編碼你一無所有。
The advocates of XP argue that the only truly important product of the
system development process is code (a concept to which they give a
somewhat broader definition than might be given by others). Without
coding you have nothing.
Coding can be drawing diagrams that will generate code, scripting a
web-based system or programming an object-oriented C# program that
needs to be compiled.
Coding can also be used to figure out the most suitable solution.
For instance, XP would advocate that faced with several alternatives
for a programming problem, one should simply code all solutions and
determine with automated tests (discussed in the next section) what
solution is most suitable.
Coding can also help to communicate thoughts about programming
problems. A programmer dealing with a complex programming problem and
finding it hard to explain the solution to fellow programmers might
code it and use the code to demonstrate what he or she means. Code, say
the exponents of this position, is always clear and concise and cannot
be interpreted in more than one way. Other programmers can give
feedback on this code by also coding their thoughts.
沒有經過測試的程序碼什么都不是。如果你沒有測試，客戶可能感覺不到，很多軟件在發布的時候沒有經過完整的測試，它們還都在工作（或多或少的工
作）。 在軟件開發程序中，極致編程認為，如果一個函數沒有經過測試就不能認為它可以工作。 This raises the question of
defining what one can be uncertain about.
- You can be uncertain whether what you coded is what you meant. To
test this uncertainty, XP uses Unit Tests. These are automated tests
that test the code. The programmer will try to write as many tests he
or she can think of that might break the code he or she is writing; if
all tests run successfully then the coding is complete.
- You can be uncertain whether what you meant is what you should have
meant. To test this uncertainty, XP uses acceptance tests based on the
requirements given by the customer in the exploration phase of release
planning.
[編輯] 傾聽
Programmers don't necessarily know anything about the business side
of the system development. The function of the system is determined by
the business side. For the programmers to find what the functionality
of the system should be, they have to listen to business.
Programmers have to listen "in the large": they have to listen what
the customer needs. Also, they have to try to understand the business
problem, and to give the customer feedback about his or her problem, to
improve the customer's own understanding of his or her problem.
Communication between the customer and programmer is further addressed in The Planning Game (see below).
From the point of view of simplicity, one could say that system
development doesn't need more than coding, testing and listening. If
those activities are performed well, the result should always be a
system that works. In practice, that will not work. One can come a far
way without designing but at a given time one will get stuck. The
system becomes too complex and the dependencies within the system cease
to be clear.
One can avoid this by creating a design structure that organizes the
logic in the system. Good design will avoid lots of dependencies within
a system; this means that changing one part of the system will not
affect other parts of the system.
[編輯] 實踐
[編輯] 策劃游戲
在極致編程中主要的策劃程序稱為策劃游戲。 本節將通過程序模型介紹這個程序。
策劃程序分為兩部分：
- 發布策劃: This is focused on determining what requirements are included
in which release and when it’s going to be delivered. The customers and
developers are both part of this. Release Planning consists of three
phases:
- Exploration Phase: In this phase the customer will give all his
requirements for the system. These will be written down on user story
cards.
- Commitment Phase: Within the commitment phase business and
development will commit themselves to the functionality that will be
included and the date of the next release.
- Steering Phase: In the steering phase the plan can be adjusted, new
requirements can be added and or existing requirements can be changed
or removed.
- 反覆狀態: This plans the activities and tasks of the developers. In
this process the customer is not involved. Iteration Planning also
consists of three phases:
- Exploration Phase: Within this phase the requirement will be
translated to different tasks. The tasks are recorded on task cards.
- Commitment Phase: The tasks will be assigned to the programmers and the time it takes to complete will be estimated.
- Steering Phase: The tasks are performed and the end the result is matched with the original user story.
Image:Planninggame.gif
[編輯] Exploration phase – Release planning
This is an iterative process of gathering requirements and estimating the work impact of each of those requirements.
- Get Requirement from Customer: Business has come with a problem;
during a meeting, development will try to define this problem and get
requirements.
- Write a Story: Based on the business problem, a story has to be
written. This is done by business, where they point out what they want
a part of the system to do. It is important that development has no
influence on this story for so far the functionality. The story is
written on a so called user story card.
- Split a Story: If development isn't able to estimate the story
(next item), it needs to be split up and written again. Again, this may
not influence the business requirements.
- Estimate a Story: Development estimates how long it will take to implement the work implied by the story card.
When business cannot come up with any more requirements, one proceeds to the commitment phase.
Image:Expl rp.gif
[編輯] 送出狀態 – 發布計劃
這一階段涉及成本、利潤和計劃影響這三個因素，包含四個部分：
- 按照價值排序：業務方按照商業價值為使用者故事排序。
- 按風險排序：開發方按風險為使用者故事排序。
- 設定周轉率：開發方決定以怎樣的速度開展專案。
- 選擇范圍：挑選在下一個發布中需要被完成的使用者故事，基于使用者故事決定發布日期。
[編輯] 價值排序
業務方按照商業價值為使用者故事排序。它們會被分為三類：
- 關鍵：沒有這些故事系統無法運作或變得毫無意義。
- 重要的商業價值：有重要業務價值的非關鍵使用者故事。
- 最好能有：并沒有重要商業價值的使用者故事；例如在可用性或使用者界面上的改進。
[編輯] 風險排序
程序設計師按照風險對使用者故事進行排序。他/她們將使用者故事的風險劃分成三類：低、中、高。以下是這種方式的一個范例：
- 決定風險索引：依照以下因素給每個使用者故事一個0到2的索引：
- 完全度（我們是否已經了解所有的故事細節？）
- 發散性（可能會發生變化嗎？）
- 復雜度（是否難以建構？）
為每個使用者故事增加所有這些索引后，給這些使用者故事指定一個風險索引：低（0–1），中（2–4），高（5–6）。
[編輯] 激勵狀態 – 發布計劃
在作業階段開發人員和業務人員可以“操縱”整個程序。這意味著，他們可以做出改變。個體的使用者故事，或是不同使用者故事的相對優先等級，都有可能改變；預估時間也可能出現誤差。這是做出相應調整的機會。
[編輯] 探索階段- 反覆計劃
反覆計劃中的探索階段是關于建立任務和預估實施時間。
- 收集使用者故事：收集并編輯下一個發布的所有使用者故事。
- 組合/分割任務：如果程序設計師因為任務太大或太小而不能預估任務完成時間，則需要組合或分割此任務。
- 預估任務：預測需要實作此任務的時間。
[編輯] 約定階段 - 反覆計劃
在反覆計劃的約定階段以不同使用者故事作為參考的任務被指派到程序設計師。
- 程序設計師接受任務：每個程序設計師都挑選一個他/她負責的任務。
- 程序設計師預估任務：由于程序設計師對此任務負責，他/她必須給出一個完成任務的估計時間。
- 設定負載系數：負載系數表示每個程序設計師在一個反覆中理想的開發時間。比如：一周工作40小時，其中5小時用于開會，則負載系數不會超過35小時。
- 平衡：當團隊中所有程序設計師都已經被配置了任務，便會在預估時間和負載系數間做出比較。任務配置在程序設計師中達到平衡。如果有一個程序設計師的開發任務過重，其它程序設計師必須接手他/她的一部分任務，反之亦然。
[編輯] 作業階段 - 反覆計劃
各個任務是在反覆計劃的作業階段中一步步實作的。
- 取得一張任務卡片：程序設計師取得一張由他/她負責的任務的卡片。
- 找尋一名同伴：這個程序設計師將和另一位程序設計師一同完成開發工作。這在實施結隊程序設計中會做更深入的探討。
- 設計這個任務：如果需要，兩位程序設計師會設計這個任務所達成的功能。
- 編輯單元測試：在程序設計師開始編輯實作功能的程序碼之前，他/她們首先編輯自動測試。這在實施單元測試中會做更深入的探討。
- 編輯程序碼：兩位程序設計師開始編輯程序碼。
- 執行測試：執行單元測試來確定程序碼能正常工作。
- 執行功能測試：執行功能測試（基于相關使用者故事和任務卡片中的需求）。
結對程序設計的意思是所有的程序碼都是由兩個人坐在一臺電腦前一起完成的。一個程序設計師控制電腦并且主要考慮編碼細節。另外一個人主要關注整體結構，不斷的對第一個程序設計師寫的程序碼進行評審。
結對不是固定的: 我們甚至建議程序設計師盡量交叉結對。這樣，每個人都可以知道其它人的工作，每個人都對整個系統熟悉，結對程序設計加強了團隊內的溝通。 (這與程序碼集體所有制是息息相關的).
[編輯] 集體所有制
集體所有制意味著每個人都對所有的程序碼負責；這一點，反過來又意味著每個人都可以更改程序碼的任意部分。結隊程序設計對這一實踐貢獻良多：借由在
不同的結隊中工作，所有的程序設計師都能看到完全的程序碼。集體所有制的一個主要優勢是提升了開發程序的速度，因為一旦程序碼中出現錯誤，任何程序設計師
都能修正它。
在給予每個開發人員修改程序碼的權限的情況下，可能存在程序設計師引入錯誤的風險，他/她們知道自己在做什么，卻無法預見某些依賴關系。完善的單元測試可以解決這個問題：如果未被預見的依賴產生了錯誤，那么當單元測試執行時，它必定會失敗。
[編輯] 現場客戶
在極致編程中，“客戶”并不是為系統付帳的人，而是真正使用該系統的人。極致編程認為客戶應該時刻在現場解決問題。例如：在團隊開發一個財務管理系統時，開發小組內應包含一位財務管理人員。
單元測試是用以測試一小段程序碼的自動測試（例如：類，方法）。在極致編程中，在程序碼編輯前就編輯單元測試。這種方式的目的是激勵程序設計師設想
他/她的程序碼在何種條件下會出錯。極致編程認為當程序設計師無法再想出更多能使他/她的程序碼出錯的情況時，這些程序碼便算完成。
[編輯] 重構
由于XP教條提倡編輯程序時只滿足目前的需求，并且以盡可能簡單的方式實作。有時會碰上一套僵硬的系統，所謂僵硬的系統，表現之一是需要雙重（或多
重）維護：功能變化需要對多份同樣（或類似）的程序碼進行修改；另一種表現是對程序碼的一部分進行修改時會影響其它很多部分。XP教條認為當這種情況發生
時，意味著系統正告訴你通過改變系統架構以重構程序碼，使它更簡單、更泛用。參見重構。
[編輯] 具爭議性的問題
Extreme Programming also has its share of controversial aspects:
- Detailed specifications are not created or preserved.
- Programmers are required to work in pairs - not all software developers expect to be asked to work this way.
- There is no Big Design Up Front. Most of the design activity
takes place on the fly and incrementally, starting with "the simplest
thing that could possibly work" and adding complexity only when it's
required by failing tests. This could result in more re-design effort
than only re-designing when requirements change.
- A customer representative is attached to the project. This role can become a single-point-of-failure for the project and some people have found it to be a source of stress.
In 2003, Matt Stephens and Doug Rosenberg
published a book under Beck's XP series imprint called "Extreme
Programming Refactored: The Case Against XP" which questioned the value
of the XP process and suggested ways in which it could be improved
(i.e. refactored). This triggered a lengthly debate in articles,
internet newsgroups and web-site chat areas. The core argument of the
book is that XP's practices are interdependent but that few practical
organisations are willing/able to adopt all the practices; therefore
the entire process fails. The book also makes other criticisms and it
draws a likeness of XP's "collective ownership" model to socialism (the authors appear to regard this as undesirable).
Certain aspects of XP have changed since the book was published, in
particular XP now accomodates modifications to the practices as long as
the required objectives are still met. It also uses increasingly
generic terms for processes. Some argue that these changes invalidate
previous criticisms; others claim that this is simply watering the
process down.
Recently, authors have attempted to reconcile XP with the older methods that XP sought to replace (such as the waterfall method) in order to offer a unified method. See http://www.lux-seattle.com/resources/whitepapers/waterfall.htm for an example.
[編輯] 極致編程的特征
極致編程方法的基本特征是：
這些內容屬性來源于那些被認為是有效的原則，并把它們發揮到極致：
- 開發人員和客戶之間的交互是有益的. 因此,一個極致編程的小組從理論上要求需要一個軟件使用者在身邊,這個使用者制定軟件的工作需求和優先等級, 并且盡可能在各種問題出現的時候馬上就能回答.
- 如果學習是好的, 那么就把它做到底: 這樣減少了開發和回饋周期的長度,測試也能更早完成.
- 簡單的程序碼更可能工作。所以極致編程的程序設計師在一個軟件專案中唯寫出能夠滿足目前實際需求的程序碼,這樣或多或少降低了程序碼的復雜性和重復性.
- 如果簡單的程序碼是好的, 那么把變得復雜的程序碼改寫成簡單的.
- 程序碼評審是好的。因此,極致編程的程序設計師以兩人搭檔的方式工作. 他們共享一個螢幕和鍵盤,增加了隊員之間的交流,也讓程序碼在一被寫出的時候就被人評審了.
- 測試程序碼是好的。因此,在極致編程中,測試用例在實際程序碼之前就被寫出來了. 程序碼只有在通過測試的時候才被認為完成了. (當然,需要進一步分解來降低復雜性). 整個軟件系統用一種周期化的,實時的,被預先變好的自動化測試方式來保證它的確有作用.參看 測試驅動的開發.
一般來說，極致編程被認為對于少于12人的小團隊很有用。一些人認為極致編程可以用于大的團隊，但是其它人認為統一軟件程序更適合大的團隊。然而,極致編程在一些超過100人的開發小組中獲得成功. 并不是極致編程不能夠推廣到更大的團隊,而是很少有更大的團隊來試著用它. 極致編程的人員也拒絕去隨便推測這個問題.
[編輯] 爭論的觀點
極致編程也有其被爭論的一面：
絕大多數設計活動都匆匆而過，并漸進式的，開始一個“最簡單的可能工作的東西”并當其需要時（測試失?。┎旁黾訌碗s性。單元測試促成為了設計紀律。
[編輯] 極致編程中的溝通
建構軟件系統的一個基本任務是向系統的開發人員傳達系統的需求。在形式的軟件開發方法學中，溝通是通過文件完成的。
極致編程方法可以被看作為在開發團隊成員間快速建構和散布統一的知識的一種方法。目的在于給所有開發人員一個共享的關于系統的看法，這個看法與使用者持有的看法相一致。為了這個目的，極致編程熱衷于簡單的設計，隱喻，使用者與程序設計師之間的合作，頻繁的口頭溝通和回饋。
參見:
[編輯] 參考資料
[編輯] 外部連線