正如我們在eAD的若干期中探究的那樣，當今信息技術中最迫切的兩個問題是: How do we deliver functionality to business clients quickly?
如何能快速地向商業用戶交付功能？
How do we keep up with near-continuous change?
如何才能跟上近乎連續的變化?
Change is changing. Not only does the pace of change continue to accelerate, but, as the September issue of eAD pointed out, organizations are having to deal with different types of change -- disruptive change and punctuated equilibrium. Disruptive technologies, like personal computers in the early 1980s, impact an industry (in the case of PCs, several related industries), while a punctuated equilibrium - a massive intervention into an ecosystem or an economy -- impacts a very large number of species, or companies. The Inte.net, which has become the backbone for e-commerce and e-business, has disrupted a wide range of industries -- more a punctuated equilibrium than a disruption.
變化本身也在不斷地變化中。不僅僅是變化的速度在不斷地提高，而且，如eAD的10月中所指出的， 組織正在不得不應付各種類型的變化-- 劇變與不斷被打破的平衡。 產生劇變的技術，象在80年代早期的個人計算機，沖擊了一個工業(PC機以及若干相關的工業)而不時打斷的平衡--一個對生態系統或者對整個經濟產生巨大影響的介入--則 影響了無數的物種，或者說，公司。已經成為電子商務支柱的Internet, 就已使大范圍的行業產生劇變--更多的是打斷的平衡而不僅僅是一次劇變。
When whole business models are changing, when time-to-market becomes the mantra of companies, when flexibility and interconnectedness are demanded from even the most staid organization, it is then that we must examine every aspect of how business is managed, customers are delighted, and products are developed.
當整個商業模式正在發生變化，當"時間意味著市場"正成為公司的咒語，當適應性與互連性正在成為甚至是最呆板的組織的需要的時候，我們將有必要檢查以下的每一個方面:商業是如何管理的，客戶為什么而感到高興，以及產品是如何開發的。
The Extreme Programming movement has been a subset of the object-oriented (OO) programming community for several years, but has recently attracted more attention, especially with the recent release of Kent Beck's new book Extreme Programming Explained: Embrace Change. Don't be put off by the somewhat "in-your- face" moniker of Extreme Programming (XP to practitioners). Although Beck doesn't claim that practices such as pair programming and incremental planning originated with XP, there are some very interesting, and I think important, concepts articulated by XP. There's a lot of talk today about change, but XP has some pretty good ideas about how to actually do it. Hence the subtitle, Embrace Change.
終極編程(Extreme Programming )運動成為面向對象編程這個團體的一部分已經有數年了， 但是直到最近才引起了越來越多的注意，特別是最近Kent Beck的《終極編程 釋義:擁抱變化》(Extreme Programming Explained: Embrace Change)一書的出版。千萬不要因為終極編程(業內人簡稱為XP)這一稱呼而對它產生反感。 盡管Beck沒有說象配對編程(pair programming)，增量式計劃(incremental planning)之類的來源 于XP,但是仍然有一些非常有趣的，我認為也是很重要的概念可以借用XP來表達�，F有有許多關于變化的討論， 但是XP卻有許多如何實際去做的非常好的想法。也就是這個副標題:擁抱變化。
There is a tendency, particularly by rigorous methodologists, to dismiss anything less ponderous than the Capability Maturity Model (CMM) or maybe the International Organization for Standardization's standards, as hacking. The connotation: hacking promotes doing rather than thinking and therefore results in low quality. This is an easy way to dismiss practices that conflict with one's own assumptions about the world.
有一種趨勢，特別在那些嚴格的方法論者中，希望剔除那些與"能力 成熟度模型"(Capability Maturity Model CMM)或者是國際標準化組織的標準相比不那么笨重的方法，比如象hacking.注釋: hacking推崇行動而不是思考從而導致了較低的質量。 剔除與某人關于這個世界的假設相沖突的實踐，這倒不失為一種簡單的方法。
Looked at another way, XP may be a potential piece of a puzzle I've been writing about over the past 18 months. Turbulent times give rise to new problems that, in turn, give rise to new practices -- new practices that often fly in the face of conventional wisdom but survive because they are better adapted to the new reality. There are at least four practices I would assign to this category:
從另一個角度來看XP，它倒可能是一個難題的某個潛在的部分，這個一個我在過去18個月中一直都在寫的內容�；靵y 的時期產生新的問題，而后者又導致了新的實踐--新的實踐公然違抗 傳統的知識，但卻得以幸存下來是因為它們能更好地適應這個新的現實世界。至少有四種實踐方式我覺得是屬于這個范疇的:
XP -- the focus of this issue of eAD
XP -- eAD本期的焦點
Lean development -- discussed in the November 1998 issue of eAD
輕量級的開發(Lean development)--已經在eAD 1998 11月中討論
Crystal Light methods -- mentioned in the November 1999 issue of eAD and further discussed in this issue
輕量級的Crystal方法(Crystal Light methods)--曾在eAD 1999年11月提到，在本期中將做進一步的討論
Adaptive software development -- described in the August 1998 issue of eAD (then called Application Development Strategies -- ADS)
自適應軟件開發(Adaptive software development)--在eAD1998年8月中描述過(當時叫做應用開發策略Application Development Strategies -- ADS)
Although there are differences in each of these practices, there are also similarities: they each describe variations from the conventional wisdom about how to approach software development. Whereas lean and adaptive development practices target strategic and project management, XP brings its differing world view to the realm of the developer and tester.
盡管這些實踐中存在著差異，但是它們中也有相似的地方:它們都描述了與傳統軟件開發不同的方法。 雖然輕量級的開發與自適應開發針對的是戰略與項目管理的，但是XP卻用不同的視角將開發方法帶入了程序員與測試員的領域。
Much of XP is derived from good practices that have been around for a long time. "None of the ideas in XP are new. Most are as old as programming," Beck offers to readers in the preface to his book. I might differ with Beck in one respect: although the practices XP uses aren't new, the conceptual foundation and how they are melded together greatly enhance these "older" practices. I think there are four critical ideas to take away from XP (in addition to a number of other good ideas):
XP中許多部分其實都來自于業已存在的那些優秀的開發實踐。"XP中沒有一個想法是全新的。大多數想法產生的時間實際上和編程一樣古老"Beck在他書中的前言中這樣說道。但是我在某一個方面考慮的也許與Beck有所不同： 盡管XP所用的實踐方式不是全新的，但是概念的建立以及它們如何融合在一起極大地增強了 這些"老"的實踐。我想(除了許多其它的好思想外，還)可以從XP中提煉出四個關鍵的思想:
The cost of change
變化的成本
Refactoring
重構
Collaboration
協作
Simplicity
簡單化
But first, I discuss some XP basics: the dozen practices that define XP.
但是首先，我們來討論XP的基礎:那十二個用于XP的實踐方式。
XP - The Basics
XP－基礎
I must admit that one thing I like about XP's principal figures is their lack of pretension. XP proponents are careful to articulate where they think XP is appropriate and where it is not. While practitioners like Beck and Ron Jeffries may envision that XP has wider applicability, they are generally circumspect about their claims. For example, both are clear about XP's applicability to small (less than 10 people), co-located teams (with which they have direct experience); they don't try to convince people that the practices will work for teams of 200.
我必須承認一件事情，就是我喜歡XP的原因應該是它沒有其他的那些花哨的東西。支持XP的人們總是會向你指出XP適合的地方以及他的某些局限性。而XP的實踐者Beck以及Ron Jeffties卻相信XP會有更廣泛的應用前景。他們通常對于自己的要求都是很謹慎的。例如：小的（小于10人），公司局部（他們有直接的經驗）兩者對于XP的適應性都是很清楚的；他們并沒有試圖讓人們相信XP可以適用于一個200人的團隊。
The Project
工程
The most prominent XP project reported on to date is the Chrysler Comprehensive Compensation system (the C3 project) that was initiated in the mid-1990s and converted to an XP project in 1997. Jeffries, one of the "Three Extremoes" (with Beck and Ward Cunningham), and I spent several hours talking about the C3 project and other XP issues at the recent Miller Freeman Software Developer conference in Washington, DC, USA.
最為著名的XP項目是克萊斯勒綜合補償系統（稱為C3工程），它在上個世紀的90年代中期開始，到1997演變為XP。Jeffries,是"終極編程三人組"之一（另外兩個是Beck同Ward Cunningham） 。我在華盛頓特區同自由軟件人談論了有關C3的以及其他與XP項目有關的東西。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
注解： Chrysler Comprehensive Compensation system 克萊斯勒綜合補償系統
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
Originally, the C3 project was conceived as an OO programming project, specifically using Smalltalk. Beck, a well-known Smalltalk expert, was called in to consult on Smalltalk performance optimization, and the project was transformed into a pilot of OO (XP) practices after the original project was deemed unreclaimable. Beck brought in Jeffries to assist on a more full-time basis, and Jeffries worked with the C3 team until spring 1999. The initial requirements were to handle the monthly payroll of some 10,000 salaried employees. The system consists of approximately 2,000 classes and 30,000 methods and was ready within a reasonable tolerance period of the planned schedule.
最初，C3是一個基于OO（面向對象技術）的開發項目，尤其是它采用Smaltalk語言進行開發。（Smaltalk ：Xerox公司開發的一種高級程序設計語言,它支持和鼠標合用的選項屏驅動式應用程序,有助于建立便于使用的計算機程序。）作為著名的Smalltalk專家，Beck被邀請來討論有關SmalTalk性能優化的問題，并且在原項目被認為不可救要的時候將其變為一個采用面向對象OO（XP）方法的試驗性項目。Beck并且帶來了Jeffries用于幫助那些基本的東西，Jeffries在C3組一直干到1999年的春天。最開始的需求是要做一個對約10，000個雇員每月薪水發放進行管理的系統。這個系統由大約2，000個類以及30，000個方法構成，并且在計劃方面提供有合理的容忍度
As we talked, I asked Jeffries how success on the C3 project translated into XP use on other Chrysler IT projects. His grin told me all I needed to know. I've been involved in enough rapid application development (RAD) projects for large IT organizations over the years to understand why success does not consistently translate into acceptance. There are always at least a hundred very good reasons why success at RAD, or XP, or lean development, or other out-of-the-box approaches doesn't translate into wider use -- but more on this issue later.
正向我們所談到，我問Jeffries他怎樣成功的將C3變為XP并應用到其他的克萊斯勒IT項目。他笑著告訴了我。多年來我為許多大型IT組織開發了不少RAD系統（快速原型開發），因此我知道為什么我們無法將成功的經驗運用于其它項目中. 對于RAD, XP, 輕量級的開發以及其它一些未得到廣泛應用的方法, 它們成功的原因至少有一百條.
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
