價值和規則
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的定義是"質量是對多數人有益"
Managing XP
管理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/
