第2章 极限编程概述

2.1极限编程实践
极限编程（eXtreme Programming,简称XP）是敏捷方法中最著名的一个。它由一系列简单却相互依赖的实践组成。这些实践结合在一起形成了一个胜于部分结合的整体。
2.1.1客户作为团队成员
我们希望客户和开发人员在一起紧密地工作，以便于彼此知晓对方所面临的问题，并共同去解决这些问题。
XP团队中的客户是指定义产品的特性并排列这些特性优先级的人或者团队。客户包括：和开发人员同属一家公司的一组业务分析师或者市场专家；用户代表；支付开发费用的人。
最好的情况是客户和开发人员在同一个房间中工作，次一点的情况是客户和开发人员之间的工作距离在100米以内。距离越大，客户就越难成为真正的团队成员。
2.1.2用户素材
为了进行项目计划，必须要知道和项目需求有关的内容，但是却无需知道得太多。对于做计划而言，了解需求只需要做到能够估算它的程度就足够了。你必须要知道存在很多细节，也必须要知道细节的大致分类，但是你不必知道特定的细节。
需求的特定细节很可能会随时间而改变，因此在离真正实现需求还很早时就去捕获该需求的特定细节，很可能会倒置做无用功以及对需求不成熟的关注。
在XP中，我们和客户反复讨论，以获取对于需求细节的理解，但是不去捕获那些细节。我们更原意客户在索引卡片上写下一些我们认可的词语。这些词语可以提醒我们记起这次交谈。基本上在和客户进行书写的同以时刻，开发人员在该卡片上写下对应于卡片上需求的估算。估算是基于和客户进行交谈期间所得到的对于细节的理解进行的。
用户故事就是正在进行的关于需求谈话的助记符。它是一个计划工具，客户可以使用它并根据它的优先级和估算代价来安排实现该需求的时间。
2.1.3 短交付周期
XP项目每两周交付一次可以工作的软件。每两周的迭代都实现了客户的一些需求。在每次迭代结束时，会给客户演示迭代生成的系统，以得到他们的反馈。
1.迭代计划
每次迭代通常耗时两周。这是一次较小的交付，可能会被加入到产品中，也可能不会，它由客户根据开发人员确定的预算而选择的一些用户故事组成。
开发人员通过度量在以前的迭代中所完成的工作量来为本次迭代设定预算。只要估算成本的总量不超过预算，客户就可以为本次迭代选择任意数量的用户故事。
一旦迭代开始，客户就统一不再修改档次迭代中用户故事的定义和优先级别。迭代期间，开发人员自由的将用户故事分解成task，并一句最具技术和商务意义的顺序来开发这些task。
2.发布计划
XP团队通常会创建一个计划来规划随后大约6次迭代的内容，这就是所谓的发布计划。一次发布通常需要3个月的工作。它表示了一次较大的交付，通常此次交付会被加入到产品中。发布计划是由一组客户根据开发人员给出的预算所选择的、牌号优先级别的用户素材组成。
发布计划不是一成不变的，客户可以随时改变计划的内容。
2.1.4验收测试
可以以客户指定的Acceptance Tests的形式来捕获有关用户素材的细节。用户素材的验收测试是在就要实现该用户故事之前或者实现该用户故事的同时进行编写的。
验收测试使用能够让它们自动并且反复运行的某种脚本语言编写，这些测试共同来验证系统按照客户指定的行为运转。
一旦通过一项验收测试，就将该测试加入到已经通过的验收测试集合中，并决不允许该测试再次失败。这个不断增长的验收测试计划每天会被多次运行，每次系统被创建时，都要运行这个验收测试集。
所有的产品代码都是由结对的程序员使用同一台多年共同完成的。结对人员中的一个控制键盘并输入代码，另一位观察输入的代码并寻找着代码中的错误和可以改进的地方。
两个人频繁互换角色，最终生成的代码是由他们两人共同设计，共同编写的。
结对的关系每天至少要改变一次，以便于每个程序员在一天中可以在两个不同的结对中工作。在一次迭代期间，每个团队成员应该和所有其他的团队成员在一起工作过，并且他们应该参与了本次迭代中所涉及的每项工作。
这将极大地促进知识在团队中的传播。
2.1.6测试驱动的开发方法
2.1.7集体所有权
2.1.8持续集成
2.1.9可持续的开发速度
XP的规则是不允许团队加班工作。在版本发布前的一个星期是该规则的唯一例外。
2.1.10开放的工作空间
2.1.11计划游戏
planning game 的本质是划分业务人员和开发人员之间的职责。业务人员（客户）决定特性的重要性，开发人员决定实现一个特性所花费的代价。
2.1.12简单的设计
XP团队使他们的设计尽可能地简单，具有表现力。此外，他们仅仅关注了计划在本次迭代中要完成的用户故事。
这意味着XP团队的工作可能不会从基础结构开始，他们可能并不先去选择使用数据库或者中间件。团队最开始的工作是以尽可能最简单的方法实现第一批用户故事。只有当出现一个用户故事迫切需要基础结构时，他们才会引入该基础结构。
下面有三条XP指导原则：
1.考虑能够工作的最简单的事情
XP团队总是尽可能寻找能实现当前用户故事的最简单的设计。
2.你将不需要它
3.一次，并且只有一次
极限编程者不能容忍重复的代码。无论在哪里发现重复的代码，他们都会消除它们。
2.1.13重构
代码往往会腐化，随着我们添加一个又一个的特性，处理一个又一个的错误，代码的结构会逐渐退化。
重构就是在不改变代码行为的前提下，对其进行一系列小的改造，旨在改进系统结构的实践活动。
重构是持续进行的。
2.1.14隐喻
没有理解这段文字