手機版
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）是一套能快速開發高質量軟件所需的價值觀、原則和活動的集合，使軟件能以盡可能快的速度開發出來并向客戶提供最高的效益。說XP是極限在于它將12個眾所周知的軟件開發的“最佳活動”都發揮到極限“10分”（或到“11分”對超級發燒友）。更詳細的細節可參看Kent Beck的關于極限編程的介紹。
What does this have to do with Windows XP?
它和Windows XP有什么關系？
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.
絕對無關。在2001年2月，微軟宣布他們下一個要發布的Windows操作系統叫做“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.
可以說不是，也可以說是。說它不是一種方法學是因為開發者可以跳過許多紙面上的東西和附加的條條框框；說它是，是因為它對于開發軟件來說是一種可重復的過程，它實際上也是一種方法學，但是屬于“輕量級”的。
Alistair Cockburn, who studies methodologies for a living, characterizes XP as a lightweight, low-ceremony, high-discipline methodology.
Alistair Cockburn,一個研究方法學的學者，描述XP為輕量級的、不講究繁文縟節的、高紀律性的方法學。
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語言進行開發的工作經驗。因為Smalltalk是第一種流行的O-O語言，Ward和Kent比其他任何人都有更長的面向對象的編程經歷。
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:
游戲策劃：結合業務和開發以盡可能快地產生商業效益。游戲策劃的范圍各有不同，但基本原則都是一樣的：
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.
業務提供了一張系統的期望特征表，把每個特征作為一個用戶需求（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).
開發工作要估計每條需求所需要的工作量，以及開發團隊在一個時間段（一次迭代）里能完成的工作量。
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.
然后企業就確定用何種順序實現哪些用戶需求，同時確定可發布的產品以的發布頻度。
Small Releases: Start with the smallest useful feature set. Release early and often, adding a few features each time.
短時發布：以實現最小的可用特征集開始。盡早發布和更新，每次只增加少數幾個新特征。
System Metaphor: Each project has an organizing metaphor, which provides an easy to remember naming convention.
系統綽號：每個項目有一個有規律的綽號，提供容易記住的命名規則。
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.
簡要設計：使用盡可能最簡單的設計來完成工作。需求也許明天就會改變，因此我們所需的只是完成今天所遇到的需求。
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.
連續測試：在程序員增加一項特征前就完成測試程序。當整個系統能運行時，測試任務也就結束了。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）(代碼)是開發者編寫用來對他們所做的程序進行功能測試的。每個單元測試典型地只測試單個的類或很少幾個類的組合。
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.
驗收測試(也被稱為功能測試)是由客戶指定來測試整個系統是否完成既定功能。驗收測試通常測試整個系統，或系統中一些大的模塊。當驗收測試達到某條給定需求后，此需求就認為已經完成了。
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）：去掉在編碼過程中產生的任何重復代碼，你可以自信地認為這么做不會破壞任何東西，因為你還有測試作為后盾。
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.
集體代碼所有權：沒有單獨的一個人能“擁有”一個模塊，所有開發者都能在任何時候針對代碼庫的任何部分進行工作。
Continuous Integration: All changes are integrated into the codebase at least daily. The tests have to run 100% both before and after integration.
連續整合：至少每天都將所有的改變整合到代碼庫中，在整合前后都要進行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小時：讓開發人員按時回家。在特殊情況下，最多也只允許加班一周，但連續加班幾周就是工作過程出了問題的跡象。
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)客戶：開發團隊要經常和活生生的客戶接觸，即系統的實際用戶。對于有很多客戶的商業軟件，可以用客戶代理（經常就是產品經理）來代替。
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?
一個典型的極限開發項目是什么樣的？
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.
你注意到的第一件事是所有程序員都同在一間屋里，經常是圍坐在房屋中間的一張大桌子邊。程序員們也許在旁邊也有桌子和辦公室，但你可通過所堆起來的成堆的書來確定大桌子才是真正的活動場所。
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團隊按一系列固定的迭代周期進行工作，根據團隊的不同一個迭代周期通常持續1～3星期。（給定團隊通常在每個開發周期都用相同的時間）
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.
在每個開發周期的開始，團隊和客戶一起開一個計劃會議。在會上他們要核實客戶希望在本周期內要完成的特性，將每個特性分割為單獨的工程任務。然后每個開發人員登記承擔特定的任務并估計這些任務的工作量。不允許開發人員在下一個周期中承擔比他上一個周期中所能完成的更多的工作。
During the rest of the iteration, the team will implement the features they signed up for, pair prog- ramming 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.
在迭代周期的其他時間內，團隊要實現他們所登記承擔的任務，所有代碼由編程對子一起完成。所有代碼都是以測試第一（test-first）的原則來寫的，也就是說開發者在程序沒有出現測試失敗之前不必修改代碼。如果沒有完成測試程序，開發人員就不能寫功能代碼。客戶提供功能測試或驗收測試來核實開發者所開發出來的特性。
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 com- pletely, 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.
在迭代周期結束時（通常是星期五），開發團隊為客戶提供一個可工作的系統。此系統可能不完整，但實現的所有功能都能完全無bug地工作，客戶接受此版本后開發團隊就可早回家休息。到了下星期一所有人重新聚集在一起策劃下一個迭代周期的工作，如此重復循環。
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.
一次性發布產品幾乎是不可能的。客戶拿到經過一些迭代周期開發出的系統就發布給最終用戶，這個系統通常幾乎是沒有缺陷的，因此唯一的問題是什么時候開發者才能增加足夠的功能以值得最終用戶去進行升級。
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人的項目. 若要完成一個兩倍大的項目就比較困難了。超過這些, 你就會需要一些別的東西, 或添加一些傳統處理大任務型項目的實踐, 或把這個項目組分解到兩個或兩個以上XP團隊中, 讓其中一些團隊當另外一些團隊的客戶。
How does XP compare to UML?
XP與UML是什么關系?
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． nbspthat contains a few simple diagrams to show canonical class relationships in the system.
XP是一個開發的過程; UML是一種設計符號。 大部分XP開發人員對UML很熟悉, 并且隨時地在記事板上畫一些UML圖表以便能夠想出更好的設計方案。盡管會有一些包含系統中主要類關系的簡明概要設計文檔，大多數XP項目并沒有大量打印出來的UML圖表。
How does XP compare to RUP?
XP與RUP是什么關系?
The Rational Unified Process, or RUP, is&n
