正如我們在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 Internet, 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 -- 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中提煉出四個關鍵的思想:
變化的成本
Refactoring
重構
Collaboration
協作
Simplicity
簡單化
But first, I discuss some XP basics: the dozen practices that define XP.
但是首先，我們來討論XP的基礎:那十二個用于XP的實踐方式。
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 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, 輕量級的開發以及其它一些未得到廣泛應用的方法, 它們成功的原因至少有一百條.
實踐
One thing to keep in mind is that XP practices are intended for use with small, co-located teams. They therefore tend toward minimalism, at least as far as artifacts other than code and test cases are concerned. The presentation of XP's practices have both positive and negative aspects. At one level, they sound like rules -- do this, don't do that. Beck explains that the practices are more like guidelines than rules, guidelines that are pliable depending on the situation. However, some, like the "40-hour week," can come off as a little preachy. Jeffries makes the point that the practices also interact, counterbalance, and reinforce each other, such that picking and choosing which to use and which to discard can be tricky.
應記住的一件事情就是我們應傾向于在小型的, 局部的團隊中運用XP。除了代碼與測試用例外, 盡量減少有些的影響。XP的實踐既有正面的表現,也有負面的。在某些方面看來，他們聽起來就像一堆規則，要做這個，不要做那個。對此Beck解釋道, 與規則相比, XP更像是指導方針，一個靈活的依賴于具體環境的開發方針。但是諸如"每周工作40小時"等看起來可能會感覺續續道道。Jeffries使得實踐也會互相作用的，平衡，互相加強。以至于挑選使用的同丟棄的都是棘手的事情。
The planning game. XP's planning approach mirrors that of most iterative RAD approaches to projects. Short, three-week cycles, frequent updates, splitting business and technical priorities, and assigning "stories" (a story defines a particular feature requirement and is displayed in a simple card format) all define XP's approach to planning.
計劃的制定： XP中關于制定計劃的實現方法中可以反映出大多數迭代式RAD項目的特點。短期的，每三周為一個循環，頻繁地更新，按優先級劃分任務與技術， 分配stories（一個story定義了一個特殊的功能需求并以一種簡單的方式記錄在卡片上），所有的這些就是構成了XP中的計劃。
Small releases. "Every release should be as small as possible, containing the most valuable business requirements," states Beck. This mirrors two of Tom Gilb's principles of evolutionary delivery from his book Principles of Software Engineering Management : "All large projects are capable of being divided into many useful partial result steps," and "Evolutionary steps should be delivered on the principle of the juiciest one next."
小版本： "每個版本應該盡可能的小，而且包含最有商業價值的需求"，Beck如是說。這也反映了Tom Gilb在他的<軟件工程管理原則>書中提到的關于漸進式發布的兩點："所有的大的項目都可以被分為局部的, 有用的小的步驟"以及"進化的步驟會傳遞到下一級。"
Small releases provide the sense of accomplishment that is often missing in long projects as well as more frequent (and more relevant) feedback. However, a development team needs to also consider the difference between "release" and "releasable." The cost of each release -- installation, training, conversions -- needs to be factored into whether or not the product produced at the end of a cycle is actually released to the end user or is simply declared to be in a releasable state.
小型版本的發布意味著具有在大型項目中經常缺少的頻繁的反饋的實現.。 然而，一個開發小組當然需要考慮到"發布"同"可發布"的不同。無論是否是最終的版本發布還是一個簡單的可發行版本的發布, 都需要付出安裝，培訓，轉化等代價。
Metaphor. XP's use of the terms "metaphor" and "story" take a little wearing in to become comfortable. However, both terms help make the technology more understandable in human terms, especially to clients. At one level, metaphor and architecture are synonyms -- they are both intended to provide a broad view of the project's goal. But architectures often get bogged down in symbols and connections. XP uses "metaphor" in an attempt to define an overall coherent theme to which both developers and business clients can relate. The metaphor describes the broad sweep of the project, while stories are used to describe individual features.
隱喻： 在XP中"隱喻"以及"story"的使用可能會讓人有一點不舒服。但是，這些術語的使用可以幫助我們以一種更人性化的方式加以理解，尤其是對客戶而言。從某種程度上來說，隱喻同體系結構是同意語――他們都著重于從全局描述一個項目。但是體系結構經常會陷于符號與連接的泥潭。而XP使用"隱喻"定義一個從開發者到商業客戶都可聯系的全面一致的主題。隱喻用于描述項目全面的面貌，而Story用于描述個別具體的特征。
Simple design. Simple design has two parts. One, design for the functionality that has been defined, not for potential future functionality. Two, create the best design that can deliver that functionality. In other words, don't guess about the future: create the best (simple) design you can today. "If you believe that the future is uncertain, and you believe that you can cheaply change your mind, then putting in functionality on speculation is crazy," writes Beck. "Put in what you need when you need it."
簡單的設計： 簡單的設計包含兩個部分。一，為已定義的功能進行設計，而不是為潛在地未來可能的功能進行設計。二，創建最佳的可以實現功能的設計。換句話說，不用管未來會是怎樣，只創建一個目前為止可以實現的最好的設計。"如果你相信未來是不確定的，并且你相信你可以很方便的改變你的主意的話，那么對未來功能的考慮是危險的。"Beck寫到。"只有在你真正需要的時候才去做"
In the early 1980s, I published an article in Datamation magazine titled "Synchronizing Data with Reality." The gist of the article was that data quality is a function of use, not capture and storage. Furthermore, I said that data that was not systematically used would rapidly go bad. Data quality is a function of systematic usage, not anticipatory design. Trying to anticipate what data we will need in the future only leads us to design for data that we will probably never use; even the data we did guess correctly on won't be correct anyway. XP's simple design approach mirrors the same concepts. As described later in this article, this doesn't mean that no anticipatory design ever happens; it does mean that the economics of anticipatory design changes dramatically.
在二十世紀八十年代，我發表了一篇有關自動化資料管理的文章"實際的同步數據"文章的意思是說數據的質量是使用功能，不是捕捉與存儲。此外，我說數據如果不是很系統的使用便會變壞。數據質量是系統使用的功能，不是可預料的設計。無論預期的對還是錯，試著設計一個我們從來都不會用到的數據，最終結果很可能我們一次也不會用到它們。XP的簡單設計方法反映了相同的觀點。如在本文后來所描述的那樣，這并不意味著不需要預測，而是說為預測的內容所做的設計一旦發生變化，其導致的代價是十分巨大的。
Refactoring. If I had to pick one thing that sets XP apart from other approaches, it would be refactoring -- the ongoing redesign of software to improve its responsiveness to change. RAD approaches have often been associated with little or no design; XP should be thought of as continuous design. In times of rapid, constant change, much more attention needs to be focused on refactoring. See the sections "Refactoring" and "Data Refactoring," below.
重構： 如果我不得不找出一個能夠將XP和其他方法區別開來的東西那就是重構――不斷的軟件再設計以改進它對于變化的反應。RAD方法常常很少甚至根本不與設計相關；XP應當被看作持續設計。當變化既快而且頻繁的時候，應投入更多的精力于重構之上。參見下面的"重構"和"數據重構"部分。
Testing. XP is full of interesting twists that encourage one to think -- for example, how about "Test and then code"? I've worked with software companies and a few IT organizations in which programmer performance was measured on lines of code delivered and testing was measured on defects found -- neither side was motivated to reduce the number of defects prior to testing. XP uses two types of testing: unit and functional. However, the practice for unit testing involves developing the test for the feature prior to writing the code and further states that the tests should be automated. Once the code is written, it is immediately subjected to the test suite instant feedback.
測試： XP充滿發人深思的有趣的難題。例如：什么是"先測試后編碼"？我曾經同軟件公司和一些IT機構一起工作，在那兒是通過代碼的行數來對程序員的績效加以考核，而測試的績效則是通過發現的缺陷的數量來考核的。這兩種方法都不能鼓勵減少測試前產生的缺陷的數量。XP使用兩種測試：單元測試和功能測試。單元測試要求在寫代碼之前就開發出相應功能的測試方法，并并測試應當是自動化的。代碼一完成，它就被立即用有關測試集加以測試，從而能立即得到反饋。
The most active discussion group on XP remains the Wiki exchange (XP is a piece of the overall discussion about patterns). One of the discussions centers around a lifecycle of Listen (requirements) Test Code Design. Listen closely to customers while gathering their requirements. Develop test cases. Code the objects (using pair programming). Design (or refactor) as more objects are added to the system. This seemingly convoluted lifecycle begins to make sense only in an environment in which change dominates.
最活躍的XP討論組仍然是Wiki exchange（XP是關于pattern總體討論的一部分），其中的一個討論圍繞聽�。ㄐ枨螅�-> 測試 -> 代碼 -> 設計的生命周期。貼近客戶聆聽并收集他們的需求。開發測試用例（test cases）。完成對象編碼（使用配對編程）。當更多對象被加入系統時進行設計（或重構）。這個看起來混亂不堪的生命周期僅僅在經常變化的環境下才有意義。
Pair programming. One of the few software engineering practices that enjoys near-universal acceptance (at least in theory) and has been well measured is software inspections (also referred to as reviews or walkthroughs). At their best, inspections are collaborative interactions that speed learning as much as they uncover defects. One of the lesser-known statistics about inspections is that although they are very cost effective in uncovering defects, they are even more effective at preventing defects in the first place through the team's ongoing learning and incorporation of better programming practices.
配對編程： 軟件（還是直接用Inspection為好？）（也稱審查或走查）也是被廣為接受（至少在理論上）和有效度量的少數軟件工程實踐之一。在最好情況下，Inspection這種協同交互的檢查能夠加速學習，同時發現缺陷。一個較少被知道的關于Inspection的統計數據是盡管它在發現缺陷方面非常有效，但通過團隊對于好的開發實踐持續的學習和協作，可以更好的在第一時間預防缺陷。
One software company client I worked with cited an internal study that showed that the amount of time to isolate defects was 15 hours per defect with testing, 2-3 hours per defect using inspections, and 15 minutes per defect by finding the defect before it got to the inspection. The latter figure arises from the ongoing team learning engendered by regular inspections. Pair programming takes this to the next step -- rather than the incremental learning using inspections, why not continuous learning using pair programming?
一家我工作過的軟件公司客戶引用一個內部研究結果，表明在測試階段發現一個缺陷需15小時，在Inspection階段發現一個缺陷則需2－3小時，而在Inspection之前發現缺陷只需15分鐘。后面的數據來自于產生于常規審查的持續的團隊學習。配對編程將這個帶入下一步――與其用Inspection來遞增式學習，為什么不用配對編程來學習呢？
"Pair programming is a dialog between two people trying to simultaneously program and understand how to program better," writes Beck. Having two people sitting in front of the same terminal (one entering code or test cases, one reviewing and thinking) creates a continuous, dynamic interchange. Research conducted by Laurie Williams for her doctoral dissertation at the University of Utah confirm that pair programming's benefits aren't just wishful thinking (see Resources and References ).
"配對編程是兩個人試圖同時編程和理解如何更好編程的一種對話"，Beck寫道。讓兩個人同時坐在一臺終端前面（一個人敲代碼或測試用例，一個人審查和思考）產生一種持續的、動態的交流。Williams在猶他大學進行的博士論文研究證明了配對編程不僅僅是一種美好的想法而且確有實效。（參見資源和參考）
Collective ownership. XP defines collective ownership as the practice that anyone on the project team can change any of the code at any time. For many programmers, and certainly for many managers, the prospect of communal code raises concerns, ranging from "I don't want those bozos changing my code" to "Who do I blame when problems arise?" Collective ownership provides another level to the collaboration begun by pair programming.
代碼共享： 項目組中的每個人都可以在任何時候修改其他項目成員的代碼，這就是XP中所定義的代碼共享。。對許多程序員以及經理而言，，共有代碼的想法會引起一些疑慮，諸如"我不想讓那些笨蛋改我的代碼"，"出現問題我應該怪誰？"等等。共享代碼從另一個層面提供了對配對編程中協作的支持。
Pair programming encourages two people to work closely together: each drives the other a little harder to excel. Collective ownership encourages the entire team to work more closely together: each individual and each pair strives a little harder to produce high-quality designs, code, and test cases. Granted, all this forced "togetherness" may not work for every project team.
配對編程鼓勵兩個人緊密協作：每個人促使另一個更加努力以圖超越。共同所有鼓勵整個團隊更加緊密協作：每個個人和每個雙人更努力生產高質量設計、代碼和測試集。當然，所有這些強迫的"共同"不一定對所有的項目組適用。
Continuous integration. Daily builds have become the norm in many software companies -- mimicking the published material on the "Microsoft" process (see, for example, Michael A. Cusumano and Richard Selby's Microsoft Secrets ). Whereas many companies set daily builds as a minimum, XP practitioners set the daily integration as the maximum - opting for frequent builds every couple of hours. XP's feedback cycles are quick: develop the test case, code, integrate (build), and test.
經常集成： 每日構造（build）在許多公司已經成為規范，模仿有關"微軟"流程的出版物上的東西。（參見，例如，Michael A. Cusumano和Richard Selby的Microsoft Secrets）許多公司將每日編鏈作為最小要求，XP實踐者將每日集成作為最大要求，選擇每兩個小時一次的頻繁編鏈。XP的反饋周期迅速：開發測試集、編碼、集成（編鏈）和測試。
The perils of integration defects have been understood for many years, but we haven't always had the tools and practices to put that knowledge to good use. XP not only reminds us of the potential for serious integration errors, but provides a revised perspective on practices and tools.
對于集成缺陷危險的認識已有多年了，但我們并不是總能擁有相應工具和時間將這些知識好好用起來。XP不僅提醒我們有可能有嚴重的集成錯誤，而且從實踐與工具的角度提供了一種新的認識。
40-hour week. Some of XP's 12 practices are principles, while others, such as the 40-hour practice, sound more like rules. I agree with XP's sentiments here; I just don't think work hours define the issue. I would prefer a statement like, "Don't burn out the troops," rather than a 40-hour rule. There are situations in which working 40 hours is pure drudgery and others in which the team has to be pried away from a 60-hour work week.
每周只干40小時： XP有12條實踐的基本原則，但是有時候，比如象每周只干40小時的原則，聽起來更象規則。我同意XP中的觀點。只是不認為有必要硬性規定工作小時數。相比起來，我更喜歡一句類似于"不要把部隊燒光"的話。在一些情況下，工作40小時太勞累，而在另外一些組里，甚至需要一周60個工作時。
Jeffries provided additional thoughts on overtime. "What we say is that overtime is defined as time in the office when you don't want to be there. And that you should work no more than one week of overtime. If you go beyond that, there's something wrong -- and you're tiring out and probably doing worse than if you were on a normal schedule. I agree with you on the sentiment about the 60- hour work week. When we were young and eager, they were probably okay. It's the dragging weeks to watch for."
Jeffries提供了關于加班的更多思索："我們說的是加班被定義為我們不想在辦公室的時候呆在辦公室。而且你不應當加班超過一周。如果你超過了，就有什么東西出了問題――你過于勞累，有可能比你按時下班干的還差。我同意你關于60工作時一周的感受。在我們年輕和滿身干勁的時候，這也許沒問題。值得注意的是拖沓的一周又一周。"
I don't think the number of hours makes much difference. What defines the difference is volunteered commitment. Do people want to come to work? Do they anticipate each day with great relish? People have to come to work, but they perform great feats by being committed to the project, and commitment only arises from a sense of purpose.
我不認為一周的工作時間會造成大的差別。決定區別的是自愿的貢獻。人們愿意來工作嗎？他們對每一天都充滿干勁嗎？人們必須來工作，但是他們通過投入項目來創造巨大成就，而投入僅僅產生于目標感。
On-site customer. This practice corresponds to one of the oldest cries in software development -- user involvement. XP, as with every other rapid development approach, calls for ongoing, on-site user involvement with the project team.
現場客戶： 這就對應到了最初軟件開發時所提出的問題――用戶參與。XP，同其他的快速開發一樣，要求客戶在現場持續地參與到項目組中。
Coding standards. XP practices are supportive of each other. For example, if you do pair programming and let anyone modify the communal code, then coding standards would seem to be a necessity.
編碼標準： XP實踐相互支持。例如，如果你進行配對編程并讓他人修改共有代碼，那么編碼標準看起來就是必須的。
價值同規則
On Saturday, 1 January 2000, the Wall Street Journal (you know, the "Monday through Friday" newspaper) published a special 58-page millennial edition. The introduction to the Industry & Economics section, titled "So Long Supply and Demand: There's a new economy out there -- and it looks nothing like the old one," was written by Tom Petzinger. "The bottom line: creativity is overtaking capital as the principal elixir of growth," Petzinger states.
在2000年一月一日周六時候，華爾街日報（周一到周五出版的）用一個58頁的版面發布了一個千僖年紀念版。在篇首的有關工業及金融的介紹里標著Tom Petzinger.寫的："長久的需求與召喚：經濟新的增長點――顯得同以往不同"。底下的一行 Petzinger 寫著："創造性正代替'萬金藥'的資本在成為首要的因素"。
Petzinger isn't talking about a handful of creative geniuses, but the creativity of groups -- from teams to departments to companies. Once we leave the realm of the single creative genius, creativity becomes a function of the environment and how people interact and collaborate to produce results. If your company's fundamental principles point to software development as a statistically repeatable, rigorous, engineering process, then XP is probably not for you. Although XP contains certain rigorous practices, its intent is to foster creativity and communication.
Petzinger并沒有談論少數天才的創造性，而是談了以下群體的創造性――從組到部門。一旦我們撇下天才們的個體創造，創造性就是環境的功能，而人們運用并互相協助而達到我們的結果的能力。如果你的公司認為軟件開發只是一個統計上的重復試驗，刻板的，技術性的過程，那么XP對于您也許并不合適。雖然XP中也有技術實踐里的嚴格，但是XP本身是追求"創造"與"溝通"。
Environments are driven by values and principles. XP (or the other practices mentioned in this issue) may or may not work in your organization, but, ultimately, success won't depend on using 40-hour work weeks or pair programming -- it will depend on whether or not the values and principles of XP align with those of your organization.
環境是靠價值同規則共同驅動的系統。XP（或者其他類似的）可能、也可能不適合您的單位，可是，應該澄清的是成功并不是只靠每周40小時的瘋狂工作或者配對編程，也不是依靠XP之中應用在您單位中的價值或者是規則。
Beck identifies four values, five fundamental principles, and ten secondary principles -- but I'll mention five that should provide enough background.
Beck指出了四個價值，五個基本規則，以及十個輔助規則--不過我要提到是這五個規則。
Communication. So, what's new here? It depends on your perspective. XP focuses on building a person-to-person, mutual understanding of the problem environment through minimal formal documentation and maximum face-to-face interaction. "Problems with projects can invariably be traced back to somebody not talking to somebody else about something important," Beck says. XP's practices are designed to encourage interaction - developer to developer, developer to customer.
溝通： 是的，溝通，可是，這里似乎沒有新的東西在里面？溝通主要是看人們自己的看法，XP構建的基本是人與人，通過最簡潔的文檔，最直接的面對面溝通獲得對任務環境的理解。
Simplicity. XP asks of each team member, "What is the simplest thing that could possibly work?" Make it simple today, and create an environment in which the cost of change tomorrow is low.
簡潔： XP問每個開發組成員："可能實現的最簡潔的方法是什么？"。今天所保持的簡潔，可以為降低明天由于變更所帶來的費用
Feedback. "Optimism is an occupational hazard of programming," says Beck. "Feedback is the treatment." Whether it's hourly builds or frequent functionality testing with customers, XP embraces change by constant feedback. Although every approach to software development advocates feedback -- even the much-maligned waterfall model -- the difference is that XP practitioners understand that feedback is more important than feedforward . Whether it's fixing an object that failed a test case or refactoring a design that is resisting a change, high-change environments require a much different understanding of feedback.
反饋： Beck說："對于編程而言，樂觀主義是一種冒險。"，"而反饋則是相應的解決良藥。"無論是用反復的構建或者頻繁的用戶功能測試，XP都能不斷地接收到反饋。雖然每次對軟件開發策略進行研討時，我們都會說及反饋--即使是非常有害的瀑布模型--不同的是XP的實踐者認為反饋比起前饋(feedforward)來更為重要。無論是對測試失敗的代碼進行修改或者是對用戶拒收的軟件從新返工，開發環境的快速變化要求開發人員對反饋有更好的認識。
Courage. Whether it's a CMM practice or an XP practice that defines your discipline, discipline requires courage. Many define courage as doing what's right, even when pressured to do something else. Developers often cite the pressure to ship a buggy product and the courage to resist. However, the deeper issues can involve legitimate differences of opinion over what is right. Often, people don't lack courage -- they lack conviction, which puts us right back to other values. If a team's values aren't aligned, the team won't be convinced that some practice is "right," and, without conviction, courage doesn't seem so important. It's hard to work up the energy to fight for something you don't believe in.
勇氣： 無論您是使用CMM方法或者是XP的方法，方法使用的本身是要求勇氣的。許多地方將勇氣定義為做某件事情的權利，即使被迫去做其他的事情。開發人員經常借口壓力而發出帶有許多缺陷的產品，并對此加以堅持。然而，更進一步的應該包括其他的正確的不同的東西進來。通常，人們并不是缺少勇氣，而是缺少一種讓正確實踐獲得承認的理由，而且，也不堅信這點，勇氣不像看起來那么重要。而如果你對之沒有信心，那么是很難盡力工作的。
"Courage isn't just about having the discipline," says Jeffries. "It is also a resultant value. If you do the practices that are based on communication, simplicity, and feedback, you are given courage, the confidence to go ahead in a lightweight manner," as opposed to being weighted down by the more cumbersome, design-heavy practices.
"勇氣并不只是方法"，Jeffries說道，它是一種最終的價值。如果你在一種基于"溝通"，"簡潔"，"反饋"的模式下工作，你將獲得勇氣，越往前信賴就越不重要。
Quality work. Okay, all of you out there, please raise your hand if you advocate poor-quality work. Whether you are a proponent of the Rational Unified Process, CMM, or XP, the real issues are "How do you define quality?" and "What actions do you think deliver high quality?" Defining quality as "no defects" provides one perspective on the question; Jerry Weinberg's definition, "Quality is value to some person," provides another. I get weary of methodologists who use the "hacker" label to ward off the intrusion of approaches like XP and lean development. It seems unproductive to return the favor. Let's concede that all these approaches are based on the fundamental principle that individuals want to do a good, high-quality job; what "quality" means and how to achieve it -- now there's the gist of the real debate!
優質的工作：好，如果你們中有贊成劣質工作的話，那么請舉手離開這兒吧。不論你是一個Rational Unified Process，CMM，或是XP的贊成者，其本質的觀點"你怎樣定義質量"與"什么樣的活動會贏得高質量"，定義"無缺點"質量是這個問題的一個方向。Jerry Weinberg的定義是"質量是對多數人有益"
管理XP
One area in which XP (at least as articulated in Beck's book) falls short is management, understandable for a practice oriented toward both small project teams and programming. As Beck puts it, "Perhaps the most important job for the coach is the acquisition of toys and food." (Coaching is one of Beck's components of management strategy.)
對于針對小型項目以及編程而言，在XP（至少是Beck的書中）里對管理的欠缺是可以理解的，。就如Beck寫的，"對于教練(coach)來說，或許最重要的工作就是獲得玩具同食物"（指導是Beck的管理戰略中的一個組成部分）
With many programmers, their recommended management strategy seems to be: get out of the way. The underlying assumption? Getting out of the way will create a collaborative environment. Steeped in the tradition of task-based project management, this assumption seems valid. However, in my experience, creating and maintaining highly functional collaborative environments challenges management far beyond making up task lists and checking off their completion.
同許多的程序員一樣，他們推薦的管理策略像是：躲避。下面的假定呢？躲避會建立一個協作的環境，在傳統的基于任務的管理里，這個假定是有效的。然而，根據我的經驗，創造并維持一個協作的環境會挑戰管理遠離編制任務列表以及檢查。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
