解析极限编程-拥抱变化_V2

作者：Kent Beck

第一章 极限编程定义

XP（极限编程）：extreme programming，适用于中小型团队在需求不明确或迅速变化的情况下进行软件开发的轻量级方法学。

第二章 学习开车

“开车并不是简单地把车开对方向。开车是要保持注意力集中，这样调整一下，再那样调整一下。”

这正是XP的范式：保持清醒、适应、变化。

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

开车这个隐喻应用于XP时有两个层次，客户驱动系统的内容，团队则驱动开发的过程（领域驱动设计）。XP让你通过不断的、小的纠正来适应，通过短周期的部署软件来朝着目标前进，这样你就不会过很长时间才发现自己走错了方向。

客户驱动系统的内容。客户（内部或外部的）从系统需要解决什么问题的概要想法开始。但是，客户通常不会清楚地知道软件应该做成什么样子。这就是为什么软件开发与开车相似，不是让车笔直地沿着道路前进。团队的客户，当他们周复一周地决定软件接下来应该走向何方时，需要谨记他们应该朝地平线的哪儿前进。

每个团队表达他们价值观的形式都会因地点、时间、团队的不同而不同。如客户驱动着系统的内容，整个团队从当前的一组实践开始，驱动着开发的过程。随着开发的继续，团队将会意识到哪些实践需要加强，哪些实践偏离了目标。每项实践都是一个改进效率、沟通、自信心和生产率的试验。

第三章 价值观、原则和实践

园艺师和普通人的区别：

1. 园艺师知道的技术比普通人多。将知识和理解的这个层次称为实践，实践就是你实际上做的事情。实践是你天天都做的事。对实践进行详细描述是有用的，因为它们是明确和客观的。你可以在修改代码前编写测试，也可以不这么做。实践的一个用处在于它们给了你一个起点：你会在修改代码前编写测试，并从中获益，哪怕你还远没有在更深层次上理解软件开发。
2. 即使普通人知道了所有的园艺技术，但还不能算是一个园艺师。在园艺方面什么是好的什么是差的，园艺师有着高度发达的判断力。他看一眼整个花园心里就知道哪儿是好的，哪儿不对。普通人可能自豪于正确剪枝的能力，园艺师却可能认识到整棵树都应该除掉。他看到这一点并不是因为他比我更擅长修剪，而是因为他对于花园中有用的东西有一个整体概念。我必须学习那些对他而言简单明了的东西。
3. 价值观是知识和理解的另一个层次。价值观是在某种处境中我们喜欢或不喜欢某事的根源。当一个程序员说 “我不想估算我的任务”，通常这和技术无关。事实上他已经做出了估算，只是不想暴露他的真实，他担心提供了一个判断的基准点，以后会对自己不利，因此，最好给出一个3倍的估算
   1. 将价值观显式化很重要，因为没有价值观，实践很快会变成生搬硬套，为行动而行动，缺乏目的或方向。从根源上分析，价值观与实践的结合意味着程序员有充分的理由会选择高效率地执行一个实践。价值观让实践有的放矢。
   2. 实践是价值观的表现，实践是清除明确的
   3. 价值观和实践是大洋的两岸，价值观是普适的，实践有非常强的情景性。
4. 在价值观与实践之间架起桥梁的是原则。原则是生活中具体领域的指导方针。普通人仅仅知道在草莓边上种植万寿菊，园艺师却知道伴栽法可以使彼此毗邻的植物相互弥补自己弱点的原则。万寿菊天生克制吃草莓的虫子。将它们种植在一起是一种实践，伴栽法就是原则。

第五章 原则

改进

软件开发的卓越是通过改进达到的

软件开发技术的历史就是逐步减少浪费的人力的历史。虽然改良的科技消除了浪费，但开发组织的社会结构增长的僵化和专业分工却在增加浪费。改进的关键之处在于使这二者协调；使用新的技术让更有效率的新的社会关系成为可能。要在工作中改进，而不是等待完美。找一个起点，开始，然后改进。

多样性

团队需要将不同的技能、态度以及看待问题和缺陷的视角整合在一起，来考虑解决问题和实现解决方案的不同方法。也就是说，团队需要多样性。

第七章 基本实践

1. 坐在一起

2. 完整团队：把拥有项目成功所必须的各种技能和视角的人都包含进团队

3. 信息工作空间：许多团队通过在墙上放置故事卡片来部分地实现这项实践 （todo doing done）

4. 故事：使用用户可见的功能单元进行计划。
   
   为每个故事取一个简单的名称，以及简短的描述或图示。把故事写在索引卡上，并放置在经常路过的墙上。
   
   故事与其他需求实践的关键区别就是 “早早估算”。估算为业务和技术观点的交互提供了一个机会，什么东西可以较早创造价值？
   
   一个想法在什么时候最有潜力？如果团队知道产品特性的成本，就可以根据它们的价值来进行拆分、合并或扩展范围

5. 周循环：一次计划一周的工作。在每周开始的时候开会。在这个会议中：

   1. 回顾迄今为止的进展，包括上周的实际进展与期望进展的吻合程度
   2. 让客户挑选在这周内要实现的故事
   3. 把故事分解成任务。团队成员签字接受这些任务并估算它们的工作量

6. 在一周开始时编写在完成故事时要运行的自动化测试。然后将本周剩余的时间用于完成故事和使测试通过。

7. 季度循环：一次计划一个季度的工作。
   
   确定瓶颈，尤其是那些在团队控制之外的
   
   开始修补措施
   
   计划季度的主题
   
   挑选对应那些主题的整个季度的故事
   
   集中在宏观想法上，考虑项目和组织的关系

8. 松弛：10分钟构建：在10分钟之内自动地构建整个系统和运行所有的测试。超过10分钟的构建，人们一般很少愿意使用它

9. 持续集成

10. 测试优先编程
    
    通过显式客观地描述程序应该做什么，你可以给自己一个编码的焦点
    
    如果测试编写起来很困难，这是个信号，说明在设计上有问题，而不是测试的问题。低耦合、高内聚的代码是很容易测试的
    
    通过编写干净的可运行代码，并运用自动化测试来证明你的意图，你就给了你的队友一个信任你的理由
    
    编程的时候很容易就会几个小时都不知道自己在干什么，如果使用测试优先编程的方法，下一步要做的工作就会很清楚：要么编写另外一个测试，要么让没有通过的测试运行。这样很快就会演变成一种自然而高效的节奏：测试，编码，重构，测试，编码，重构

11. 增量设计

第八章 启程

仅仅通过看了本书，然后决定实践XP，是很难在新的环境中执行所有实践、支持所有价值观，并应用所有原则的。XP的技术只能及其背后的态度是需要时间去学习的。

那么，如何决定首先改变什么呢？

1. 通过观察你正在做什么以及你想要什么，来选择第一个实践。可以使用XP风格的计划方法(来做出这个决定)：编写改进软件开发过程的故事= “构建自动化”，“坚持测试先行”，“与joe结对编程2小时”。对每个故事要花费的时间做出估计，确定过程改进的预算，并且先选择一个故事来执行。在发现了容易的或有价值的以及困难的情况时再做出相应的调整。

2. 改变从意识开始（萌动-欲动-意动-冲动-行动）。改变所需要的意识来自于感觉、直觉、事实或局外人的反馈。感觉虽然有价值，但需要和事实或可信任的观点相互校验。

3. 意识可能来自度量。度量中的趋势可以在结果变糟之前指出何时应该做出改变。如果一个团队不能对过去的经历进行准确的反省，它就无法做出一个明智的决定，关于在多大程度上进行结对编程。

4. 一旦认识到需要改变，就可以开始改变了。你可以把基本实践作为开始来改进开发实践。每项基本实践都描述了一个行为的连续集，找到你在每项实践中的当前定位，选择一个实践，该实践的目的与你的变化优先级相符合，向该实践所描述的终点前移一步，看看开发过程中的人性和效率是否得到了提高。

5. 改变总是从自身开始。你唯一能够改变的人是你自己。不论你的组织功能多么健全或者情况恰好相反，你都可以自己开始应用XP。团队中的任何一个人都可以开始改变自己的行为：程序员可以先写测试；测试员可以使他们的测试自动化；客户可以撰写故事和排定优先级；主管们可以希望有透明度。

第十章 完整XP团队

测试员、交互设计师、架构师、项目经理、产品经理、主管人员、技术文献书写员、用户、程序员、人力资源、角色

• 信息是双向流动的：流入和流出团队。项目经理要促进团队与客户、赞助商、供应商和用户方的沟通。为了促进沟通，他们根据需要将团队内的合适人选介绍给团队外的合适人选，而不是充当一个交流瓶颈。项目经理同样要促进团队内部沟通以增强团队的凝聚力和信心。项目经理作为团队的一个高效的促进者，比作为一个重要信心的控制者，对团队的帮助更大。

第十二章 计划：管理范围

计划可以使目标和方向清楚明确。XP中的计划开始于把当前的目的、假设和事实公布于众。利用当前明确的信息，你们可以就什么是范围之内的、什么是范围之外的，以及下一步该做什么达成共识。

计划的一部分工作是从所有可能性中决定下一步要做什么。计划是复杂的，因为对故事的成本及价值的估算是不确定的。即我们赖以做出决定的信息是变化的。所以我们用反馈来改进评估，尽可能晚地做出基于最佳信息的决定。这就是为什么在XP中计划是一个每天、每周和每个季度都要做的活动。随着事实的出现，计划也在不断地改变以适应事实。

计划不是对未来的预测。计划至多通过表达你今天所知道的来估计明天也许会发生的事情。计划的不确定性也并没有否定其价值。它能够帮助你与其他团队间的协调同步。计划给了你一个出发点，帮助团队中的每一个人根据团队目标来作出决定。

任何时间尺度的计划都有这样四个步骤：

1. 列出可能需要完成的工作部件
2. 估算这些部件
3. 为计划周期设定一个预算
4. 就预算内需要完成的工作达成共识。谈判时，不要改变这些估算或者预算

我们需要聆听团队中每个人的声音。计划提供了一个平台，团队可以在其中了解到各方的希望，但是只对需求负责。

计划是我们共同来做的一件事情，需要合作。计划是一个听、说以及将目标和特定时间段联系在一起的训练。它对于每个团队成员都是有价值的输入。没有计划，我们就是很少沟通、缺乏效率的个体。也只有当我们和谐地计划和工作的时候，我们才构成了一个团队。

事情进展不顺利的时候就是我们最需坚持价值观和原则的时候，同时修改我们已有的实践去尽可能地保持效率。不准确的评估是信息的错误，而不是价值观或者原则的错误。如果是数字上的错误，那么就需要改正数字，沟通结果。

在索引卡上写故事，并把卡片放在墙上明显的地方。卡片是一种实现透明度的途径，将其作为重视和尊重每个团队成员的输入。

第十三章 尽早测试、经常测试、自动测试

软件开发的一个目标就是减少缺陷的出现，直到经济上能够接受的水平。

缺陷是不可避免的。在程序员时先根本想不到的情形，软件行为就很可能会超出其想象。

软件开发的另一个目标是减少缺陷的出现到一个可以适度增长团队信任的水平。一个程序员引入的错误会增加其他所有人的工作难度。每个团队成员引起的影响其他人的错误，都会导致整个团队的研发时间、精力以及彼此信任的成本消耗。

越早发现缺陷，所需的花费就越少

第十四章 设计：时间的价值

软件设计已经被物理设计活动的隐喻束缚住了

增量数据库设计策略

• 首先建立一个空数据库
• 采用脚本自动加载所有的表列和必要的已存数据
• 依次给脚本编号，使得运行脚本可以让数据库从任何早期阶段到达后期阶段

第十五章 增大XP规模

人数、投资、组织的大小、时间、问题的复杂性、解决方案的复杂性、故障的后果

第二十章 应用XP

开始XP过程就像进入一个池塘，而不是收养一个小孩。有许多方法可以进入一个池塘：你可以浸入一个脚趾，你可以坐在池边摇摆你的脚；你可以沿着台阶走下去；你可以完成一个平稳的强有力的竞技跳水；或者你可以像炮弹一样砸进去，制造巨大噪音且把你周围的每一个人弄湿，在这里没有哪种是所谓正确的方法。

开始组织变化之路仍然要从你自己做起，这是你可以控制的一个变化。首先锻炼你的技能，然后将它们投入使用。模范带头开发是一种有利的领导形式。

• 你学会测试先行编程，然后和你的团队共享这种方法和经验
• 你的团队要学会逐个故事评估和开发，然后邀请内部客户挑选故事
• 你的组织要学会按计划部署可靠的软件，然后邀请外部客户参与做计划

推动快速转变的条件如下：

• 校准价值观。团队和组织愿意以XP的价值观指导工作
• 痛苦。团队最近经历了一次失败，比如开发中止或部署失败，这些痛苦而清晰的记忆将使人们更加愿意尝试剧烈的变化

选择教练

“教练” 这个词意味着在成为团队一分子和坚持自己独立观点之间的一个平衡。开始阶段，教练负责发现改进的机会并引导实验解决它们，教练要有经验和洞察力，才不会陷入日复一日的团队工作中。

XP的价值观、原则和实践最好通过示例学习。你可以从犯过过错的人身上学习，否则你自己也会犯错误。

教练注意到沟通中的瓶颈并妥善的处理它们。当团队在畏惧的驱动下做事时，教练会提醒他们做简单地事情。教练也会激励团队团队采用XP的实践。教练既要示范有效的价值观和实践，又要对整个过程负责，保持团队在可承受的节奏下工作并持续改进，同时教练会交流他在这个过程中所看到的，以便团队能解决问题。

什么时候不应该使用XP

在其实际价值观与XP价值观不一致的组织中，XP是无效的。

第二十三章 永恒的编程之道

建筑师想要快速地完成一个工作并且得到奖赏，但是却忽视了关键的信息：顾客想怎样居住。亚历山大的梦想是把设计房屋的权利还给和其紧密相关的住户们。

亚历山大为了达到这个目的收集了大量建筑模式，以便根据设计和建造房屋中经常出现的问题定制好的解决方案。模式本身从来不是目的，而是作为一种在专业建筑师和那些将生活工作在建筑师设计的房屋中的人们之间平衡权利的手段。

亚历山大想要平衡设计者和空间用户之间权利的尝试最终失败了。建筑师不想放弃他们的任何权利而客户不知道提出任何需求。编程不是盖房子，软件开发也不是建筑。我们的材料跟他们的材料不同。在软件上，有机会创造新的社会结构，使得技术优点和商业利益联系起来生产新的产品和具有独特价值的服务，这就是我们的优势。

工具和技术总是在变化，但是它们的变化不大。然而，人，变化得慢却很深刻。XP的挑战是鼓励深刻的变化，更新个体价值观和互相间的关系。