极限编程（Extreme Programming）

极限编程（Extreme Programming）—走向极限

march-bird lucian yjf taopin wl jazz韩伟 nullgate Simon[AKA](转载自cutter.com)　　　　2003年09月15日

　　Conclusions: Going to Extremes

　　结论：走向极限

　　Orr and Cockburn each describe their approaches and experience with lighter methodologies. But earlier, in describing Chrysler's C3 project, I alluded to the difficulty in extending the use of approaches like XP or even RAD. In every survey we have done of eAD subscribers, and every survey conducted of software organizations in general, respondents rate reducing delivery time as a critical initiative. But it is not just initial delivery that is critical. Although Amazon.com may have garnered an advantage by its early entry in the online bookstore market, it has maintained leadership by continuous adaptation to market conditions -- which means continuous changes to software.

　　Orr 和 Cockburn 都描述了他们的轻量级方法和经验。但在前面描述Chrysler的 C3 项目时，我间接的提到，扩展使用类似XP或者甚至是RAD的方法都存在着困难。在我们对eAD的订阅者所做的所有调查以及所有软件组织的行为调查中，一般说来，快速的响应速度，减少发布时间是一个关键的开始。但这并不是说只有首次发布才是关键的。虽然 Amazon.com 因为更早进入网上书店市场而拥有优势，但它为了维持它的领导地位，必须持续不断的适应市场条件----这意味着软件的持续更改。
　　
　　Deliver quickly. Change quickly. Change often. These three driving forces, in addition to better software tools, compel us to rethink traditional software engineering practices -- not abandon the practices, but rethink them. XP, for example, doesn't ask us to abandon good software engineering practices. It does, however, ask us to consider closely the absolute minimum set of practices that enable a small, co-located team to function effectively in today's software delivery environment.
　　
　　快速发布.快速修改.频繁变更.通过这三者的驱动，加上更好的软件工具，迫使我们重新思考传统的软件工程实践----并不是放弃它们，而是对其重新加以思考。例如，XP 并没有要我们抛弃好的软件工程实践。相反，它要求我们去深入地思考，在当今软件发布环境下，小型协作团队能够高效运作所需的最低环境要求有哪些。

　　Cockburn made the observation that implementation of XP (at least as Beck and Jeffries define it) requires three key environmental features: inexpensive inter-face changes, close communications, and automated regression testing. Rather than asking "How do I reduce the cost of change?" XP, in effect, postulates a low-change cost environment and then says, "This is how we will work." For example, rather than experience the delays of a traditional relational database environment (and dealing with multiple outside groups), the C3 project used GemStone, an OO database.

　　Cockburn 观察发现，XP（至少按照Beck和Jeffries所定义的那样）的实现至少需要三个环境特征：界面修改不会带来昂贵的的代价，更密切的交流和自动的回归测试。实际上 XP 不是问"我该如何降低变更带来的成本"，而是要求一个低更改成本的环境，然后说"我们将这样工作"。例如， C3项目使用面向对象数据库GemStone，而不是去使用传统关系数据库（以及和多个外部组打交道）。

　　Some might argue that this approach is cheating, but that is the point. For example, Southwest Airlines created a powerhouse by reducing costs -- using a single type of aircraft (Boeing 737s). If turbulence and change are the norm, then perhaps the right question may be: how do we create an environment in which the cost (and time) of change is minimized? Southwest got to expand without an inventory of "legacy" airplanes, so its answer might be different than American Airline's answer, but the question remains an important one.

　　有些人也许会说这种方法是欺骗，确实如此。例如，西南航空公司在创建动力室时，使用同一种类型的飞机（波音737）来降低成本。如果湍流和改变都是标准的，那么正确的问题可能就是：我们如何创建一个导致最低变更成本（和时间）的环境？西南航空公司在扩张时，没有遗留的飞机存货。对于美国航空公司来说，这个问题的答案也许会不同，但是它仍然是个重要的问题。

　　There are five key ideas to take away from this discussion of XP and light methods:

　　在这个关于XP和轻量方法的讨论中，我们能得到如下五个主要观点：

　　For projects that must be managed in high-speed, high-change environments, we need to reexamine software development practices and the assumptions behind them.

　　对于那些处于飞速变化环境中的项目而言，我们需要重新检视有关的软件开发实践以及与之对应的有关假定。
　　
　　Practices such as refactoring, simplicity, and collaboration (pair programming, metaphor, collective ownership) prompt us to think in new ways.

　　类似于重构、简单化和合作（配对编程，隐喻，代码共享）等实践促使我们以一种新思路来思考。

　　We need to rethink both how to reduce the cost of change in our existing environments and how to create new environments that minimize the cost of change.

　　我们不仅需要重新思考如何在现有环境中降低变更导致的成本，而且还需要重新考虑如何创造一个新的环境, 从而能够将变更成本降到最低。

　　In times of high change, the ability to refactor code, data, and whole applications becomes a critical skill.

　　在频繁变动中，对代码, 数据以及整个应用重构的能力将会成为一项关键的技能。
　　
　　Matching methods to the project, relying on people first and documentation later, and minimizing formality are methods geared to change and speed.

　　将方法应用到项目中去时，先依赖人，再依赖文档，尽量减少形式化的东西，从而有效地将方法与项目相结合

　　Editor's Musings

　　编者的沉思（编后语）

　　Extreme rules! In the middle of writing this issue, I received the 20 December issue of BusinessWeek magazine, which contains the cover story, "Xtreme Retailing," about "brick" stores fighting back against their "click" cousins. If we can have extreme retailing, why not Extreme Programming?

　　极端的规则。在写这篇文章的过程中，我曾经收到12月20日发行的商业周刊杂志。其中有一个封面故事，"极端零售"，关于"brick"商店反击它们的堂兄弟"click"。如果我们可以有极端零售，为什么不极端编程呢。

　　Refactoring, design patterns, comprehensive unit testing, pair programming -- these are not the tools of hackers. These are the tools of developers who are exploring new ways to meet the difficult goals of rapid product delivery, low defect levels, and flexibility. Writing about quality, Beck says, "The only possible values are 'excellent' and 'insanely excellent,' depending on whether lives are at stake or not" and "runs the tests until they pass (100% correct)." You might accuse XP practitioners of being delusional, but not of being poor-quality-oriented hackers.

　　重构，设计模式，对单元测试的充分理解，配对编程----这些都不是黑客们的工具。它们是开发者们为了解决产品快速发布，同时又能保持较少的缺陷和灵活性时探索出的新方法。关于质量，Beck说，"只有两种情况下是有价值的：'优秀'或者'极其优秀'，这取决于其对软件产品生存的影响程度"，以及 "执行测试直到它们通过（100％正确）"。你也许可以指责XP的实践者是受到了蒙蔽，但是他们决不是那种不重视质量的黑客。

　　To traditional methodology proponents, reducing time-to-market is considered the enemy of quality. However, I've seen some very slow development efforts produce some very poor-quality software, just as I've seen speedy efforts produce poor-quality software. Although there is obviously some relationship between time and quality, I think it is a much more complicated relationship than we would like to think.

　　对于传统方法的支持者来说，缩短发布时间是质量的敌人。然而，我看过一些开发速度很慢而且质量非常差的软件，就象我看过的另一些开发速度很快但质量低下的软件一样。虽然在时间和质量间存在一些明显的联系，但我认为这个联系比我们一般所想象的要的复杂的多。

　　Traditional methodologies were developed to build software in environments characterized by low to moderate levels of change and reasonably predictable desired outcomes. However, the business world is no longer very predictable, and software requirements change at rates that swamp traditional methods. "The bureaucracy and inflexibility of organizations like the Software Engineering Institute and practices such as CMM are making them less and less relevant to today's software development issues," remarks Bob Charette, who originated the practices of lean development for software.
　　
　　传统方法可用于开发那些变化程度不大并可预期最终结果的软件.然而，商业世界却是变化莫测的，并且传统开发方法已无法满现在的快速变化软件需求的要求。轻量级软件开发实践的创始人Bob Charette认为"由于软件工程研究所(SEI)这样组织的官僚化、顽固性，以及诸如CMM的实践，使得他们日益脱离当今的软件开发。

　　As Beck points out in the introduction to his book, the individual practices of XP are drawn from well-known, well-tested, traditional practices. The principles driving the use of these practices, along with the integrative nature of using a specific minimal set of practices, make XP a novel solution to modern software development problems.
　　
　　就象Beck在他书中所写的简介中指出的一样，XP中的各个独立实践，都是从著名的，经过很好的测试的，传统实践中抽取出来的。这些原则驱动着实践的使用，与一个特别的实践最小集自然的一体化在一起，使得XP成为一个解决现代软件开发问题的新方案。

　　But I must end with a cautionary note. None of these new practices has much history. Their successes are anecdotal, rather than studied and measured. Nevertheless, I firmly believe that our turbulent e-business economy requires us to revisit how we develop and manage software delivery. While new, these approaches offer alternatives well worth considering.
　　
　　但是我必须以一条警告来做结束语。所有的这些新实践都没有很长的历史，它们的成功就象逸事一样，没有被加以研究和度量。然而我坚信，我们混乱的电子商务经济需要我们重新审视如何开发和管理软件发布。这些方法虽然很新，但它们提供了有价值的另一条思路。

　　In the coming year, we will no doubt see more in print on XP. Beck, Jeffries, Fowler, and Cunningham are working in various combinations with others to publish additional books on XP, so additional information on practices, management philosophy, and project examples will be available.
　　
　　明年，我们毫无疑问地可以看到更多关于XP的出版物，Beck, Jeffries, Fowler和Cunningham 都在相互合作出版更多关于XP的书。因此，你将看到更多的关于实践的信息，管理哲学和项目实例等。

　　Finally, a note on how to continue the discussion of XP and other "extremes": as I announced in the previous issue, we have initiated an eAD discussion forum. If you are interested in joining the group, send us an e-mail at ead@cutter.com, and we will add you to the discussion group and send logon information.
　　
　　最后，一个关于如何继续XP和其他"极端事物"讨论的提示：就象我在前面讨论中宣布的那样，我们创建了一个eAD论坛。如果你对加入这个小组感兴趣，给我们发email到 ead@cutter.com，我们将把你加入这个讨论组，并且会把登录信息发送给你

极限编程（Extreme Programming）—走向极限相关推荐

极限编程 Extreme Programming （中英文对照）图形解释
极限编程 Extreme Programming 作者不详来源审校 BigMac[AKA] 译者 march-bird lucian yjf taopin wl jazz韩伟 nullgate ...
极限编程(Extreme Programming)
极限编程(Extreme Programming) 作者不详来源 http://www.cutter.com/ 译者 march-bird lucian yjf taopin wl jazz韩伟 ...
极限编程(eXtreme Programming)简介
极限编程(eXtreme Programming)是近几年才时兴起来的开发模型,极限编程(eXtreme Programming)主要是针对中小型开发团队在开发时间要求紧.需求不稳定的中小项目(大多数 ...
极限编程 (Extreme Programming) 和用户故事 (User Stories) 的关系
(Source: User Stories) 用户故事与用例具有相同的用途,但不尽相同.它们用于为发布计划会议创建时间估计.它们也用于代替大型需求文档.用户故事由客户编写,作为系统需要为他们执行的操作 ...
极限编程 (Extreme Programming) - 迭代计划 (Iterative Planning)
(Source: XP - Iteration Planning) 在每次迭代开始时调用迭代计划会议,以生成该迭代的编程任务计划.每次迭代为1到3周. 客户从发布计划中按照对客户最有价值的顺序选择用户 ...
极限编程 (Extreme Programming) - 发布计划 (Release Planning)
编写用户故事后,您可以使用发布计划会议来创建发布计划.发布计划指定将为每个系统版本实现哪些用户故事以及这些版本的日期.这给出了一组用户故事供客户在迭代计划会议期间进行选择,以便在下一次迭代期间实施. ...
极限编程（Extreme Programming）—重构
极限编程(Extreme Programming)-重构 march-bird lucian yjf taopin wl jazz韩伟 nullgate Simon[AKA](转载自cutter.co ...
什么是Extreme Programming
Extreme Programming(极限编程,简称XP)是由Kent Beck在1996年提出的.Kent Beck在九十年代初期与Ward Cunningham共事时,就一直共同探索着新的软件 ...
什么是XP，介绍XP,敏捷扫盲XP(Extreme Programming)。
一什么是XP?.XP是Extreme Programming的缩写,中文译为极限编程.极限编程是一种强调团队工作的工作方式,它是多种敏捷方式的一种. 二在XP中,常见的工程实践有: 1.测试驱动开 ...

极限编程（Extreme Programming）—走向极限

极限编程（Extreme Programming）—走向极限

极限编程（Extreme Programming）—走向极限相关推荐

最新文章

热门文章