谈谈“极限编程(Extreme Programming)”

原创 2004年10月22日 15:19:00

Extreme Programming

审校 BigMac[AKA]
译者 march-bird lucian yjf taopin wl jazz韩伟 nullgate Simon[AKA]

As we have explored in several issues of eAD, the two most pressing issues in information technology today are:

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来表达。现有有许多关于变化的讨论, 但是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个月中一直都在写的内容。混乱 的时期产生新的问题,而后者又导致了新的实践--新的实践公然违抗 传统的知识,但却得以幸存下来是因为它们能更好地适应这个新的现实世界。至少有四种实践方式我觉得是属于这个范畴的:

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




But first, I discuss some XP basics: the dozen practices that define XP.

XP - The Basics
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, 轻量级的开发以及其它一些未得到广泛应用的方法, 它们成功的原因至少有一百条.

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.

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."

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.

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.

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.

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.

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?

"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).

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.

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.

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.

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."

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.

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.

Values and Principles
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.

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.

Beck identifies four values, five fundamental principles, and ten secondary principles -- but I'll mention five that should provide enough background.

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.

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.

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.

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.

"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.

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
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.)

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.

Figure 1 -- Historical lifecycle change costs.


Figure 2 -- Comtemporary lifecycle change costs.
The Cost of Change
Early on in Beck's book, he challenges one of the oldest assumptions in software engineering. From the mid-1970s, structured methods and then more comprehensive methodologies were sold based on the "facts" shown in Figure 1. I should know; I developed, taught, sold, and installed several of these methodologies during the 1980s.

Beck asks us to consider that perhaps the economics of Figure 1, probably valid in the 1970s and 1980s, now look like Figure 2 - that is, the cost of maintenance, or ongoing change, flattens out rather than escalates. Actually, whether Figure 2 shows today's cost profile or not is irrelevant -- we have to make it true! If Figure 1 remains true, then we are doomed because of today's pace of change.

The vertical axis in Figure 1 usually depicts the cost of finding defects late in the development cycle. However, this assumes that all changes are the results of a mistake -- i.e., a defect. Viewed from this perspective, traditional methods have concentrated on "defect prevention" in early lifecycle stages. But in today's environment, we can't prevent what we don't know about -- changes arise from iteratively gaining knowledge about the application, not from a defective process. So, although our practices need to be geared toward preventing some defects, they must also be geared toward reducing the cost of continuous change. Actually, as Alistair Cockburn points out, the high cost of removing defects shown by Figure 1 provides an economic justification for practices like pair programming.
  图1中的y轴通常用来表示在开发周期的后期发现错误后需要花费的改错成本。可是,这正验证了一个假设,即后期所有需要做的开动均来自前期的一个错误,比方说一个设计缺陷。从这一点来看,传统方法太依赖于在软件生命周期的早期"不出错"。但是在当今瞬息万变的环境中,我们不能完全预防住那些我们预测不到的东西--即由应用需求不断增长而带来的变化,并且这种变化在早期不可能遇见并加以预防。因此,虽然我们要尽可能在早期做出某些应付变化的预防措施,但是更重要的是我们要减少后期改变所带来的开销。正如 Alistai Cockburn 所指出的,需要高成本的图1所示的那种改正缺陷方法,正好从节省开支的角度给了一些实用的方法(如配对编程)一个好的理由。

In this issue of eAD, I want to restrict the discussion to change at the project or application level -- decisions about operating systems, development language, database, middleware, etc., are constraints outside the control of the development team. (For ideas on "architectural" flexibility, see the June and July 1999 issues of ADS.) Let's simplify even further and assume, for now, that the business and operational requirements are known.

Our design goal is to balance the rapid delivery of functionality while we also create a design that can be easily modified. Even within the goal of rapid delivery, there remains another balance: proceed too hurriedly and bugs creep in; try to anticipate every eventuality and time flies. However, let's again simplify our problem and assume we have reached a reasonable balance of design versus code and test time.

With all these simplifications, we are left with one question: how much anticipatory design work do we do? Current design produces the functionality we have already specified. Anticipatory design builds in extra facilities with the anticipation that future requirements will be faster to implement. Anticipatory design trades current time for future time, under the assumption that a little time now will save more time later. But under what conditions is that assumption true? Might it not be faster to redesign later, when we know exactly what the changes are, rather than guessing now?

This is where refactoring enters the equation. Refactoring, according to author Martin Fowler, is "the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure." XP proponents practice continuous, incremental refactoring as a way to incorporate change. If changes are continuous, then we'll never get an up-front design completed. Furthermore, as changes become more unpredictable -- a great likelihood today -- then much anticipatory design likely will be wasted.
  这就是我们为什么要提出重构的原因。重构,Martin Fowler说过,是不改变软件对外表现但是重整内务的一种改进。XP方法的支持者在变化的环境中实践了连续的、增量式的重构方法。如果变化是不断演化的的,那就不可能存在什么一步到位的设计方法。说白了,如果变化不可预测--正如当今社会的情况--过多的在设计时考虑以后可能的变化,完全是一种浪费。

Figure 3 -- Balancing design and refactoring, pre-internet.


Figure 4 -- Balancing design and refactoring today.
I think the diagram in Figure 3 depicts the situation prior to the rapid-paced change of the Internet era. Since the rate of change (illustrated by the positioning of the balance point in the figure) was lower, more anticipatory designing versus refactoring may have been reasonable. As Figure 4 shows, however, as the rate of change increases, the viability of anticipatory design loses out to refactoring- - a situation I think defines many systems today.

In the long run, the only way to test whether a design is flexible involves making changes and measuring how easy they are to implement. One of the biggest problems with the traditional up- front-design-then-maintain strategy has been that software systems exhibit tremendous entropy; they degrade over time as maintainers rush fixes, patches, and enhancements into production. The problem is worse today because of the accelerated pace of change, but current refactoring approaches aren't the first to address the problem. Back in the "dark ages" (circa 1986), Dave Higgins wrote Data Structured Software Maintenance, a book that addressed the high cost of maintenance, due in large part to the cumulative effects of changes to systems over time. Although Higgins advocated a particular program-design approach (the Warnier/Orr Approach), one of his primary themes was to stop the degradation of systems over time by systematically redesigning programs during maintenance activities.
  在一个长期项目中,检验一个设计是否具有很好的灵活性是通过变化需求,同时看看原设计能否很容易的实现新变化的需求。这种传统的"先设计,再维护"策略的最大问题在于软件系统存在非常大的熵(极易变化,没有规律)。一个系统随着时间的推移,维护、改错、打补丁、增强功能等工作会使系统的熵越来越大。现在由于外部环境变化加快,情况正越来越糟。不过,现在的重构技术也不是第一个试图解决这个问题的方法。早在所谓的"黑暗时期"(circa 1986),Dave Higgins 就写过一本名为"Data Structured Software Maintenance"的书,该书指出了由于随着时间的推移变化的累计影响不断增大,维护所需要的开销也将越来说庞大,Higgins 提出了一种新的设计方法(the Warnier/Orr Approach)用于阻止系统的熵增大所带来的负面影响,该方法的思想是在维护过程中有系统的对程序进行重新设计。

Higgins's approach to program maintenance was first to develop a pattern (although the term pattern was not used then) for how the program "should be" designed, then to create a map from the "good" pattern to the "spaghetti" code. Programmers would then use the map to help understand the program and, further, to revise the program over time to look more like the pattern. Using Higgins's approach, program maintenance counteracted the natural tendency of applications to degrade over time. "The objective was not to rewrite the entire application," said Higgins in a recent conversation, "but to rewrite those portions for which enhancements had been requested."
  Higgins 的方法首先为程序改如何设计设定一种模式(虽然那时还没有模式这个提法),然后在细致的代码设计与"好"的模式之间建立一种映射,程序员即根据这种映射关系来理解系统并修改程序,使修改的结果更接近于那个模式。使用 Higgins 这个方法可以通过维护抵消系统谁时间而熵增大的趋势。Higgins 说:"该方法的目标并不是重写整个系统,而只是重写那些根据需要必须增强的部分。"

Although this older-style "refactoring" was not widely practiced, the ideas are the same as they are today -- the need today is just greater. Two things enable, or drive, increased levels of refactoring: one is better languages and tools, and the other is rapid change.

Another approach to high change arose in the early days of RAD: the idea of throwaway code. The idea was that things were changing so rapidly that we could just code applications very quickly, then throw them away and start over when the time for change arose. This turned out to be a poor long-term strategy.
  在早期的 RAD(快速原型开发)方法中还有另一种应付变化的办法:代码抛弃思想。这个思想认为环境和需求变化太快,因此我们唯一的办法只能是快速编写新代码,并且也快速的抛弃老代码。我们认为这不是长久之计。

Refactoring is closely related to factoring, or what is now referred to as using design patterns. Design Patterns: Elements of Reusable Object-Oriented Software, by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, provides the foundational work on design patterns. Design Patterns serves modern-day OO programmers much as Larry Constantine and Ed Yourdon's Structural Design served a previous generation; it provides guidelines for program structures that are more effective than other program structures.
  重构(Refactoring)与构造 (factoring),或者说与设计模式的使用密切相关。Erich Gamma, Richard Helm, Ralph Johnson, 和 John Vlissides合著的《 Design Patterns: Elements of Reusable Object-Oriented 》一书为设计模式做出了奠基性的工作。正如Larry Constantine 和Ed Yourdon 所倡导的结构化设计一样,设计模式对当代的面向对象技术程序设计做出了巨大的贡献,为开发人员带来了福音。通过设计模式,程序的结构的比以往更为有效。

If Figure 4 shows the correct balance of designing versus refactoring for environments experiencing high rates of change, then the quality of initial design remains extremely important. Design patterns provide the means for improving the quality of initial designs by offering models that have proven effective in the past.
  如果图表4 所显示的设计(designing)与重构(refactoring)在面对高速变化环境时的适应能力方面的差别是客观的话,初始设计的质量则显的尤为重要。通过提供过去已被证明是有效的模式,设计模式(Design patterns)提供了一种提高初始设计质量的方法。

So, you might ask, why a separate refactoring book? Can't we just use the design patterns in redesign? Yes and no. As all developers (and their managers) understand, messing with existing code can be a ticklish proposition. The cliché "if it ain't broke, don't fix it" lives on in annals of development folklore. However, as Fowler comments, "The program may not be broken, but it does hurt." Fear of breaking some part of the code base that's "working" actually hastens the degradation of that code base. However, Fowler is well aware of the concern: "Before I do the refactoring, I need to figure out how to do it safely.... I've written down the safe steps in the catalog." Fowler's book, Refactoring: Improving the Design of Existing Code, catalogs not only the before (poor code) and after (better code based on patterns), but also the steps required to migrate from one to the other. These migration steps reduce the chances of introducing defects during the refactoring effort.
  现在,也许你会问,为什么还需要一本独立讲重构的书呢?难道我们不可以只使用设计模式来重新设计吗?可以,也不可以。正如所有的开发人员(包括管理者)都知道,修改原有的程序代码是一件棘手的事。development folklore年刊上有一句话,"if it ain't broke,don't fix it".然而,正如Fowler所提到的,"程序也许还没有'坏掉',但却造成了潜在的危害." 害怕对那些还能"工作"的代码重新构造实际上只会加剧代码性能的衰退。同时,Fowler也清楚的认识到:"在软件重构之前,需要找到安全的做法……我把这些安全的步骤写进了目录"。Fowler所写的<>,不仅编录了如何对以前的(差的)代码和以后的(基于模式设计的较好)的代码进行重构的方法,而且也包含了代码分割重构的步骤。这些步骤减少了在重构过程中出现差错的机会。

Beck describes his "two-hat" approach to refactoring -- namely that adding new functionality and refactoring are two different activities. Refactoring, per se, doesn't change the observable behavior of the software; it enhances the internal structure. When new functionality needs to be added, the first step is often to refactor in order to simplify the addition of new functionality. This new functionality that is proposed, in fact, should provide the impetus to refactor.
  Beck用"two-hat"方法来描述重构,也就是说, 添加新的功能与重构是两种不同的行为。在本质上,重构不改变软件可见的外部功能,它只是增强了软件的内部结构。当有新的功能需要添加时,第一步常是对软件进行重构,使添加更简化。事实上,这种添加的新功能为重构提供着推动力。

Refactoring might be thought of as incremental, as opposed to monumental, redesign. "Without refactoring, the design of the program will decay," Fowler writes. "Loss of structure has a cumulative effect." Historically, our approach to maintenance has been "quick and dirty," so even in those cases where good initial design work was done, it degraded over time.
  与重量级的再设计相反,重构可以被认为是增量(incremental)式的再设计,"没有重构,程序设计会 腐烂",Fowler写到," 结构性的缺陷会带来累积效应 "。历史上,我们对软件维护的方法是"quick and dirty"(快速但不彻底的?),致使一些初始设计工作做的好的项目,随着时间推移,也会"退化"(degrade).

Figure 5 -- Software entropy over time.
Figure 5 shows the impact of neglected refactoring -- at some point, the cost of enhancements becomes prohibitive because the software is so shaky. At this point, monumental redesign (or replacement) becomes the only option, and these are usually high- risk, or at least high-cost, projects. Figure 5 also shows that while in the 1980s software decay might have taken a decade, the rate of change today hastens the decay. For example, many client- server applications hurriedly built in the early 1990s are now more costly to maintain than mainframe legacy applications built in the 1980s.
  图表 5 显示了没有重构时的情况:因为软件是如此的不可靠,升级维护费用变的让人望而却步,于是巨型(monumental)设计(或替换)成了唯一选择,项目的风险,至少是投入上,变的越来越大。图 5也显示,在80年代,软件的生存期大约要10年,而在今天需求的快速变化加剧了软件的腐烂。举个例子,许多90年代初一窝蜂做出来的C/S应用软件在今天比80年代留下来的大型机软件的维护费用还要高的多。

Data Refactoring: Comments by Ken Orr
数据重构: Ken Orr注解
Editor's Note: As I mentioned above, one thing I like about XP and refactoring proponents is that they are clear about the boundary conditions for which they consider their ideas applicable. For example, Fowler has an entire chapter titled "Problems with Refactoring." Database refactoring tops Fowler's list. Fowler's target, as stated in the subtitle to his book, is to improve code. So, for data, I turn to someone who has been thinking about data refactoring for a long time (although not using that specific term). The following section on data refactoring was written by Ken Orr.
  编者注: 如上所提,XP和重构思想吸引我的一点是他们能够清楚认识到所要考虑实施问题的边界条件(boundary conditions).例如,Fowler写了一章"Problems with Refactoring".其中首要的问题就是数据库的重构。正如书的副标题所示,Fowler的目标是为了提高代码质量。为此,我咨询了一些在数据重构(或者用其他的术语)方面有较深研究的人。以下关于数据重构部分由Ken Orr所写。

When Jim asked me to put together something on refactoring, I had to ask him what that really meant. It seemed to me to come down to a couple of very simple ideas:
  当Jim 要我讲一讲重构时,我问他重构究竟意味着什么。对我来说,把它归纳为以下简单的几点:

Do what you know how to do.

Do it quickly.

When changes occur, go back and redesign them in.

Go to 1.
回到 1

Over the years, Jim and I have worked together on a variety of systems methodologies, all of which were consistent with the refactoring philosophy. Back in the 1970s, we created a methodology built on data structures. The idea was that if you knew what people wanted, you could work backward and design a database that would give you just the data that you needed, and from there you could determine just what inputs you needed to update the database so that you could produce the output required.
  在过去几年中,Jim和我一起工作,共同研究各种系统方法学(systems methodologies),发现所有的方法学与重构思想(refactoring philosophy)有着一致的地方。70年代,我们建立了一种基于数据结构的方法学。其主要思想是:在知道了人们的需求后,逆向工作,设计一个仅含必需数据的数据库,然后再确定更新数据库必需的输入数据,产生需要的输出数据。

Creating systems by working backward from outputs to database to inputs proved to be a very effective and efficient means of developing systems. This methodology was developed at about the same time that relational databases were coming into vogue, and we could show that our approach would always create a well-behaved, normalized database. More than that, however, was the idea that approaching systems this way created minimal systems. In fact, one of our customers actually used this methodology to rebuild a system that was already in place. The customer started with the outputs and worked backward to design a minimal database with minimal input requirements.
  从输出结果逆向工程到数据库再到输入来建构系统的方法被证明是一种非常有效和有效率的系统开发方法。几乎在关系数据库开始流行的同时,这种方法也发展了起来。使我们能够建立起运作良好,规范化的数据库。除此之外,这种思想也适用于创建最小系统(minimal systems).事实上,我们的一个客户在重建一个系统时已经使用了这种方法并取得了成功。该客户从输出入手,通过逆向工程设计了一个满足最小输入需求的最小数据库。

The new system had only about one-third the data elements of the system it was replacing. This was a major breakthrough. These developers came to understand that creating minimal systems had enormous advantages: they were much smaller and therefore much faster to implement, and they were also easier to understand and change, since everything had a purpose.
  新系统只有老系统三分之一的数据元(data elements )。这是一个大的突破。开发人员开始逐渐认识到建立最小系统有着巨大的优势:系统更小因而可以更快的实现;功能单一更能适应变化。

Still, building minimal systems goes against the grain of many analysts and programmers, who pride themselves on thinking ahead and anticipating future needs, no matter how remote. I think this attitude stems from the difficulty that programmers have had with maintenance. Maintaining large systems has been so difficult and fraught with problems that many analysts and programmers would rather spend enormous effort at the front end of the systems development cycle, so they don't have to maintain the system ever again. But as history shows, this approach of guessing about the future never works out. No matter how clever we are in thinking ahead, some new, unanticipated requirement comes up to bite us. (How many people included Internet-based e-business as one of their top requirements in systems they were building 10 years ago?)

Ultimately, one of the reasons that maintenance is so difficult revolves around the problem of changing the database design. In most developers' eyes, once you design a database and start to program against it, it is almost impossible to change that database design. In a way, the database design is something like the foundation of the system: once you have poured concrete for the foundation, there is almost no way you can go back and change it. As it turns out, major changes to databases in large systems happen very infrequently, only when they are unavoidable. People simply do not think about redesigning a database as a normal part of systems maintenance, and, as a consequence, major changes are often unbelievably difficult.

Enter Data Refactoring
Jim and I had never been persuaded by the argument that the database design could never be changed once installed. We had the idea that if you wanted to have a minimal system, then it was necessary to take changes or new requirements to the system and repeat the basic system cycle over again, reintegrating these new requirements with the original requirements to create a new system. You could say that what we were doing was data refactoring, although we never called it that.

The advantages of this approach turned out to be significant. For one thing, there was no major difference between development of a new system and the maintenance or major modification of an existing one. This meant that training and project management could be simplified considerably. It also meant that our systems tended not to degrade over time, since we "built in" changes rather than "adding them on" to the existing system.
  这么做的好处是显而易见的.首先,开发一个新系统和维护或对旧系统统进行较大改造的区别并不是很大.这就意味着管理一个项目和培训工作将大大减少.同时,也将减少开发时间,这是因为我们对变化的处理方式不同,一个是'built in'(建立在变化之上),另一个是'adding them on'(添加变化)。

Over a period of years, we built a methodology (Data Structured Systems Development or Warnier/Orr) and trained thousands of systems analysts and programmers. The process that we developed was largely manual, although we thought that if we built a detailed-enough methodology, it should be possible to automate large pieces of that methodology in CASE tools.

Automating Data Refactoring
To make the story short, a group of systems developers in South America finally accomplished the automation of our data refactoring approach in the late 1980s. A company led by Breogán Gonda and Nicolás Jodal created a tool called GeneXus1 that accomplished what we had conceived in the 1970s. They created an approach in which you could enter data structures for input screens; with those data structures, GeneXus automatically designed a normalized database and generated the code to navigate, update, and report against that database.
  为了缩短开发时间,南美的一组系统开发人员在80年代年开发出了数据重构自动化工具。由Breogán Gonda 和 Nicolás Jodal领导的公司开发了一种名叫GeneXus的工具,这正是我们在70年代所构想要的。他们创建的方法使我们在输入数据结构以后,系统能够自动为你创建规范的数据库并产生浏览、更新和输出数据的代码。

But that was the easy part. They designed their tool in such a way that when requirements changed or users came up with something new or different, they could restate their requirements, rerun (recompile), and GeneXus would redesign the database, convert the previous database automatically to the new design, and then regenerate just those programs that were affected by the changes in the database design. They created a closed-loop refactoring cycle based on data requirements.

GeneXus showed us what was really possible using a refactoring framework. For the first time in my experience, developers were freed from having to worry about future requirements. It allowed them to define just what they knew and then rapidly build a system that did just what they had defined. Then, when (not if) the requirements changed, they could simply reenter those changes, recompile the system, and they had a new, completely integrated, minimal system that incorporated the new requirements.

What Does All This Mean?
Refactoring is becoming something of a buzzword. And like all buzzwords, there is some good news and some bad news. The good news is that, when implemented correctly, refactoring makes it possible for us to build very robust systems very rapidly. The bad news is that we have to rethink how we go about developing systems. Many of our most cherished project management and development strategies need to be rethought. We have to become very conscious of interactive, incremental design. We have to be much more willing to prototype our way to success and to use tools that will do complex parts of the systems development process (database design and code generation) for us.

In the 1980s, CASE was a technology that was somehow going to revolutionize programming. In the 1990s, objects and OO development were going to do the same. Neither of these technologies lived up to their early expectations. But today, tools like GeneXus really do many of the things that the system gurus of the 1980s anticipated. It is possible, currently, to take a set of requirements, automatically design a database from those requirements, generate an operational database from among the number of commercially available relational databases (Oracle, DB2, Informix, MS SQL Server, and Access), and generate code (prototype and production) that will navigate, update, and report against those databases in a variety of different languages (COBOL, RPG, C, C++, and Java). Moreover, it will do this at very high speed.
  80年代,CASE使开发产生革命性的变化。90年代,对象和OO方法也使开发产生革命性的变化。这些技术都没有像达到期望的效果。但现在,像GeneXus这样的工具切切实实的做到了80年代人们所期望的东西。确实有可能在给定系统需求后自动进行数据库设计,生成一种实际工作的商用关系型数据库(Oracle, DB2, Informix, MS SQL Server, and Access),并产生能够浏览、更新和输出数据库中数据的不同语言(COBOL, RPG, C, C++, and Java)的代码(原型和结果)。

This new approach to systems development allows us to spend much more time with users, exploring their requirements and giving them user interface choices that were never possible when we were building things at arm's length. But not everybody appreciates this new world. For one thing, it takes a great deal of the mystery out of the process. For another, it puts much more stress on rapid development.

When people tell you that building simple, minimal systems is out of date in this Internet age, tell them that the Internet is all about speed and service. Tell them that refactoring is not just the best way to build the kind of systems that we need for the 21st century, it is the only way.


1Gonda and Jodal created a company called ARTech to market the GeneXus product. It currently has more than 3,000 customers worldwide and is marketed in the US by GeneXus, Inc.


Crystal Light Methods: Comments by Alistair Cockburn
Editor's note: In the early 1990s, Alistair Cockburn was hired by the IBM Consulting Group to construct and document a methodology for OO development. IBM had no preferences as to what the answer might look like, just that it work. Cockburn's approach to the assignment was to interview as many project team members as possible, writing down whatever the teams said was important to their success (or failure). The results were surprising. The remainder of this section was written by Cockburn and is based on his "in-process" book on minimal methodologies.
  编者注:在九十年代早期,Alistair Cockburn IBM顾问组工作时,为OO(面向对象)的开发制订了一套工作方法。IBM认为不管白猫黑猫,抓的到老鼠就是好猫。Cockburn 深入接触许多开发小组,写下了他们认为导致项目成功或者失败的关键之处。结果让人大吃一惊。以下内容是由 Cockburn写的,基于他的含有极少方法论的"实战工作"书 。

In the IBM study, team after successful team "apologized" for not following a formal process, for not using a high-tech CASE tool, for "merely" sitting close to each other and discussing as they went. Meanwhile, a number of failing teams puzzled over why they failed despite using a formal process - maybe they hadn't followed it well enough? I finally started encountering teams who asserted that they succeeded exactly because they did not get caught up in fancy processes and deliverables, but instead sat close together so they could talk easily and delivered tested software frequently.
  在IBM的研究组里,开发小组要向以前成功的小组"道歉",因为他们没有遵守一道正式的工序, 因为他们没有用一个高科技的CASE工具,又或者"仅仅"因为他们坐在一起,讨论他们下步 该怎么做。 同时,一些失败的小组觉得非常迷惑,尽管他们使用了正式的工序,他们还是 失败了--也许是遵守这些工序还遵守的不够好?后来我开始碰到一些成功的小组,他们宣称 正是因为没有陷于花里胡哨的过程和可发布性,而是大家坐在一起,从而使得他们可以 更容易的加以讨论并且经常交换测试后的软件,最终才得以成功。

These results have been consistent, from 1991 to 1999, from Hong Kong to the Americas, Norway, and South Africa, in COBOL, Smalltalk, Java, Visual Basic, Sapiens, and Synon. The shortest statement of the results are:
  这些结论从 1991 到 1999,从香港到美国, 挪威, 和南非,在COBOL, Smalltalk, Java, Visual Basic, Sapiens, 和 Synon都是一贯坚持 , 这些结论的最短描述是:

To the extent you can replace written documentation with face-to-face interactions, you can reduce reliance on written work products and improve the likelihood of delivering the system.
尽可能在你的范围内,用面对面的沟通来代替写文档,从而可以减少对写好了的工作产品的依赖,并 增大发布系统的可能性

The more frequently you can deliver running, tested slices of the system, the more you can reduce reliance on written "promissory" notes and improve the likelihood of delivering the system.

People are communicating beings. Even introverted programmers do better with informal, face-to-face communication than with paper documents. From a cost and time perspective, writing takes longer and is less communicative than discussing at the whiteboard.

Written, reviewed requirements and design documents are "promises" for what will be built, serving as timed progress markers. There are times when creating them is good. However, a more accurate timed progress marker is running tested code. It is more accurate because it is not a timed promise, it is a timed accomplishment.
  那些写好的而且评审过的需求和设计文档,只是"承诺"了要做什么,我们可以将其作为项目进度的标志 使用。有很多进度标志在最初设立时是好的。然而,更准确的进度标志应该是运行测试后的代码。因为这不是预先承诺的标志,而是真正完成的标志。

Recently, a bank's IT group decided to take the above results at face value. They began a small project by simply putting three people into the same room and more or less leaving them alone. Surprisingly (to them), the team delivered the system in a fine, timely manner. The bank management team was a bit bemused. Surely it can't be this simple?

It isn't quite so simple. Another result of all those project interviews was that: different projects have different needs. Terribly obvious, except (somehow) to methodologists. Sure, if your project only needs 3 to 6 people, just put them into a room together. But if you have 45 or 100 people, that won't work. If you have to pass Food & Drug Administration process scrutiny, you can't get away with this. If you are going to shoot me to Mars in a rocket, I'll ask you not to try it. We must remember factors such as team size and demands on the project, such as:

As the number of people involved grows, so does the need to coordinate communications.

As the potential for damage increases, the need for public scrutiny increases, and the tolerance for personal stylistic variations decreases.

Some projects depend on time-to-market and can tolerate defects (Web browsers being an example); other projects aim for traceability or legal liability protection.
一些项目依赖市场方面所确定的发布时间,而且对于一些缺陷能加以容忍(WEB浏览器就是这样一个例子);其他的一些 项目致力于条理性和法律责任。

The result of collecting those factors is shown in Figure 6. The figure shows three factors that influence the selection of methodology: communications load (as given by staff size), system criticality, and project priorities.
  根据收集到的有关因素总结出的结论如图Figure 6所示。它显示了影响选择不同方法论的三个因数:沟通难度(由成员的数量决定),系统关键程序,以及项目的优先级。

Figure 6 -- The family of Crystal methods.


Locate the segment of the X axis for the staff size (typically just the development team). For a distributed development project, move right one box to account for the loss of face-to-face communications.

On the Y axis, identify the damage effect of the system: loss of comfort, loss of "discretionary" monies, loss of "essential" monies (e.g., going bankrupt), or loss of life.

The different planes behind the top layer reflect the different possible project priorities, whether it is time to market at all costs (such as in the first layer), productivity and tolerance (the hidden second layer), or legal liability (the hidden third layer). The box in the grid indicates the class of projects (for example, C6) with similar communications load and safety needs and can be used to select a methodology.

The grid characterizes projects fairly objectively, useful for choosing a methodology. I have used it myself to change methodologies on a project as it shifted in size and complexity. There are, of course, many other factors, but these three determine methodology selection quite well.

Suppose it is time to choose a methodology for the project. To benefit from the project interviews mentioned earlier, create the lightest methodology you can even imagine working for the cell in the grid, one in which person-to-person communication is enhanced as much as possible, and running tested code is the basic timing marker. The result is a light, habitable (meaning rather pleasant, as opposed to oppressive), effective methodology. Assign this methodology to C6 on the grid.

Repeating this for all the boxes produces a family of lightweight methods, related by their reliance on people, communication, and frequent delivery of running code. I call this family the Crystal Light family of methodologies. The family is segmented into vertical stripes by color (not shown in figure): The methodology for 2-6 person projects is Crystal Clear, for 6-20 person projects is Crystal Yellow, for 20-40 person projects is Crystal Orange, then Red, Magenta, Blue, etc.
  重复这些所有的格子,产生一个轻量级的方法的家族,根据他们对人们的信心,沟通,和发布运行代码的频率。我叫这个家族为Crystal Light方法论族。这个家族用颜色(在图上没画)分成不同的竖直的条纹:2-6个人的项目的方法论叫 Crystal Clear ,6-20人的项目的方法论叫 Crystal Yellow , 20-40人的项目的方法论叫 Crystal Orange,然后是 Red,Magenta,Blue,等等。

Shifts in the vertical axis can be thought of as "hardening" of the methodology. A life-critical 2-6-person project would use "hardened" Crystal Clear, and so on. What surprises me is that the project interviews are showing rather little difference in the hardness requirement, up to life-critical projects.
  垂直方向间的切换在方法学上被称为强化。一个短生命期的2到6个人的项目应该使用强化了的Crystal Clear或其派生方法来管理。使我惊喜的是,在这样的 项目中几乎看不到增加需求和按时完成项目之间的矛盾。

Crystal Clear is documented in a forthcoming book, currently in draft form on the Web. Crystal Orange is outlined in the methodology chapter of Surviving Object-Oriented Projects (see Editor's note below).
  Crystal Clear出自一本即将出版的书,现在网上已经有草稿。在《Surviving Object-Oriented Projects》一书的方法论一章中描述了Crystal Orange的轮廓。

Having worked with the Crystal Light methods for several years now, I found a few more surprises.
  在采用Crystal Light方法多年以后,现在我发现了更多的惊喜。

The first surprise is just how little process and control a team actually needs to thrive (this is thrive, not merely survive). It seems that most people are interested in being good citizens and in producing a quality product, and they use their native cognitive and communications abilities to accomplish this. This matches Jim's conclusions about adaptive software development (see Resources and References, page 15). You need one notch less control than you expect, and less is better when it comes to delivering quickly.

极限编程(Extreme Programming)—轻量级的Crystal方法

极限编程(Extreme Programming)—轻量级的Crystal方法march-bird lucian yjf taopin wl jazz韩伟 nullgate Simon[AKA](转载...
  • silures
  • silures
  • 2004年10月30日 13:31
  • 948


 极限编程(XP,eXtreme Programming)是一种软件工程方法学,是敏捷软件开发中最富有成效的几种方法学之一。如同其他敏捷方法学,极限编程和传统方法学的本质不同在于它更强调可适应性而不是...
  • Max__Payne
  • Max__Payne
  • 2008年12月27日 18:29
  • 2190

极限编程的例子 老师发的课件

  • 2010年07月18日 18:12
  • 110KB
  • 下载


《解析极限编程》这本书已经买回来好长时间了,直至今天才有时间翻开看。 目前看了前言与第一章,首次领略到原创Kent Beck对XP的解释,感受到大师级人物的量级之重以及对软件业思想的深远影响。以下是一...
  • jianfengqu
  • jianfengqu
  • 2010年02月18日 12:12
  • 409


Differences Between Scrum and Extreme Programming Scrum与XP极限编程的不同之处Scrum and Extreme Programming (X...
  • seagal890
  • seagal890
  • 2016年01月02日 21:33
  • 922

《Extreme Programming Explained》 读书笔记

Feelings Before our holiday begin, I borrow the book from library. It’s written in both Chinese and...
  • dongzhe8
  • dongzhe8
  • 2014年03月15日 21:33
  • 546

极限编程 Extreme Programming (中英文对照)图形解释

 极限编程 Extreme Programming 作者 不详 来源 审校 BigMac[AKA]译者 march-bird lucian yjf taopin wl jazz韩伟 nullgate ...
  • SafeF8
  • SafeF8
  • 2005年01月03日 22:07
  • 4503

Extreme Programming介绍

Extreme Programming介绍计划 User stories的编写 开发计划的制定 经常构造版本 Load Factor因子的确定 将项目分解为各个迭代期 每个迭代期开始时制定计划 人员集...
  • cngkqy
  • cngkqy
  • 2008年01月17日 11:13
  • 3617

Reading : Extreme Programming Explained: Embrace Change (2nd Edition) (The XP Series)

客户驱动系统的内容。客户(内部或外部的)从系统需要解决什么问题的概要想法开始。但是,客户通常不会清楚地知道软件应该做成什么样子。 整个团队从当前的一组实践开始,驱动着开发的过程。随着开发的继续,团队将...
  • flyhigher2003
  • flyhigher2003
  • 2007年07月18日 18:14
  • 527

极限编程(Extreme Programming)—实践

极限编程(Extreme Programming)—实践 march-bird lucian yjf taopin wl jazz韩伟 nullgate Simon[AKA](转载自cutter.co...
  • silures
  • silures
  • 2004年10月30日 13:42
  • 965
您举报文章:谈谈“极限编程(Extreme Programming)”