解析极限编程：拥抱变化

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

　　贝克，拥有经营着First Class Software ，Inc.，在他的公司里他把注意力集中在他的两大兴趣上：模式和极限编程。他对软件开发的一些先驱模式、CRC卡、HotDraw 绘画编辑器框架、xUnix单元测试框架和重新发现“测试先行”的编程做出了贡献。

第一部分  问题  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