解析极限编程——拥抱变化 (2008 年度畅销榜NO.723 )

极限编程（XP）是一种经历过实践考验的轻量级软件开发方法学，本书是XP宣言，也是第一本有关XP的图书。
本书共分三部分，第1部分包括第1章至第9章，通过讨论创建新的软件开发规范中要解决的问题的不同层面来设定极限编程的前提。第2部分包括第10章至第18章，内容着重于如何将第一部分中的抽象概念转化为具体方法论的实践，这部分不会确切地说明如何执行这些实践，而是要讨论它们的大体结构，同时提供了一套指导性的准则和策略。第3部分包括第19章至第27章，该部分讨论了如何将上一部分中的策略确切地付诸实践。
本书语言轻松活泼，实用性与可读性较强，适合于软件开发人员、软件项目管理人员，以及所有想要了解XP背后思想的各界人士参考。

第一部分 问题 1

第1章 风险：基本的问题 3
软件开发不能按时交付，也就不能创造价值。这不仅会造成经济损失，而且对当事人本身也有很大的影响。我们需要找到一种新的方法来开发软件。
第2章 开发情节 7
日复一日的编程从与客户要求的特性明确相关的任务开始，然后测试、实现、设计，最后到集成。软件开发中每个活动的细节都包含在各个情节中。
第3章 软件开发的经济学 11
从经济上考虑，为了使软件开发更有价值，我们需要减缓开销，加快收益并增加项目的可能的高效生产期。但最重要的是我们需要增加用于业务决策的选项。
第4章 四个变量 15
我们将控制项目中的四个变量-成本、时间、质量和范围。其中，范围的控制最有价值的。
第5章 变化的成本 21
在某些情况下，更改软件引起的成本以指数方式上升的趋势会随时间的推移而趋于缓和。如果可以使曲线变得平滑，那么以前对有关开发软件的最佳方式的假定将不再成立。
第6章 学会开车 27
我们需要通过做许多小的调整（而不是几次大的调整）来控制软件的开发，这有点象开车。也就是说我们需要反馈来知道我们何时出现了错误，我们需要很多机会来纠正这些错误，而且，我们必须能够以比较合理的成本完成这样的纠正。
第7章 四个准则 29
当我们形成一种风格，能够体现出“沟通”、“简单”、“反馈”和“勇气”这样一整套协调的既能为人们所用，又能满足商业需要的准则的时候，我们就成功了。
第8章 基本原则 37
我们可以从这四个准则衍生出许多基本原则来规范我们的新风格。我们将检查提出的开发实践以查看它们是否符合这些原则。
第9章 回到基本问题 45
我们希望能够竭尽全力做到稳定。可预测的软件开发。但是我们没有时间去做任何额外的事情。开发软件的四项基本工作是：编码，测试，倾听和设计。

第二部分 解决方案 53

第10章 简短概述 55
我们将依靠简单实践（就是那些几十年前常常被视为不切实际或天真而遭摒弃的实践）之间的协作。
第11章 这如何奏效 67
实践互相支持。一种实践的弱点可以由其他实践的优点来弥补。
第12章 管理策略 77
我们使用商业基本要素全面地管理项目，这些要素包括：分阶段交付，进行迅速和具体的反馈，清晰地阐述系统的业务要求和为特殊任务配备专家。
第13章 设备策略 83
我们将为团队创建一个开放的工作空间，外围是小的私人空间，中间是公共编程区。
第14章 拆分业务责任和技术责任 87
我们的策略的一个关键点是让技术人员把精力集中在技术问题上，让业务人员把精力集中在业务问题上。项目必须由业务决策来驱动，而技术决策则要给业务决策提供有关成本和风险的信息。
第15章 计划策略 93
我们制订计划的方法是：迅速制订一个总体计划，然后在越来越短的时间范围内-年、月、周和日-逐步深入地将其完善。我们将迅速并低成本地制订计划，这样当我们必须改动它的时候也不会受到惰性影响。
第16章 开发策略 105
与管理策略不同，开发策略从根本上背离了传统的观念--我们会认真制订今天的问题的解决方案，并相信我们能够在明天解决明天的问题。
第17章 设计策略 111
从一个非常简单的起点出发，我们将继续完善系统的设计。我们将去掉任何不能证明是有用的灵活性。
第18章 测试策略 123
我们总是在编码前编写测试。我们将一直保留这些测试，并频繁的运行全部测试。我们还会根据客户的观点生成测试。

第三部分 实现XP 129

第19章 采用XP 131
一次一种实践地采用XP，始终处理对团队最紧要的问题。一旦这个问题不再是最紧要的，就接着转向下一个问题。
第20章 改进XP 133
希望改变其现有文化的项目远比能从头创造新文化的项目更常见。从测试或计划开始，在现有项目上每次进行一点点来逐渐采用XP。
第21章 理想的XP项目的生命期 139
理想的XP项目要经历一个短暂的初期开发阶段，随后是多年同时进行的生产支持和优化，最后，当项目失去意义时体面地退休。
第22章 人员的角色 147
我要使极限团队运转起来，就必须有人充当特定的角色--程序员、客户、教练、跟踪者。
第23章 20-80原则 157
XP的最大功效只有在采用了所有实践时才能发挥出来。许多实践可以逐个采用，但如果能同时采用它们，它们的效果就会倍增。
第24章 使XP难以执行的原因 159
即使蓝领程序员也能够执行单个的实践，但是要把所有的实践组合在一起并保持它们的统一很不容易。使XP难以执行的原因主要是人的情感-尤其是恐惧心理。
第25章 什么时候不应使用XP 163
XP的确切局限尚不清楚。但是有一些因素能阻止XP奏效-团队太大，客户多疑以及技术不能很好地支持更改。
第26章 工作中的XP 167
XP可以适应常见形式的合同（虽然稍微有些改动）。特别地，利用计划游戏，固定价格／固定范围的合同会成为固定价格／固定日期／大致固定范围的合同。
第27章 结论 173

参考书目与附注 177
词汇表 191

关于本书 这本书讲的是 XP 背后的思想-它的根源、哲学、情节以及神话。它旨在帮助你在选择是否在项目中使用 XP 时做出明智的决策。如果你读了本书后正确地决定不把 XP 用于你的项目，或者你正确地决定使用它，我同样达到了我的目的。本书的第二个目的是帮助那些已经在使用 XP 的读者更好地理解它。 这不是一本关于如何精确地进行“极限编程”的书。你不会在本书中见到大量检查清单或看到许多示例，也不会看到大量编程理论。要获得那些内容，你必须上网，与这里提到的一些教练进行谈话，等待那些主题性和指导书性质的书出版，或者你也可以做出自己的版本来。 现在，接受 XP 的下一个场合掌握在一群对软件开发的现状不满意的人手中（你可能就是其中一个）。你需要更好的软件开发方法，你需要更好地处理与客户的关系，你需要更快乐。更可靠。更多产的程序员。简而言之，你在寻求巨大的回报，而且为了获得它们你不惧怕尝试新的理念。而且，如果你准备冒险的话，你希望能确信不是因为愚蠢才这么做的。 XP 让你以不同的方式工作。有时 XP 的建议与公认的明智做法完全相反。这里我希望那些选择使用 XP 的人在得到令人信服的理由以后再以不同方式工作，不过要是已经有了理由的话，就不要再犹豫了。我写这本书就是为了向你说明这些理由。 什么是 XP？ 什么是 XP？ XP 是一种轻量、高效、低风险、柔性、可预测、科学而且充满乐趣的软件开发方式。它与其他方法论的不同之处在于： * 它的短周期内的早期。具体和持续的反馈。 * 它递增地进行计划编制，这种方法迅速提供一个总体计划，然后在项目的整个生命周期内不断发展它。 * 它针对不断变化的业务需求灵活地对功能的实现进行计划的能力。 * 它依赖于由程序员或客户编写的自动测试来监控开发进度，使得系统得以发展并及早捕获缺陷。 * 它依赖于口头交流、测试和源代码来沟通系统的结构和意图。 * 它依赖于在整个系统存在期间一直持续的进化式设计过程。 * 它依赖于技术水平一般的程序员之间的紧密协作。 * 它依赖于能同时满足程序员的短期本能和项目的长期利益的实践。 XP 是一种软件开发规则，说它是一种规则是因为有些东西是 XP 中必须做的。你不需要选择是否编写测试--如果你不这样做，那么你就不是极限的：不讨论了。 XP 旨在用于可以由二至十名程序员组成的团队开发的项目，这样的项目不能为现有的计算环境所束缚，而且要能够用一天中的少量时间完成合理的测试执行任务。 某些人在第一次接触 XP 时，会感到吃惊或愤怒。不管怎么说，XP 中没有一样概念是新的。大多数概念和编程一样老。某种程度上 XP 是保守的--它的所有技术都是经过数十年（对于实现策略）或数百年（对于管理策略）验证的。 XP 的创新之处在于： * 把所有这些实践结合在一起。 * 确保尽可能彻底地执行它们。 * 确保这些实践能在最大可能程度上互相支持。 够了 在《The Forest People and The Mounted People》中，人类学家 Colin Turnbull 描绘了两个社会的明显反差。在山区，资源稀缺，人们总是处于饥饿的边缘。由此形成的文明是非常可怕的。一旦小孩有了任何幸存的机会，母亲们就丢弃他们，让他们与野生的孩子一起流浪。暴力。残忍和背叛是社会的公理。 相反，森林中有丰富的资源。一个人每天只需花费半个小时就能满足自己的基本需要。森林文化是山区文化的反面。成年人共同养育孩子，在孩子们能完全照顾自己之前，他们一直受到养护如果一个人不小心杀死了另外一个人（蓄谋犯罪的概念还没有），他会被放逐，但也只是走到附近的森林中，并且只是几个月的时间，即使在这种情况下，其他部落的人也会给他食物。 XP 可以作为一个回答“如果你有足够的时间，你将如何编程”这个问题的试验。但是，你不可能有额外的时间。因为这毕竟是商业，而无疑我们都想成功。但是如果你有足够的时间，你会编写测试，你会在学到一些东西后重新构建系统的结构，你会与程序员同事或客户进行大量讨论。 与那种强加了不可能的期限的。无情而让人难以忍受的苦差事不同，这样的“富足心理”是符合人性的。富足心理是一件好事。 它创造出了它特有的效率，正如匮乏心理会造成特有的浪费。 摘要 这本书的写作方式就像是你和我在一起创造一种新的软件开发方法。 我们从审视我们关于软件开发的基本假设开始。然后我们创造方法本身。 最后我们审视我们所创造的方法的影响--如何采用它。何时不应采用它以及它能为业务创造什么样的机会。 本书分为三个部分。 * “问题”--从“风险： 基本问题”到“回到基本问题”这些章节提出了“极限编程”试图解决的问题，并提出用来评估解决方案的标准。 这部分将给你一个“极限编程”的总体概念。 * “解决方案”--从“简短概述”到“测试策略”这些章节将第一部分中的抽象概念转化为具体方法论的实践。 这部分不会确切地说明如何执行这些实践，而是要讨论它们的大体结构。 每种实践的讨论都将实践与在第一部分中介绍的问题和法则联系起来。 * 实现 XP-从“采用 XP”到“使用 XP”的章节描述了围绕如何实现 XP 的各种主题--如何采用它。极限项目中对各种各样的人的期望。业务方面的人士是如何看待 XP 的。 鸣谢 我是写这本书的第一个人，不是因为这是我的观点，而是因为这是我对这些观点的看法。 XP 中的大多数实践和编程一样老。 Ward Cunningham 是你在本书中读到的许多内容的直接来源。 从很多意义上看来，过去的十五年我做的唯一一件事情就是试图向其他人解释他是如何顺应自然地工作的。 感谢 Ron Jeffries 的尝试，他使它更加完美。 感谢 Martin Fowler 以平近易懂的方式解释它。 感谢 Erich Gamma 在观看 Limmat 的天鹅时与我长谈，使我免于思维混乱。 而如果我没有从我的父亲 Doug Beck 那里学习，并在这些年里一直使用他的编程技术，那么所有这一切将不会发生。 感谢 Chrysler 的 C3 团队坚持跟随我，然后超越我而走向成功。 特别感谢我们的经理 Sue Unger 和 Ron Savage 的勇气，给予我们试验的机会。 感谢 Daedalos Consulting 支持本书的写作。 校阅冠军的荣誉属于 Paul Chisholm，他是靠着大量见解独到而通常又率直尖刻的评论获得桂冠的。如果没有他的反馈，本书不会取得它今天一半的成绩。 我从与所有校阅者的交流中得到了很多乐趣。至少我从他们那儿得到了极大的帮助。我无法完全表达我对他们认真审阅我文章的 1.0 版的谢意，其中一些是用另外一种语言写的。感谢（按我读到他们的评论的随机顺序排列）Greg Hutchinson、Massimo Arnoldi、Dave Cleal、Sames Schuster、Don Wells、Joshua Kerievsky、Thorsten Dittmar、Moritz Reeker、Daniel Gubler、Christoph Henrici、Thomas Zang、Dierk Koenig、Miroslav Novak、Rodney Ryan、Frank Westphal、Paul Trunz、Steve Hayes、Kevin Bradtke、Jeanine De Guzman、Tom cubit、Falk Bruegmann、Hasko Heinecke、Peter Merel、Rob Mee、Pete McBreen、Thomas Ernst、Guido Haechler、Dieter Holz、Martin Knecht、Dierk Konig、Dirk Krampe、Patrick Lisser、Elisabeth Maier、Thomas Mancini、Alexio Moreno、Rolf Pfenninger和Matthias Ressel。