《解析极限编程》读书笔记

解析极限编程

Extreme Programming explained: EMBRACE CHANGE

Kent Beck

 

屋檐下的水滴-- 读书笔记系列

http://blog.csdn.net/dwater

 

第1部分 问题

第1章 风险：基本问题

软件开发不能按时交付，也就不能创造价值。这不仅会造成经济损失，而且对当事人本身也有很大影响。我们需要找到一种新的方法来开发软件。

软件开发的基本问题是风险，包括进度延迟、项目取消、系统恶化、缺陷率、业务误解、业务变更、错误特性多、人员调整。

XP是一种在软件开发过程中处理各个级别上风险的软件开发方法。它生产效率高，可以产生高质量的软件，而且在执行过程中有很多乐趣。

第2章 开发情节

日复一日的编程从与客户要求的特性明确相关的任务开始，然后是测试、实现、设计，最后到集成。软件开发中的每个活动的细节都包含在各个情节中。

第3章 软件开发的经济学

从经济上考虑，为了使软件开发更有价值，我们需要减少开销，加快收益并增加项目可能的高效生产期。但最重要的是，我们需要增加用于业务决策的选择。

使用以下三个因子，我们可以创建一个能够使项目经济价值最大化的策略：出入的现金流、利率、项目失败率。对此，我们需要做到：减小开销、增加收益、推迟开销并提早收益、提高项目的存活率。

软件项目管理可以看成具有四种选择：放弃、转换、延期、增长。

对于选择的价值，其计算两分是艺术，五分是数学，一分是有效的老式Kentucky偏差修正。其中涉及到五个因子：获得选择所需的投资量、实行选择赢得收获所需的代价、收获的现值、实行选择的时间量、收获的最终价值的不确定性。其中选择的价值通常由最后一个因子来支配，无论不确定性是来自技术风险、变化的业务环境，还是快速变化的需求，不确定性越大，策略的价值就越高。

什么时候使用XP？理论上的答案是：在需求比较模糊或需求不断变化时。

第4章 四个变量

我们将控制项目中的四个变量：成本、时间、质量、范围。其中，范围的控制最有价值。

这里有个从控制变量系统的角度建立的软件开发模型，在该模型中，软件开发过程中有四个变量：成本、时间、质量、范围，软件开发的游戏规则是让外力（客户、管理）人员确定三个变量的值，而开发人员确定第四个变量的值。

对于软件开发来说，范围是应该注意的最重要的变量。在项目管理中，最有力的决定之一是消除范围。如果积极主动的管理范围，你就可以向管理人员和客户提供成本、时间和质量的控制。

范围的一个重要特点就是它是一个变化很大的变量。在开始的时候，需求从来都是不清楚的，客户从来不能确切地告诉你他们需要什么。软件的开发会改变软件本身的需求。如果我们把需求的这种柔性看作是一个机会，而不是一个问题，我们就可以将范围当作四个变量中最容易控制的。通过不去试图完成太多的功能，我们就可以保持能力按时实现满足所需质量的产品。

如果我们根据这一模型创建一种开发规则，就可以使软件的日期、质量、成本先固定下来，然后看看这三个变量所揭示的范围，接着我们便可在开发过程中通过不断调整范围来适应遇到的情况。由于项目经常改变方向，这必须是一个能够很容易地包含变化的过程。

为了避免在发行周期结束时遗漏重要的功能，XP使用了两个策略：

1．  大量估算和反馈实际结果。

2．  首先实现客户最重要的需求。

第5章 变化的成本

在某些情况下，更改软件引起的成本以指数方式上升的趋势会随时间的推移而趋于缓和。如果可以使曲线变得平滑，那么以前对软件开发最佳方式的假设将不再成立。

变化的成本可能不会随时间的推移而急剧上升，而是最终成为渐近线，这是XP的前提之一，也是XP的技术前提。你将尽量推迟做出重大决定，从而推迟支付作决定的成本，并使得做出正确决定的可能性最大；你将仅实现你必须实现的部分，而寄希望于预期的需求不会成为现实；你将仅在元素简化了现有代码或者使编写后面的代码更简单时，才将它们引入设计。

如果变化的花费一直很少，那么附加值和通过早期的具体反馈而减少的风险将在价值上超过早期成本引起的附加成本。

保持变化成本低廉不是变魔术。在技术方面，对象是一项关键技术。简单设计、自动测试、不断改良设计的态度，能决定代码是否易于修改。

第6章 学会开车

我们需要通过做许多小的调整而不是几次大的调整来控制软件的开发，这有点像开车。也就是说我们需要反馈来知道我们何时出现了错误，我们需要很多机会来纠正这些错误，而且，我们必须能够以比较合理的成本来完成这样的纠正。

即时工作看上去很顺利，也不要把视线从公路上移开。只有变化是不变的。时刻准备着这样调整一点，那样调整一点。有时你可能不得不朝完全不同的方向前进。这就是一个程序员的生活。

软件中的所有东西都在变。需求变化、设计变化、业务变化、技术变化、团队变化、成员变化。问题不在于变化，因为变化总是要发生，问题实际上是在发生变化时有没有能力应对。

第7章 四个准则

当我们形成一种风格，能够体现出沟通、简单、反馈和勇气这样一整套协调的、既能为人们所用、又能满足商业需要的准则的时候，我们就成功了。

项目中的问题无一例外总是出自那些不愿与别人探讨重要问题的家伙。XP旨在采用许多只能通过沟通完成的实践来保持良好的沟通。这是些短期内有意义的实践，比如单元测试、结对编程、任务估算，其作用就是让程序员、客户和管理人员必须进行沟通。XP雇佣一位教练，他的工作就是观察大家什么时候没有进行沟通，然后提醒大家。

XP在打赌。它赌今天做的简单些然后需要时在明天花些功夫进行改进，要比今天做得很复杂而以后再也用不到要好得多。简单和沟通之间有一种奇妙的相互支持的关系。沟通得越多，就越清楚哪些工作需要做，哪些工作不需要做。系统越简单，需要的沟通就越少。

对系统当前状态的具体反馈是极为宝贵的。乐观是编程行业的大忌，而反馈则是良药。在分钟和日的级别里进行的反馈有单元测试、故事估算、进度反馈。在周和月级别进行的反馈有功能测试、开发速度、生产发布。具体的反馈与沟通和简单可以搭配工作。

让系统变得简单，就要作出更改，甚至是大的更改，这需要勇气。沟通、简单、反馈都支持勇气，勇气也支持简单。

另外一个更深刻的准则——尊重，它隐藏在四个准则的表面之下。开发小组的成员需要互相关心，并乐于成为一个有效团体中的一员。

第8章 基本原则

我们可以从这四个准则衍生出许多基本原则来规范我们的新风格。我们将使用开发实践来查看他们是否符合这些原则。

沟通、简单、反馈、勇气这四个准则提供了成功解决方案的标准，但对于确定使用何种实践来说，这些准则太模糊。我们需要提炼这些准则，得出可以使用的具体原则。

下面是一些基本原则：

快速反馈、假设简单性、递增更改、提倡更改、优质工作。

下面是一些不太重要的原则：

教授知识、小的初始投资、积极求胜、具体试验、开诚布公的沟通、顺着人类的本能工作、接受的责任、本地调整、轻装上阵、诚实的度量。

2004-1-11

第9章 回到基本问题

我们希望更够竭尽全力做到稳定、可预测的软件开发。但是我们没有时间去做任何额外的事情。软件开发的四项基本工作是：编码、测试、倾听和设计。

一个系统要生存就必须保留源代码。代码给你的最重要的东西是学习以及进行简洁明了的交流机会。编码时，还有机会去理解代码的最佳结构。代码可用来沟通，还可用于表示测试。

测试提供了一个机会，使你可以不考虑如何实现，只考虑你想要什么，然后，测试会告诉你是否实现了你认为你实现了的东西。测试告诉你何时完成了编码：当测试能够运行时，编码工作就暂时完成了；当你想不出其他可能出错的测试时，编码就全部完成了。

测试是一种资源又是一种职责，你有责任编写你能想到的每一个不能立即运行的测试。把测试当作基本工作的长期理由是测试可以是程序的生存时间更长，短期理由是它给编程工作增添许多乐趣，而且编码时你会更有自信。

编程和测试相结合比只编程快，因为做测试能够节省调试的时间。做得很差的测试很危险。测试的窍门是找出所能容忍的缺陷的级别。我们使用两套测试，一套是程序员编写的单元测试，另一套是客户编写（至少是客户指定）的功能测试。

程序员必须倾听客户讲述业务上的问题，帮助客户理解什么容易做，什么难做。程序员提供的反馈能够帮助客户更好地理解他们的业务问题。

设计就是创建组织系统中的逻辑的结构。

好的设计能够这样组织逻辑：对系统中某处的更改不会总是需要对其它地方也进行更改；确保系统中的每一部分逻辑有且只有一个“家”；将逻辑放在它所操作的数据附近；能够只对一个部分进行更改而扩展系统。

糟糕的设计正好相反。复杂性时糟糕设计的另一个来源，如果一个设计需要间接的四个层次才能弄明白要做什么，而且这些层次没有任何特别的功能性或解释性的作用，那么这种设计就是糟糕的。

                                                                2004-01-12

第2部分 解决方案

第10章 简短概述

我们将依靠简单实践（那些几十年前常常被视为不切实际或天真而遭摒弃的实践）之间的协作。

下面是所有的实践：

计划游戏	通过结合使用业务优先级和技术评估来快速确定下一个版本的范围。当计划赶不上实际变化时就应更新计划。 业务人员决定的内容有：范围、优先级、版本组成、发布日期。 技术人员决定的内容有：估算、后果、过程、详细的日程计划。
小版本	将一个简单系统迅速投产，然后以很短的周期发布新版本。 每个版本应该尽可能小而完整，必须是有意义的，包含最有价值的业务需求。 每次计划一两个月远好过每次计划六个月或一年。尽可能缩短周期。
隐喻	用有关整个系统如何运行的简单的、众所周知的故事来指导所有开发。 每个XP项目都由一个全面的隐喻指导，它帮助项目中的每个人理解基本元素及其关系。XP中的隐喻在很大程度上取代了别人所说的“体系结构”。体系结构的目的是向每个人提供一个进行工作的连贯情节，为业务人员和技术人员所周知的情节。通过引入隐喻，我们可以得到易于沟通和阐述的体系结构。
简单设计	任何时候都应该将系统设计得尽量简单，不必要的复杂性一旦发现就马上去掉。任何时候，正确的软件设计都具有下列特征： 1．  能够运行全部测试； 2．  没有重复逻辑； 3．  陈述每个对程序员重要的意图； 4．  有尽可能少的类别和方法。 在需要时再添加你需要的东西。
测试	程序员不断地编写单元测试，在这些测试能够无误运行的情况下，开发才可以继续。客户编写测试来证明功能已经完成。 程序员和客户对程序的信心将成为程序的一部分。随着时间的推进，程序变得越来越可靠，接受变化的能力越来越强。 没有必要为所编写的方法都编写测试，只对可能出错的方法编写测试。
重构	程序员重新构造系统（但不更改其行为）以去除重复、改善沟通、简化或提高柔性。不要根据猜测进行重构，应在系统要求时再那么做。当系统要求你复制代码时，它便是在要求重构。
结对编程	全部生产代码都是由两个程序员在同一台计算机上，用同一个键盘、同一个鼠标编写的。每一对成员中有两种角色。driver应思考实现此方法的最佳途径，另一个则更加偏重于从略性的角度进行思考。配对是动态的。
集体所有权	任何人在任何时候可以在系统的任何位置更改任何代码。 无人所有权 ----〉 个人所有权 ----〉 集体所有权
持续集成	每天多次集成和生成系统，每次都完成一项任务。 几小时最多一天的开发后对代码进行集成和测试。一个简单的方法，就是使用一台计算机专门做集成工作。
每周工作40小时	一般情况下，一周工作不超过40小时。不要连续两个星期加班。 加班是项目存在严重问题的征兆。
现场客户	在团队中加入一位真正的、起作用的用户，他将全面负责回答问题。
编码标准	程序员依照通过代码进行沟通的规则来编写所有代码。 标准应提倡可能的最小工作量，应强调沟通，必须被整个团队自愿地采纳。

2004-1-22

第11章 这如何凑效

实践相互支持。一种实践的弱点可由其他实践的优点来弥补。

这里的实践，每一个都是从编写程序的时候就开始被使用，其中的大多数已经由于它们的弱点日渐明显而被抛弃。变化的成本指数曲线的崩溃，使得所有这些实践得以重拾往日的风光。每种实践仍旧有以前的弱点，但是这些弱点可以用其它实践的优点来弥补。

第12章 管理策略

我们使用上也基本要素全面地管理项目，这些要素包括：分阶段交付，进行迅速和具体的反馈，清晰地阐述系统的业务需求，以及为特殊任务配备专家。

管理上的两难之处：一方面无法让管理人员做出所有决策，另一方面又不能让每个人随心所欲，在没有监督的情况下干自己想干的事情。以下是帮助我们在这二者之间权衡的原则：

接受职责：管理人员的任务是强调需要做的事情，而不是布置工作。

优质工作：管理人员和程序员要相互信任，因为后者希望做出优秀的工作。

递增更改：管理人员自始至终提供指导，而不是在开始时拿出厚厚的指导手册。

本地适应：管理人员要带头讲XP应用到具体情况，了解其与公司文化的冲突并寻求解决。

轻装上阵：管理人员不应强加太多系统开销，要求程序员做的任何事情不应花费很多时间。

诚实度量：管理人员无论是用何种度量标准，它必须在实际精确度的水平上。

以上原则得出的策略更像是分布式决策而不是集中控制。管理人员的任务是：运行计划游戏，进行度量，确保相关人员了解度量工作的标准，在偶尔无法分布式解决的时候实施干预。

度量、指导、跟踪、干预：

XP的基本管理工具是度量（metric），度量的方法是大的可视图表。管理人员周期性更新一个显眼的图表，通常这就是所需的全部干涉。不要使用太多度量，通常一个团队同时最多只能忍受三到四种度量。准备好撤掉那些已经达到目的的度量。

XP中的管理者分为教练和跟踪者两个角色，可能也可能不由同一个人扮演。

教练主要关心过程中的技术执行和改进部分，理想的教练是一个好的沟通者，不易恐慌，技术过硬，很自信。衡量一个教练的标准是其做出了多么少的技术决策，其任务是让所有其他人做出正确的决策。教练不会负责许多开发任务，相反，其工作职责为：

充当开发伙伴，特别是对于那些刚开始承担责任的新程序员或者困难的技术任务来说。

明确长期的重构目标，鼓励以小规模的重构来实现目标的一部分。

用个人技术技巧帮助程序员。

向上层管理人员解释过程。

最重要的工作可能是采购玩具和食物，以期对开发产生良好的影响。

跟踪者的任务是搜集某个时刻所有正在跟踪的测量数据，确保团队知道实际度量的是什么，以及所预期的是什么。跟踪不应造成大量系统开销，两周进行一次实际开发数据的搜集足以。运行计划游戏是跟踪的一部分。

干预是走到团队面前说：我不知道我是怎么把项目弄成现在这个样子，但是我现在必须怎样怎样......谦卑是干预时要遵循的规则。

                                                                    2004-01-27

第13章 设备策略

我们将为团队创建一个开放的工作空间，外围是小的私人空间，中间是公共编程区。

第14章 拆分业务责任和技术责任

关键是让技术人员把精力集中在技术问题上，让业务人员把精力集中在业务问题上。项目必须由业务决策来驱动，而技术决策则要给业务决策提供有关成本和风险的信息。

业务方和开发方任意一方得到的权力过大，项目都会受到损害。业务人员应该做适合他们来做的决策，程序员应该做适合他们来做的决策。任何一方的决定都应通知另一方，任何一方都不能单方面作任何决定。

业务人员应该选择：发布的范围或者时间；提出的功能的相对优先级；提出的功能的确切范围。

开发人员必须确定：实现功能所需的时间估算；各种可选技术方案的后果估算；适合其个性、业务环境、公司文化的开发过程；使用哪组实践来开始以及使用什么样的进程来评审实践的效果和对变化进行试验。

第15章 计划策略

我们制定计划的方法是：迅速制定一个总体计划，然后在越来越短的时间范围内（年、月、周和日）逐步深入地将其完善。我们将迅速并低成本地制定计划，这样在我们必须改变它的时候也不会受到惰性影响。

制定计划的几个目的：团结和组织开发团队；决定范围和优先级；估算成本和日程；让大家对系统的成功信心百倍；为反馈提供一个基准。

制定计划的一些原则：只制定下一阶段所需的计划；接受的责任；负责实现的人进行估算；忽略各部分之间的依赖关系；

为优先级作计划与为开发作计划的比较，后者简单得多。

计划游戏：客户每隔三周对开发进行指导

最好的环境是业务方和开发方互相信任、互相尊重，这需要一套规则来支配——由谁来做决定，做哪些决定，何时做出决定，以及如何记录这些决定。

计划游戏旨在是让开发团队生产的软件的价值得到最大化。开发团队的策略是尽可能少地投入，并尽可能快地将最有价值的功能投入生产。计划游戏中的牌是故事卡。计划游戏中的两个玩家是开发方和业务方。游戏分为探索、承诺、指导三个阶段。

探索阶段找出系统最终完成什么功能，共分三步：业务方编写一个故事；开发方估算时间；对无法估算或某部分比其他部分更重要的故事进行分割。

承诺阶段旨在是让业务方选择下一版本的范围和日期，并让开发方有信息地做出交付承诺，共分四步：

1．  业务方将故事按价值分为三类——必须具备的、高商业价值的、有则更好的；

2．  开发方将故事按风险分为三类——可精确估算的、可合理估算的、完全无法估算的；

3．  设置速度，即开发方告诉业务方使用“理想工程时间”每个月能干多块；

4．  业务方选择范围，即根据工程结束日期、估算来选择卡片，或者选好卡片然后计算日期。

指导阶段旨在根据开发方和业务方掌握的情况来更新计划，共分四步：迭代、恢复、新故事、重新估算。

迭代计划：开发团队计划其活动

迭代计划游戏的牌是任务卡，玩家是所有单个的程序员，游戏在一到四周的迭代中完成，阶段和步骤类似。探索阶段编写任务、分割和组合任务；承诺阶段接受任务、估算任务、设置负载因子、平衡；指导阶段实现任务、记录进度、恢复、确认故事。

迭代计划和发布计划之间的主要差别在于前者的日程允许更多摇摆。

计划游戏和迭代游戏间的一个区别是后者程序员在估算之前就承担任务，另一个区别是后者中有些任务不直接与客户需要相关。

对于较小的项目，就不需要迭代计划了，但对于协调十个程序员的工作来说这是很有必要的。

                                                                     2004-02-09

第16章 开发策略

与管理策略不同，开发策略从根本上背离了传统的观念——我们会认真制定今天的解决方案，并相信我们能够在明天解决明天的问题。

开发策略从迭代计划开始，持续集成减少了开发冲突并为开发过程创造了一个自然而然的结尾，集体所有权鼓励整个团队改善整个系统，最后，结对编程将整个过程联系在一起。

                                                                  2004-02-10

第17章 设计策略

从一个非常简单的起点出发，我们将继续完善系统的设计。我们将去掉任何不能被证明是有用的灵活性。

XP的设计策略是永远使用能运行当前测试套件的最简单的设计，做法如下：

1．测试优先，这样便知何时完成。必须专门为编写测试来做设计：对象及其可见方法是什么？

2．设计并实现，只要使该测试运行即可。要使全部测试都能运行，你将不得不设计足够的实现。

3．重复。

4．一旦有机会可以使设计更简单，抓住机会去做。

面对大规模的重构，必须把它分解成较小的步骤来进行。你需要不断编写测试用例，此时你会发现有机会向大目标更进一步。抓住那个机会，这边改变一个方法，那边改变一个变量，最终这个大规模的重构就只是小事一桩了。

最佳设计：能运行所有测试用例的最简单的设计。按优先级排序，以下是“最简单”的含义：

1．  系统（代码、测试）必须能够沟通任何你希望沟通的内容。

2．  系统不能包含重复的代码。（与前一项构成“一次且只有一次”规则）

3．  系统拥有尽可能少的类。

4．  系统拥有尽可能少的方法。

系统设计的目的首先是沟通程序员的意图，其次是为系统的逻辑提供生存的地方。

今天的设计应该今天做，明天的设计留到明天做。

一方面，使用图形可以加快设计速度；另一方面，使用图形设计是在冒险，因为他们无法提供具体的反馈。我们的策略如下：

一次只画几幅图形；不应出于恐惧而使用图形；迅速弄清图形是否准确；鼓励那些善于使用图形的人使用图形；一旦图形对代码起到作用就不再保留。即少量的初始投资；积极求胜；快速反馈；顺应人的本能；拥抱变化和轻装上路。

在XP项目中，体系结构一部分是通过系统隐喻来概括的。计划游戏的规则规定第一次迭代必须能够产生一个系统的整体功能框架，但是你仍然必须做可能有效的最简单的事情。对于第一次迭代，选择一套简单的、基本的、你能够创建整个体系结构的故事，然后所小范围，用可能有效的最简单的方法实现故事，这个过程结束时，你便拥有了一个体系结构。

                                                                                                                       2004-02-12

第18章 测试策略

我们总是在编码前编写测试。我们将一直保留这些测试并频繁地运行全部测试。我们还会根据客户的观点生成测试。

应该编写有助于使程序能够运行并使程序能够一直运行的测试。在XP中，你编写的测试应该是独立的、自动化的。

在测试变得和代码一样复杂和易出错时，测试所有内容是不可能的，应该测试可能出错的部分。测试是一种赌博，当结果与预期相反时，测试就胜出了。多编写一些确实能够胜出的测试，少编写那些不会胜出的测试。

程序员和客户编写测试。程序员编写逐个方法地单元测试，客户逐个故事地编写功能测试。单元测试必须保证100%成功运行，而功能测试没有必要一直都100%运行。

XP团队不论大小都至少配有一名专职测试员，因为客户通常不会自己编写功能测试，他们需要有人将他们的测试数据翻译成真实、自动化和独立的测试。

以下情况，程序员编写单元测试：

1．    某个方法的接口不清楚；

2．    某个方法的接口很清楚，但你认为实现会稍微有点复杂；

3．    你想到代码不像被编写的那样工作的一种异常情况；

4．    你后来发现一个问题，那么应编写一个测试以隔离这个问题；

5．    你打算重构某些代码，但是不确定它应该有什么样的行为。

其他可能用得上的测试有：并行测试、压力测试、灵活测试。

                                                                  2004-02-10

第3部分 实现XP

第19章 采用XP

一次一种实践地采用XP，始终处理对团队最紧要的问题。一旦该问题不再是最紧要的，就接着转向下一个问题。

Don Wells关于如何采用XP的回答：

1．  挑出最棘手的问题。

2．  以XP方式解决它。

3．  当它不再最棘手的时候，重复以上步骤。

测试、计划游戏是两个明显的起始位置。采用XP时，不可轻视物质环境的重要性，记得布置家具、购买快餐食品。

第20章 改进XP

希望改变其现有文化的项目远比能从头创造新文化的项目更常见。从测试或计划开始，在现有项目上每次进行一点点来逐渐次采用XP。

要使现有团队将XP用于已经在生产中的软件，必须在测试、设计、计划、管理、开发这几个方面修改采用的策略：

测试：千万不要回头为现有代码编写测试，而应该只根据需要编写测试。在需要向未测试的代码添加功能时，首先为代码的现有功能编写测试。在需要修复错误、重构时，首先编写测试。

设计：过渡与测试相似。不要希望立刻改正一切，而应该每次只改正一点。添加新功能时，请首先准备重构。实现前始终要准备的重构，在向XP过渡时要比XP开发中更加频繁。

计划：必须将现有需求信息转变成故事卡片，必须教会客户游戏规则，客户必须决定下一个版本的内容。转换到XP计划的最大挑战和机会是让客户明白他们可以从团队中获得更多利益。

管理：让合适的人做合适的决定。注意在过渡期间提醒每个人他们所选择的规则。不断关注每天出现的情况，在出现“非极限”情况时，向后退一步。提醒团队规则、准则和原则，然后决定做什么。确定无法有效工作的团队成员，在无法改善时应该做出更改。

开发：第一件事情是将办公桌布置妥当，以便两个人可以并排坐下，并且无须移动椅子就可以来回移动键盘。对结对编成应该比通常所需的更加严格。一点一点地解决测试和设计问题。使所有处理过的代码遵循大家一致同意的编码标准。

                                                                                                         2003-11-02

第21章 理想XP项目的生命期

理想的XP项目要经历一个短暂的初期开发阶段，随后是多年同时进行的生产支持和优化，最后，在项目失去意义时体面地退休。

探索： 该阶段必须对使用的工具获取足够的信心，确信可以完成程序，且一旦代码完成就可以成天运行；确信自己拥有或者能够学会所需的技能；团队成员学会互相信任。 程序员需要使用在生产系统时将要使用到的每一项技术，并进行技术性能限度实验。对于一周时间都不能开始运行的技术，考虑替换的方法，因为太冒险。 程序员需要积极探索系统体系结构的各种可能性，花一两周的时间，使用三四种不同的方法，生成一个与目标系统相似的系统，并比较其中的差异。程序员还需要对有关体系结构的想法进行实验，在一天之内用三种不同的方法实现它，然后看哪种感觉最好。 程序员应该对每一项编程任务进行估算实践，从而提高估算能力和信心。 在此期间，客户在实践编写故事，保证程序员能够肯定地估算出完成故事所需的工作量。 阶段结束的标志：客户认为故事卡片上的材料足以构成第一个不错的版本；程序员认为不开始实际实现系统就无法更好地估算。 如果团队已经了解技术并彼此熟悉，探索阶段可以在几周之内完成；如果团队面对的是完全陌生的技术或领域，那么可能必须持续几个月的时间。                                                          2003-11-05

计划： 该阶段的目的：使客户和程序员能够有信心地就完成一套最小、最有价值故事的期限达成一致。 如果在探索期间做过准备，计划应该会用1~2天时间。第一个版本的时间应该在2~6个月之间。时间再短，可能无法解决任何重要的业务问题；时间再长，则太冒险了。

迭代： 将进度分为多个一到四周的迭代。 第一次迭代产生体系结构。因此，为该次迭代挑选这些故事，它们迫使你创建整个系统（即使只是个骨架）。而对于此后的迭代，将完全由客户挑选那些最有价值的故事。 迭代期间需要寻找与计划的偏差，并在检测到偏差时做出改动。比如添加或删除故事，更改范围，甚至是更改过程。 每次迭代，为计划内的每个故事产生一套功能测试用例。理想状况下，每次迭代结束时，客户已经完成所有功能测试并都能运行成功。记住来一次小小的庆祝。

生产： 在生产第一个版本时，反馈的周期要缩短，可能需要进行1周而不是3周的迭代，也可能需要每天一次的碰头会，让每个人知道其他人在做什么。 准备好实现新的测试，通常会有某个用于验证软件是否能够投产的过程。该阶段经常用到并行测试。可能还会需要调节系统的性能。 做一个显眼的列表，让所有人看到当前版本投产后团队的行进方向。 记住在软件实际投产后，举办一个大型聚会。

维护： 维护是XP项目真正的正常状态。在开发新功能的同时，保持现有系统运行，并处理好人员的变更。每个版本同样从探索阶段开始。 开发一个已在生产的系统与开发一个还没有进行生产的系统完全两样。准备好中断开发来应付生产问题。对改动需要更加谨慎，并小心的迁移既有数据。 进入生产状态后，可能会改变开发速度。在探索阶段测量一下生产支持对开发活动的影响。一定要让所有程序员轮流担当咨询人员。 无论如何，应该将不断开发的软件投产，即使明知软件的某些部分不能执行。任何情况下，不要让代码闲置超过一次迭代的时间。在完成一个版本时，最后要做的是集成一块不可能破坏任何东西的代码。 给新成员2~3个迭代的时间，他们的工作是大量提问，充当结对编程伙伴和阅读大量测试和代码。在他们感觉准备好了的时候，让他们负责一些编程任务，但负载因子要小些。在他们自己能够完成任务时，提高他们的负载因子。 如果团队的组成在逐渐变化，那么不到一年就可以用全新的人员替换原有的开发团队。

死亡： 死得其所与活得舒适同样重要。对人对XP，皆是如此。无论是客户想不出任何新故事，还是团队实在无法交付所需的软件，都是系统死亡的时侯。                                                           2003-11-10

第22章 人员的角色

要使极限团队运转起来，就必须有人充当特定的角色——程序员、客户、教练、跟踪者。

程序员可以是客户，但必须清楚在特定时刻他到底在扮演哪个角色，分离技术和业务决策。

程序员：XP的核心。 沟通、结对编程、简单设计、重构、单元测试、接受系统共享所有权、勇气。

客户：XP的另一个重要组成部分。 客户需要做出业务决策，需要编写故事，编写功能测试，需要证明自己的勇气。 最好的客户是那些将会实际使用系统，并对要解决的问题有一定认识的人。

测试员： 负责帮助客户选择并编写功能测试，经常运行所有的测试，传播测试结果，并确保测试工具运行正常。

跟踪者：团队的记录者 对团队、个人的估算进行反馈。 负责从整体上观察，在迭代进行到一半时，告诉团队是否需要作些调整；在几次迭代之后，告诉团队是否需要进行大改动已完成下一次迭代。 需要培养的技能主要是不打扰整个过程而收集信息，必要时稍稍介入，让人们意识到他们实际在任务上花费的时间。

教练：在整体上负责过程 在队员偏离过程时给予提醒，并让团队引以为戒。对XP有全面细致的理解。 不要太直接地讲出你所发现的问题，而要以能让团队也能发现问题的方式说明。

顾问： 在团队面临棘手事件时，教会他们如何解决问题。

大老板： 勇气、信心、偶尔坚持让团队实现自己的承诺。

2003-11-20

第23章 20-80原则

XP的最大功效只有在采用了全部实践时才能发挥出来。许多实践可以逐个采用，但如果能同时采用它们，效果就会倍增。

XP的20-80原则：将最有价值的20%的功能投入生产，完成最有价值的20%的设计。

XP依靠20-80原则来延期优化。作者认为实践和规则相互共同发生作用，从而产生一种大于部分总和的协同效应。并不是说不严格遵守这些实践就不能得到任何改进，而是说如果采用整个XP的话，你可以得到更多。

第24章 使XP难以执行的原因

即使是蓝领程序员，也能够执行单个的实践；但要把所有的实践组合在一起，并保持它们的统一，这就不是一件容易的事。使XP难以执行的主要原因是人的情感——尤其是恐惧心理。

XP在细节上很简单，但执行起来却很困难。学会XP的实践并不难，难的是组合所有实践，并保持它们之间的平衡。这些实践又相互支持的倾向，但是有很多问题、忧虑、恐惧、事件和错误都会使这个过程失去平衡。

作者认为XP中的比较棘手的事情：

学会用尽可能简单的方式观察世界既是一项技能，也是一项挑战。挑战是可能你不得不改变你的价值观，你必须学会对复杂不满，不停探索，直到想到最简单的方法。

保持谦逊，切勿不懂装懂。

合作。学习新的人际交往技巧，和队员密切的交流。

有效的沟通，顺利的表达感情。说出自己的想法，倾听别人的想法。

XP困难的原因正是——通过对自己的开发过程负责，你就承担了发现问题和解决问题的责任。

第25章 什么时候不应该使用XP

XP的确切局限还不清楚，但是有些因素会让XP难以奏效——团队太大，客户多疑，以及技术不能很好地支持更改。

不对不适用XP的使用XP，对适用XP的项目使用XP，两者同样重要。有些情况不适合使用：

1．  阻止XP项目成功的最大绊脚石是文化。其一是商业文化，其症状表现为企图“直线行驶”，其变体是复杂的规范，在开始编程之前要求完整的规范、分析或设计。劝客户或经理放弃那些让他们感到大权在握的文档！其二是那种要求你花费大量时间证明“对公司的承诺”的文化。你不能身心疲惫的执行XP。

2．  团队大小。五十个不行，二十个也不行。十个人是比较合理的，如果只有三、四个程序员，可以避开一些专门针对程序员协作的实践，比如迭代计划游戏。

3．  在规模缩放的过程中，最大的瓶颈是单线程集成过程。必须扩展单线程集成。

4．  你若使用固有成本曲线为指数型的技术，不应该使用XP。XP的基础是保持代码简单明了。

5．  另一个技术障碍是反馈时间很长的环境，一天内很难完成几次集成、构建和测试。

6．  物理环境必须合适。一个大房间，中间的桌子上放置功能强大的计算机，周围是小隔间，          这是最好的环境。噪音大，距离远，无法随时沟通，你会无法发挥XP的最大功效。程序员分散在两层楼上，或者在同一层楼但相距甚远，此时XP不适用。

                                                                     2003-12-15

第26章 工作中的XP

XP可以适应常见形式的合同（虽然稍有改动）。利用计划游戏，固定价格、固定范围的合同会成为固定价格、固定日起、大致固定范围的合同。

错误的合同形式可以轻易地破环一个项目，无论你有什么样的工具、技术和才干。必须使XP适应常见的商业实践。

典型的固定价格和范围的项目会把双方拉向相反的方向，供应商希望尽可能少干活，而客户希望尽可能得到更多。XP以一种微妙而重要的方式改变这种关系。初识范围是一个“例如”。“例如，用500万马克，我们认为可以在12个月内完成下面的故事”。客户有选择故事、替换故事的权利。

XP团队提供的更像是预定而不是固定价格、日期、范围，团队将在一定时期内以最快的速度为客户工作。他们将跟踪客户的学习过程。每次迭代开始，客户有一次正式的机会来改变方向和引进全新的故事。

XP引入的另一种不同由小版本引起，这会为反馈、变更、终止提供机会。

外包：outsourcing

在中典型的外包开发，客户会得到一堆他们不知道该如何维护的代码，他们有3种选择：

自己将系统进一步演化成一个爬虫（crawl）；

雇用原始供应商继续改进系统；

雇用不太了解哪些代码的另一个供应商。

外包的一次性交付违反了递增变化原则，用XP做这件事：团队与客户住在一起，他们将完成“计划游戏”来决定该做什么，合同完成后将代码留给客户。客户可进行单元测试、功能测试，还可以监督程序员的工作以便了解系统。

内包：insourcing

逐渐用客户的技术人员替换团队的成员。XP通过不断地测试速度来支持内包。牺牲了速度，但降低了风险。

时间和材料：在该合同中，XP团队按小时或天计费。供应商和客户需要保持良好的关系。

完工奖金：在与XP一起使用完工奖金和罚款条款时需要注意，计划游戏会不可避免地导致项目范围的更改。如果你担心客户坚持要在与原始任务条款一致时才付奖金，那么别签这样的合同。

及早终止：XP的特性之一是在项目进行过程中，客户可确切地看到他们将要得到的东西。任何时候，客户如果发现项目失去意义，他们能够及时终止项目。考虑添加一个条款，允许客户停止项目并支付总成本中一定比例的份额，可能还要补偿供应商被临时通知去寻找一份新合同的损失。

框架：在“计划游戏”中，业务方可以是一个曾经构建过框架将要支持的那种应用程序的程序员。框架的功能将成为故事。

套装产品：“计划游戏”中，业务方的角色可由市场部扮演，也可能雇用一个专家级的软件用户作为业务方的一部分。

                                                                   2003-12-16

第27章 结论

任何方法论都源自恐惧。你设法去养成一些习惯，就是为了避免使恐惧成为现实。即使对所有能够想到的可能做好准备，我们也会受到预料之外的不测事件的攻击。团队可以随时做好充分的准备，朝业务或系统要求的方向前进。放弃为应变所做的直接准备后，他们反而变得能够适应任何变化。他们什么都不预料，他们对任何事情不再感到惊讶。

                                                                                                                2004-01-11

http://blog.csdn.net/dwater