?

這個XP和windows xp沒有任何關(guān)系

XP開發(fā)模式也就是極限開發(fā)模式 采用極限編程展開

Extreme Programming FAQ

Introduction
簡介

What is Extreme Programming? Does it involve bungee cords?
什么是極限編程（Extreme Programming）？它需要蹦級保險繩么?:-)

　　Extreme Programming (or XP) is a set of values, principles and practices for rapidly developing high-quality software that provides the highest value for the customer in the fastest way possible. XP is extreme in the sense that it takes 12 well-known software development "best practices" to their logical extremes -- turning them all up to "10" (or "11" for Spinal Tap fans). See Kent Beck's introduction to Extreme Programming Explained for more details.
極限編程（Extreme Programming，或簡稱XP）是一套能快速開發(fā)高質(zhì)量軟件所需的價值觀、原則和活動的集合，使軟件能以盡可能快的速度開發(fā)出來并向客戶提供最高的效益。說XP是極限在于它將12個眾所周知的軟件開發(fā)的“最佳活動”都發(fā)揮到極限“10分”（或到“11分”對超級發(fā)燒友）。更詳細的細節(jié)可參看Kent Beck的關(guān)于極限編程的介紹。

What does this have to do with Windows XP?
它和Windows XP有什么關(guān)系？
Absolutely nothing. In February 2001, Microsoft announced that the next release of their consumer Windows operating system would be called "Windows XP". The use of "XP" as shorthand for Extreme Programming predates Microsoft's use of "XP" by 2-3 years.
絕對無關(guān)。在2001年2月，微軟宣布他們下一個要發(fā)布的Windows操作系統(tǒng)叫做“Windows XP”，用"XP"做為極限編程的縮寫在2～3年前就預測了微軟的"XP"用法。

Is XP a methodology?
XP是一種方法學么？
No and yes. No, it's not a methodology in the sense of a lot of paperwork and additional hoops for developers to jump through. But yes, in the sense that it is a repeatable process for developing software, it is in fact a methodology, although a lightweight one.
可以說不是，也可以說是。說它不是一種方法學是因為開發(fā)者可以跳過許多紙面上的東西和附加的條條框框；說它是，是因為它對于開發(fā)軟件來說是一種可重復的過程，它實際上也是一種方法學，但是屬于“輕量級”的。

Alistair Cockburn, who studies methodologies for a living, characterizes XP as a lightweight, low-ceremony, high-discipline methodology.
Alistair Cockburn,一個研究方法學的學者，描述XP為輕量級的、不講究繁文縟節(jié)的、高紀律性的方法學。

Where did XP come from?
XP起源于何處？
XP was originated by Kent Beck, based on his years of practice as an O-O software developer, and in particular, his work with Ward Cunningham using the Smalltalk programming language. Because Smalltalk was the first popular O-O language, Ward and Kent have been doing object-oriented programming longer than just about anyone else.
XP最早是由Kent Beck提出來的，源于他多年的O-O實踐，特別是他和Ward Cunningham一起使用Smalltalk語言進行開發(fā)的工作經(jīng)驗。因為Smalltalk是第一種流行的O-O語言，Ward和Kent比其他任何人都有更長的面向?qū)ο蟮木幊探?jīng)歷。

What are the basic practices of XP?
XP的基本實踐是什么？
The 12 core practices of XP are:
12個XP的核心實踐是：

The Planning Game: Business and development cooperate to produce the maximum business value as rapidly as possible. The planning game happens at various scales, but the basic rules are always the same:
游戲策劃：結(jié)合業(yè)務(wù)和開發(fā)以盡可能快地產(chǎn)生商業(yè)效益。游戲策劃的范圍各有不同，但基本原則都是一樣的：
Business comes up with a list of desired features for the system. Each feature is written out as a User Story, which gives the feature a name, and describes in broad strokes what is required. User stories are typically written on 4x6 cards.
業(yè)務(wù)提供了一張系統(tǒng)的期望特征表，把每個特征作為一個用戶需求（User Story）記錄下來,其中包括特征名和需求的各種提法。用戶需求典型地是寫在4x6的卡片上。
Development estimates how much effort each story will take, and how much effort the team can produce in a given time interval (the iteration).
開發(fā)工作要估計每條需求所需要的工作量，以及開發(fā)團隊在一個時間段（一次迭代）里能完成的工作量。
Business then decides which stories to implement in what order, as well as when and how often to produce a production releases of the system.
然后企業(yè)就確定用何種順序?qū)崿F(xiàn)哪些用戶需求，同時確定可發(fā)布的產(chǎn)品以的發(fā)布頻度。
Small Releases: Start with the smallest useful feature set. Release early and often, adding a few features each time.
短時發(fā)布：以實現(xiàn)最小的可用特征集開始。盡早發(fā)布和更新，每次只增加少數(shù)幾個新特征。
System Metaphor: Each project has an organizing metaphor, which provides an easy to remember naming convention.
系統(tǒng)綽號：每個項目有一個有規(guī)律的綽號，提供容易記住的命名規(guī)則。
Simple Design: Always use the simplest possible design that gets the job done. The requirements will change tomorrow, so only do what's needed to meet today's requirements.
簡要設(shè)計：使用盡可能最簡單的設(shè)計來完成工作。需求也許明天就會改變，因此我們所需的只是完成今天所遇到的需求。
Continuous Testing: Before programmers add a feature, they write a test for it. When the suite runs, the job is done. Tests in XP come in two basic flavors.
連續(xù)測試：在程序員增加一項特征前就完成測試程序。當整個系統(tǒng)能運行時，測試任務(wù)也就結(jié)束了。XP中的測試包括兩種類型：
Unit Tests are written by the developers to test functionality as they write it. Each unit test typically tests only a single class, or a small cluster of classes.
單元測試（Unit Tests）(代碼)是開發(fā)者編寫用來對他們所做的程序進行功能測試的。每個單元測試典型地只測試單個的類或很少幾個類的組合。
Acceptance Tests (also known as Functional Tests) are specified by the customer to test that the overall system is functioning as specified. Acceptance tests typically test the entire system, or some large chunk of it. When all the acceptance tests pass for a given user story, that story is considered complete.
驗收測試(也被稱為功能測試)是由客戶指定來測試整個系統(tǒng)是否完成既定功能。驗收測試通常測試整個系統(tǒng)，或系統(tǒng)中一些大的模塊。當驗收測試達到某條給定需求后，此需求就認為已經(jīng)完成了。
Refactoring: Refactor out any duplicate code generated in a coding session. You can do this with confidence that you didn't break anything because you have the tests.
求精（Refactoring）：去掉在編碼過程中產(chǎn)生的任何重復代碼，你可以自信地認為這么做不會破壞任何東西，因為你還有測試作為后盾。
Pair Programming: All production code is written by two programmers sitting at one machine. Essentially, all code is reviewed as it is written.
編程對子：所有代碼都是坐在同一臺機器前的兩個程序員共同編寫的，因此所有代碼在編寫的同時就完成了復查工作。
Collective Code Ownership: No single person "owns" a module. Any developer is expect to be able to work on any part of the codebase at any time.
集體代碼所有權(quán)：沒有單獨的一個人能“擁有”一個模塊，所有開發(fā)者都能在任何時候針對代碼庫的任何部分進行工作。
Continuous Integration: All changes are integrated into the codebase at least daily. The tests have to run 100% both before and after integration.
連續(xù)整合：至少每天都將所有的改變整合到代碼庫中，在整合前后都要進行100%的測試。
40-Hour Work Week: Programmers go home on time. In crunch mode, up to one week of overtime is allowed. But multiple consecutive weeks of overtime are treated as a sign that something is very wrong with the process.
每周4干40小時：讓開發(fā)人員按時回家。在特殊情況下，最多也只允許加班一周，但連續(xù)加班幾周就是工作過程出了問題的跡象。
On-site Customer: Development team has continuous access to a real live customer, that is, someone who will actually be using the system. For commercial software with lots of customers, a customer proxy (usually the product manager) is used instead.
在位(on-site)客戶：開發(fā)團隊要經(jīng)常和活生生的客戶接觸，即系統(tǒng)的實際用戶。對于有很多客戶的商業(yè)軟件，可以用客戶代理（經(jīng)常就是產(chǎn)品經(jīng)理）來代替。
Coding Standards: Everyone codes to the same standards. Ideally, you shouldn't be able to tell by looking at it who on the team has touched a specific piece of code.
編碼標準：每個人都按相同的標準編寫代碼。理想情況下，你無法通過看代碼的形式來說出是團隊中的誰編寫的。
What does a typical extreme programming project look like?
一個典型的極限開發(fā)項目是什么樣的？
The first thing you'd notice is that all the programmers are in a room together, usually sitting around a large table in the middle of the room. The programmers may have desks or offices nearby, but you can tell by the piles of books are piled that the big table is where the action is.
你注意到的第一件事是所有程序員都同在一間屋里，經(jīng)常是圍坐在房屋中間的一張大桌子邊。程序員們也許在旁邊也有桌子和辦公室，但你可通過所堆起來的成堆的書來確定大桌子才是真正的活動場所。

XP teams work in a series of fixed iteration cycles. Iterations typically last 1, 2 or 3 weeks each depending on the team. (A given team will almost always use same the iteration size for every iteration.)
XP團隊按一系列固定的迭代周期進行工作，根據(jù)團隊的不同一個迭代周期通常持續(xù)1～3星期。（給定團隊通常在每個開發(fā)周期都用相同的時間）

At the beginning of each iteration, the team gets together with the customer for a planning meeting. In that meeting, they go over the features the customer wants done in that iteration, breaking each feature down into individual engineering tasks. Individual developers then sign up for specific tasks, and estimate those tasks. No developer is allowed to sign up for more work in the coming iteration than he completed in the previous iteration.
在每個開發(fā)周期的開始，團隊和客戶一起開一個計劃會議。在會上他們要核實客戶希望在本周期內(nèi)要完成的特性，將每個特性分割為單獨的工程任務(wù)。然后每個開發(fā)人員登記承擔特定的任務(wù)并估計這些任務(wù)的工作量。不允許開發(fā)人員在下一個周期中承擔比他上一個周期中所能完成的更多的工作。

During the rest of the iteration, the team will implement the features they signed up for, pair programming on all production code. All code is written test-first -- that is, the developers don't write any code until they have a failing test case. The developers write unit tests to test individual classes and subsystems. The customer provides functional or acceptance tests to validate the features that the programmers are developing.
在迭代周期的其他時間內(nèi)，團隊要實現(xiàn)他們所登記承擔的任務(wù)，所有代碼由編程對子一起完成。所有代碼都是以測試第一（test-first）的原則來寫的，也就是說開發(fā)者在程序沒有出現(xiàn)測試失敗之前不必修改代碼。如果沒有完成測試程序，開發(fā)人員就不能寫功能代碼。客戶提供功能測試或驗收測試來核實開發(fā)者所開發(fā)出來的特性。

At the end of the iteration (usually on a Friday), the programmers deliver a working system to the customer. The system may not be complete, but all functionality that is implemented works completely, without bugs. The customer accepts delivery, and the team goes home early. The next Monday everyone meets again to plan the next iteration, and the cycle repeats itself.
在迭代周期結(jié)束時（通常是星期五），開發(fā)團隊為客戶提供一個可工作的系統(tǒng)。此系統(tǒng)可能不完整，但實現(xiàn)的所有功能都能完全無bug地工作，客戶接受此版本后開發(fā)團隊就可早回家休息。到了下星期一所有人重新聚集在一起策劃下一個迭代周期的工作，如此重復循環(huán)。

Actual product release is almost a non-event. The customer takes delivered system from some iteration, and distributes it to the end users. The system is always very nearly defect-free, so the only question is when the developers have added enough functionality to make it worthwhile for the end users to upgrade.
一次性發(fā)布產(chǎn)品幾乎是不可能的。客戶拿到經(jīng)過一些迭代周期開發(fā)出的系統(tǒng)就發(fā)布給最終用戶，這個系統(tǒng)通常幾乎是沒有缺陷的，因此唯一的問題是什么時候開發(fā)者才能增加足夠的功能以值得最終用戶去進行升級。

How big a project will XP work with?
XP可以完成多大的項目?
Easily up to a dozen programmers. Up to twice that with some difficulty. Beyond that, you'll need something else, either augmenting XP with more traditional heavyweight practices, or splitting the project among two or more regular XP teams, with some teams becoming customers for other teams.
很容易完成一個需要有12人的項目. 若要完成一個兩倍大的項目就比較困難了。超過這些, 你就會需要一些別的東西, 或添加一些傳統(tǒng)處理大任務(wù)型項目的實踐, 或把這個項目組分解到兩個或兩個以上XP 團隊中, 讓其中一些團隊當另外一些團隊的客戶。

How does XP compare to UML?
XP 與UML是什么關(guān)系?
XP is a development process; UML is a design notation. Most XPers are fluent in UML, and periodically draw UML diagrams on marker boards to work out design issues. Most XP projects don't have reams of printed UML diagrams, although there may be a brief design overview document that contains a few simple diagrams to show canonical class relationships in the system.
XP 是一個開發(fā)的過程; UML是一種設(shè)計符號。 大部分 XP 開發(fā)人員對 UML 很熟悉, 并且隨時地在記事板上畫一些UML 圖表以便能夠想出更好的設(shè)計方案。盡管會有一些包含系統(tǒng)中主要類關(guān)系的簡明概要設(shè)計文檔，大多數(shù) XP 項目并沒有大量打印出來的 UML 圖表。

How does XP compare to RUP?
XP 與RUP是什么關(guān)系?
The Rational Unified Process, or RUP, is a customizable "one size fits all process". It defines lots of roles, processes and documents, but essentially all of them are optional. Robert C. Martin has made a pretty good case that XP is in fact a minimal instance of RUP.
RUP （Rational Unified Process）,是一個可以定制的 "適合各種過程的統(tǒng)一尺度". 它定義了許多角色, 過程和文檔，但本質(zhì)上它們都是可選的。 Robert C. Martin 曾經(jīng)作一個很好的比喻：XP 實際上是RUP的一個最小實例。

How does XP compare to CMM?
XP 與CMM是什么關(guān)系?
General consensus on the XP mailing list is that XP is close to the spirit of CMM. However, real-world CMM practitioners tend to place a much higher emphasis on ceremonial meetings and paper documentation than XPers do, so it's unclear if an XP shop would receive a high CMM rating.
關(guān)于XP 郵件列表的共識是XP 接近CMM精神. 然而，相對于XP開發(fā)人員而言，現(xiàn)實世界中的CMM 實踐者更重視正式的會議和書面文檔，所以很難說是否一個XP團隊會得到一個高CMM級別。

What does YAGNI mean?
YAGNI 是什么意思?
"You aren't gonna need it," a general refrain when someone suggests building functionality for the system that isn't required by any current user story. For example:
"你不會需要它," 這是當某人建議為系統(tǒng)增加當前任何用戶都不想要的功能時得到的一個普遍答復。例如:

Programmer 1: "It says here we need to save the default number of widgets between sessions. I'd better write a generalized object persistence mechanism."
程序員 1: "我們需要保存會話間缺省的窗口部件數(shù)目。我最好寫一個通用的持久性對象機制。"

Programmer 2: "YAGNI. Just write out a one-line text file for now. If we need more later, we'll add it later."
程序員 2: "YAGNI.現(xiàn)在寫了一個單行的文本文件就行了。如果我們以后需要更多功能，那就以后再把它加上。"

What does ''Do the simplest thing that could possibly work.'' (DTSTTCPW) mean?
"完成夠用的、最簡單的東西" (DTSTTCPW)什么意思?
This is something an XP coach will say when he sees an XP developer doing something that is needlessly complicated. In general, XP says don't overdesign your system....
這是當一個XP教練看到一個XP 開發(fā)員在干一些沒有必要的復雜東西時。會說的話總而言之,一般來說， XP不會過分設(shè)計你的系統(tǒng)....

How can you know one approach is simpler than another?
你怎會知道一個方法比另一個方法簡單?

XP actually has a very specific definition of "simplest" (based on the list in Extreme Programming Explained, p.109):
其實XP 有一個很明確的“最簡單”的定義 (根據(jù)Extreme Programming p.109解釋的條目):

The system (code plus tests) clearly communicates everything that needs to be communicated at the current instant in its development. This means that it runs every existing test, and that the source code clearly reveals the
系統(tǒng) (代碼加測試) 明確地傳送任何在開發(fā)中當前時刻需要傳送的信息。這意味著它運行著每一個已存在的測試，并且源代碼對任何一個讀代碼的人清晰地顯示出它背后所隱含的意思。 intention behind it to anyone who reads it.

The system contains no duplicate code, unless that would violate (1).
這個系統(tǒng)不包含重復的代碼，否則就會違反 (1)。
The system contains the minimum number of classes possible without violating (1) or (2).
這個系統(tǒng)包含盡可能少的類，并且同時不違背 (1) 或(2)。
The system contains the minimum number of methods possible, consistent with (1) (2) and (3).
這個系統(tǒng)包含盡可能少的方法，并且同時不違背 (1) ，(2)和(3).
What does "Once and Only Once" (OAOO) mean?
“一次并且僅僅一次” (OAOO) 什么意思?
Once and only once is just shorthand for the first two items in the XP definition of "simplest". (1) says you need to say everything that needs to be said once. (2) says you need to say it only once, avoiding duplication.
一次并且僅僅一次是XP中"最簡單"定義中前兩項的速記法。 (1) 該說的每樣東西只說一遍。 (2) 該說的只說一遍，不要重復。

Where can I get a more complete glossary of XP terms?
在什么地方可以得到更為完整的XP術(shù)語集?
There's a fairly extensive XP glossary available at?http://c2.com/cgi/wiki?XpGlossary.?This is part of Ward Cunningham's amazing Wiki system.
http://c2.com/cgi/wiki?XpGlossary?有一個頗為廣泛的XP術(shù)語集。這是Ward Cunningham 的驚人 Wiki 系統(tǒng)的一部分。

Common Objections
反對意見
Isn't XP just undisciplined "hacking" or "cowboy coding"?
難道XP不就是沒有紀律的"黑客"或"牛仔編碼"?
Don't let the lack of paperwork and meetings fool you. Unless you're at least a CMM level 3 shop, XP is likely more disciplined than the way you produce software today. Some examples of that discipline:
不要讓缺乏文檔和會議來愚弄你。除非你已經(jīng)達到了CMM 3級或更高級別,否則 XP 比起你現(xiàn)在生產(chǎn)軟件的方法可能更講紀律。下面是此紀律的幾個例子:

XPers won't write any functionality that doesn't fulfill a specific, explicit customer need.
XP開發(fā)人員不會編程實現(xiàn)任何不滿足一個特定的，直接的客戶需求的功能。
XPers won't write any code without first writing a failing test
如果沒有完成測試程序，開發(fā)人員就不能寫功能代碼。
XPers write all production code in pairs.
XP開發(fā)人員兩兩組合來編寫所有的代碼。
XPers deliver a fully functional (albeit possibly feature limited) system at the end of each 1-3 week iteration.
XP開發(fā)人員在每一個1~3周的循環(huán)時段結(jié)束時遞交完全的功能（雖然特性有限）系統(tǒng)。
Won't pair programming cut productivity in half?
難道兩兩組合編程不會讓生產(chǎn)率減半嗎?
It turns out that two programmers working as a pair are more than twice as productive as a single programmer working alone, and also produce higher quality code. The big gain is not, as you might think, in avoiding little syntax errors, but rather in avoiding the big picture errors -- the ones where you blow an entire afternoon barking up the wrong tree.
事實證明兩個程序員一起工作比單獨工作的程序員生產(chǎn)力至少提高了一倍，并且產(chǎn)生了更高質(zhì)量的代碼。這個大的收獲并不象你想象的那樣在于避免句法錯誤，而是在于避免大錯誤-就像你苦干一下午，剝光了一棵樹的皮，到頭來卻發(fā)現(xiàn)弄錯了對象。

Laurie Williams has done empirical studies of pair programming. Her work is summarized in the paper The Costs and Benefits of Pair Programming, which she co-wrote with Alistair Cockburn. In this study, after only a few pairing sessions, pairs of programmers were roughly as twice as productive as solo programmers, yet produced substantially fewer defects.
Laurie Williams 曾經(jīng)做過關(guān)于編程對子的經(jīng)驗調(diào)研。她的工作在論文《編程對子的代價和收益》（The Costs and Benefits of Pair Programming）中得到總結(jié)，這篇論文是她與 Alistair Cockburn合寫的. 在這個研究中, 僅僅通過幾次對子會議，程序員對子的工作效率大約就是單個工作程序員的兩倍，盡管還會有幾個代碼錯誤。

With pair programming and collective code ownership, how are programmers supposed to be recognized and compensated?
在編程對子和代碼所有權(quán)歸于集體的情況下，程序員們的工作是如何被認定和給于報酬的呢？
XP has collective code ownership, but individual task ownership. Each developer signs up for tasks at the beginning of each iteration. He is then responsible for completing those tasks by pairing with another developer. At the end of each iteration, the customer decides if the task is complete or not. After a year, you'll have a long list of completed tasks to show your manager.
XP中代碼所有權(quán)權(quán)是集體的，但是任務(wù)是個人的。每個開發(fā)人員在每次迭代的開始是承擔某些任務(wù)。那么他就要與另一個開發(fā)人員搭檔負責完成那些任務(wù)。在每次迭代的終點，客戶來決定這項任務(wù)是否完成。一年后，你就可以把一個長長的完成的任務(wù)的清單給你的經(jīng)理看。

Isn't it annoying having someone looking over your shoulder while you program?
當你編程的時候，總有人在你肩膀后面注視你是不是讓人感到不自在？
Pair programming means two people working side-by-side on the same problem on the same computer; if someone is looking over your shoulder, you're doing it wrong. Typically, the person "driving" the keyboard and mouse will be focused primarily on tactical issues in coding the current method, while the non-driver will focus more on strategic issues, like how the method fits into the system, and is it needed at all in the first places. It's kind of like a road rally, where a driver and a navigator collaborate to get over a given course in the best time.
雙人編程意味著兩個人坐在一起在一個計算機上解決同一個的問題；如果有人在你肩膀后面注視你，就說明工作方式有誤。典型的情況是，通過鍵盤和鼠標直接進行編程的人首要考慮的是基于目前算法寫代碼的戰(zhàn)術(shù)問題，而另一個則更加關(guān)心戰(zhàn)略問題，即如何使算法適用于系統(tǒng)并在最初首先判定它的必要性。這很像公路汽車拉力賽，駕駛員和領(lǐng)航員在最短的時間內(nèi)合作克服遇到的問題。

Won't pair programming interfere with "flow", which requires solitude and silence?
編程對子會不會干擾到"順暢性"呢？它可是需要的孤獨和安靜的環(huán)境。
Pair programming appears to access another kind of flow, which is shared between the two people pairing. There's some talking, but not a lot of idle chitchat, and and it's easier to return to the state if someone interrupts you.
看起來編程對子可以達到另一種形式的"順暢性"。它由配對的兩人共享。他們之間會有一些有益的而不是喋喋不休的閑聊，而且如果有人打斷你們的話，應(yīng)該更容易回到狀態(tài)。

How can you possibly test everything? Don't you get a combinatoric explosion?
你如何能夠測試所有的問題？你沒有遇到組合爆炸嗎？
It's true that computation theory pretty much proves you can't validate every possible state of a non-trivial system. However, in practice, an experience programmer can produce a pretty good set of tests that will result in a high degree of confidence that the system is working correctly.
計算理論很好的證明了對一個非平凡系統(tǒng)你不可能核實它的所有的可能的狀態(tài)。當然在實際中，一個有經(jīng)驗的程序員能夠給出一個相當不錯的測試集，通過測試的系統(tǒng)能夠獲得更高的正確運行的信任程度。

It's sort of like those probabilistic tests used to produce large prime numbers for public-key cryptography. You can't tell for certain that a number is prime without trying to factor it, but you can apply a number of simpler tests that will verify its primeness to any degree of certainty that you want.
這類似于那些用來為公開密匙系統(tǒng)產(chǎn)生大質(zhì)數(shù)的概率測試。你不能沒有試著分解某個數(shù)就肯定地說這個數(shù)是質(zhì)數(shù)，但是你可以使用大量的簡單測試在某種你需要的程度上確認它是質(zhì)數(shù)。

Won't simple design leave you with a program that won't scale well?
難道簡單設(shè)計不會使你的程序不能很好地擴展嗎？
Simple design, practiced alone typically would have this result. But XP says that after you do the simplest thing that could possibly work, you go back and refactor your code until everything your code needs to express appears once and only once within the code base.
只使用簡單設(shè)計通常確實會產(chǎn)生這種結(jié)果。但是XP說的是，在你的作了最簡單的能夠工作的東西后，你回去求精你的代碼直到你的代碼所要表達的所有事情在你的代碼庫中出現(xiàn)且只出現(xiàn)一次。

Won't YAGNI lead you to design dead-ends down the road?
難道YAGNI不會引導你沿著沒有出路的設(shè)計道路走下去嗎？
General experience in the XP community is an unqualified "no". At the very worst, it may happen, but so rarely that your wins from all the other YAGNIs will more than pay for having to backtrack once in a while.
XP社會的普遍經(jīng)驗認為這絕對不可能。雖然在最壞情況下，這是可能的，但你從所有其它的YAGNI那里贏來的價值很少會超過你為偶爾的倒退所做的付出。

I don't think I [want to do/can sell my bosses on doing] all of the practices. Can I leave some out and still be doing XP?
我覺得我沒法[實施或者能讓我老板接受]做所有XP實踐。我能只做其中一些而仍被稱為是XP嗎？
Many of the practices work well in isolation, so it's quite possible you'd be better off using the ones you feel like than none at all. However there's a synergistic effect to using all of them together that you'll be missing out on. As a result, a lot of people in the XP community feel strongly that if you're not using all 12 practices, you're not doing XP.
大部分實踐都能夠獨自的很好的工作，所以你使用其中一些肯定會比什么都不用會使你有更好的境況。然而，將所有的實踐配合在一起使用會有更好的效果。XP社會的許多人強烈認為如果你沒有用到所有的12個實踐，你就不是在做XP。

As a practical matter, there's currently no XP certification authority. You can do whatever you want, and no XP Gestapo is going to kick in your door. But if you're not using all 12 practices, you probably could be going faster.
一個實際的情況是目前沒有一個XP的權(quán)威認證。你可以隨便做你想做的，沒有XP的蓋世太保來敲你的門。但是如果你沒有使用所有的12個實踐，你可能會走得更快。

Learning More
更多的資料
Where can I learn more about XP?
在哪兒我能學到更多的XP的知識？
The best place to start is currently Kent Beck's book "Extreme Programming Explained: Embracing Change", (available from Amazon.com among other places). This book is essentially the definitive guide to XP at the moment, and a fairly quick read.
目前最好的起點是Kent Beck的書：《Extreme Programming Explained: Embracing Change》（可以從Amazon.com或其他地方獲得。）這本書是現(xiàn)在權(quán)威的XP指南，也是一本很容易讀的書。

Once you have an overview of XP, visit Ward Cunningham's Wiki Wiki Web (or Wiki for short). Wiki is a simple, yet powerful hypertext system. Anyone can add or modify any page on Wiki, so the system collects the knowledge of thousands of people into a (semi) coherent whole. Started as a system for cataloging Design Patterns, Wiki has grown to include literally hundreds of pages related to XP. A good starting point is?http://c2.com/cgi/wiki?ExtremeProgrammingRoadmap.
一旦你有了一個XP的總體概念，請訪問Ward Cunningham的Wiki Wiki Web（簡稱 Wiki）。Wiki是一個簡單的但功能強大的超文本系統(tǒng)。任何人能增加或修改它上面的任何頁面。這樣，該系統(tǒng)集中了數(shù)千人的知識于一個（半）連貫的整體之中。從一個設(shè)計模式的目錄系統(tǒng)，Wiki已經(jīng)成長為包含了數(shù)百頁XP相關(guān)頁面的系統(tǒng)。可以從這里開始：?http://c2.com/cgi/wiki?ExtremeProgrammingRoadmap.

There's also a lively XP mailing list on Yahoo Groups (formerly eGroups). To subscribe, send a blank email to?extremeprogramming-subscribe@yahoogroups.com. Or see the archives on the web at?http://groups.yahoo.com/group/extremeprogramming.
在Yahoo討論組（正式的提法是eGroups）中也有一個活躍的XP郵件列表。向?extremeprogramming-subscribe@yahoogroups.com?發(fā)內(nèi)容為空的郵件就可以登記參加。或者訪問其文檔庫，鏈接是：http://groups.yahoo.com/group/extremeprogramming。