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的关于极限编程的介绍。

它和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”用法。

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为轻量级的、不讲究繁文缛节的、高纪律性的方法学。

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比其他任何人都有更长的面向对象的编程经历。

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.
一次性发布产品几乎是不可能的。客户拿到经过一些迭代周期开发出的系统就发布给最终用户，这个系统通常几乎是没有缺陷的，因此唯一的问题是什么时候开发者才能增加足够的功能以值得最终用户去进行升级。

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团队中, 让其中一些团队当另外一些团队的客户。