解析极限编程---读书笔记

解析极限编程

---

第一部分 问题

​ 软件开发规范中要解决的问题的不同层面来设定极限编程的前提。

​ 驱动隐喻、四个准则、从这些准则派生出来的原则，以及要根据我们的新开发规范组织的活动。

---

第一章 风险：基本的问题

进度延迟（XP要求发行周期较短，最多为几个月），项目取消（XP让客户选择具有最大业务意义的最小版本，从而使得软件的价值得到最大化），系统恶化（XP创建并维护一整套测试程序，以确保质量基准），缺陷率（按照程序员和客户双重角度进行测试程序的编写），业务误解（项目的说明书会在团队开发的过程中不断地得到改进），业务变更（客户用新功能取代仍未完成的功能），错误特性多（XP只专注于有最高优先级的任务），人员调整（程序员需要自己进行估算）。

第二章 开发情节

XP核心故事—开发情节：

两个程序员一起编程–》测试驱动开发，除非所有的测试都能运行，否则就没用完成–》结对程序员不仅让测试用例运行，还改进系统的设计–》集成时包括集成测试

第三章 软件开发的经济学

对于一个不确定价值的新功能，不妨等待一下，防止无谓的劳作。

第四章 四个变量

控制变量系统：成本（突然增多并不会解决问题，太少也不能）、时间（也是不能太多和太少）、质量（牺牲的质量终究会以另一种方式被补回来）、范围（更小的解决客户业务问题的范围有助于提高质量）。外力（客户、管理人员）确定任意三个变量的值，而开发团队确定第四个变量的结果值。

需求从来都是不清楚的，客户从来不能确切地告诉我们他们需要什么。我们进行大量估算和反馈实际结果的工作。更好的估算能减小不得不放弃功能的几率。首先实现客户最重要的需求，这样如果不得不放弃别的功能，那么这个功能也不会比已经在系统中运行的功能更重要。

第五章 变化的成本

变化的成本随着技术的提升在逐渐变缓。

第六章 学会开车

我们需要通过做许多小的调整来控制软件开发，并且要以比较合理的成本完成这样的纠正。变化总是要发生的，问题实际上是在发生变化时有没有能力应对。

第七章 四个准则

• XP的四个准则：

  • 沟通：项目中出现的问题总是出自那些不愿与别人探讨重要问题的人身上。
  • 简单：今天做的简单点明天再去修改，总好过今天做的很复杂明天不用了要好。
  • 反馈：通过测试带来系统的反馈能使得我们很快找到系统的问题。
  • 勇气：对不好的代码要有勇气重构，同时也有勇气支持降低系统复杂性的古怪念头。

  开发小组成员之间要相互尊重，进而才能使团队真正有效起来。

第八章 基本原则

快速反馈：快速反馈会使得我们在学习上的巨大不同

假设简单性：先出色完成今天的工作，并相信自己在将来必要时可以很好的修改系统。

递增更改：一小步一小步的更改

提倡更改：在解决最重要的问题的情况下保留最多选项的那一个

优质工作：要保证是真的干了好的工作

第九章 回到基本问题

软件开发的四项基本工作：编码、测试、倾听和设计。

代码可以用来沟通—表达策略性意图，描述算法，指出将来可能进行扩展和收缩的地方。

测试既是一种资源又是一种责任，测试在程序员来看可以巩固其自信，于客户来看，系统可以正常地工作。

找到一种构建沟通地方法，使得应该沟通地事情得到沟通，并且以适当的详细程度得到沟通。

必须提供一种环境：能够产生好的设计，改正糟糕的设计而且任何需要学习的人都可以学习当前的设计。

---

第二部分 解决方案

第十章 简短概述

计划游戏：业务人员决定范围，优先级，版本的组成，发布的日期；技术人员决定估算，后果，过程，详细的日程计划。

小版本：每个版本都应尽可能地缩小，包含最有价值的业务需求。

隐喻：引入隐喻我们可以得到易于沟通和阐述的体系结构

简单设计：根据测试增加功能是不理智的，要去掉任何可以拿掉而不违反系统约定的部分。

测试：不必为所编写的每个方法都编写测试，而只对有可能出错的方法编写。

重构：当系统要求程序员复制代码的时候，它也就是在要求重构。

结对编程：配对是需要有不同的角色，一个角色在于实现此方法的最佳途径，另一个在于战略性的思考。

集体所有权：如果有任何人发现改进任何部分代码的机会，他都应该立即执行改进。

持续集成：几小时，开发者就需要对代码进行集成和测试

每周工作40小时：保持心态和精力良好

现场客户：让真正系统用户坐下来，回答开发人员的问题。

编码标准：对整个团队而言应当自愿遵守这一的编码标准

第十一章 这如何奏效

任何一种实践都难以担当重任，它们需要其他实践来帮助保持平衡。

第十二章 管理策略

管理人员负责对团队服务，同时也要准备终止项目。

第十三章 设备策略

怎么合适，怎么对编码有效，设备就应当怎么摆放。

第十四章 拆分业务责任和技术责任

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

第十五章 计划策略

制定一个总体计划，然后在越来越短的时间范围内逐步深入地将其完善。拿到合同后，要立即开启计划游戏，才能够对自己按照合同交货的能力进行反复查对。

第十六章 开发策略

持续集成减少了开发冲突并为开发过程创造了一个自然而然的结尾。复杂代码不会存在很长时间，由于每个人都会查看所以当被发现时就会有人去尽量简化它。结对编程是知会找到有空的人。同时会产生更多高质量的代码，使得人们不会犯重压之下的错误实践。

第十七章 设计策略

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

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

在第一次迭代的过程结束拥有一个体系结构可能它不是我们所期望的但是我们会了解一些东西。

第十八章 测试策略

不应该测试那些不会在实践中出错的代码，应该测试可能出错的部分。

专职的测试员将客户比较模糊的概念转换为真实、自动化和独立的测试。

---

第三部分

---

第十九章 采用XP

挑出最棘手的问题

以XP方式解决它

当它不再是最棘手的问题时，重复上述步骤。

第二十章 改进XP

对于已有软件团队的改变要一点点来虽然会很慢，但是走一些XP形式化的内容会使得大家对于流程的接受更快。

第二十一章 理想的XP项目的生命期

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

第二十二章 人员的角色

• 程序员要有信心面对责任。
• 客户要会给程序员解压同时学习如何编写故事和功能测试。
• 测试员需要帮助客户选择并编写功能测试。
• 跟踪者需要整体观察，记录团队历史，需要培养是在不打扰团队地流程而收集信息。
• 教练在整体上负责这个过程。团队逐渐成熟的过程中也就教练这个角色也慢慢不再重要。
• 顾问需要需要可以解决技术知识，并保持良好心态。
• 大老板需要更多的勇气去接受XP团队诚实的沟通。

第二十三章 20-80原则

将最有价值的20%功能投入生产，然后提供80%的收益，通过20-80原则延期优化。

第二十五章 什么时候不应使用XP

当团队太大、客户多疑以及技术不能很好地支持更改。

第二十六章 工作中的XP

第二十七章 结论

团队可以随时做好充分的准备，朝业务或系统要求的方向行进。放弃为应变做的直接准备后，他们反而变得能够适应任何变化。