eXtreme Programming（极限编程）

1. 定义

   1、Extreme Programming (XP) 是以开发符合变化的客户需求的软件为目标而产生的一种方法， 它的成功得益于它对客户满意度的特别强调，XP 使开发者能够更有效的响应客户的需求变化，哪怕在软件生命周期的后期。
   2、一种历过很多实践考验的软件开发方法.
   3、是一种轻量、高效、低风险、柔性、可预测、科学而且充满乐趣的软件开发方法。
   4、是勇气，交流，反馈和简单。
   5、是软件开发过程中的纪律，它规定：必须在编程前写测试，必须两个人一起编程，必须遵守编程规范……。
   6、是把最好的实践经验提取出来，形成了一个崭新的开发方法

. XP 与其它方法论的不同之处
1. 短周期内的早期、具体和持续的反馈。
3. 递增地进行计划编程，这种方法迅速提供一个总体计划，然后在项目的整个生命周期内不断发展它。
4. 针对不断变化的业务需求，灵活地对功能的实现进行计划的能力。
5. 依赖于程序员或客户编写的自动测试来监控开发速度，使得系统得以进展并及早捕获缺陷。
6. 依赖口头交流、测试和源代码来沟通系统的结构和意图。
7. 依赖于在整个系统存在期间一直持续的进化式设计过程。
8. 依赖于技术水平一般的程序员之间的紧密协作。
9. 依赖于能同时满足程序员的短期本能和项目的长期利益的实践。

. XP价值观

1. Communication
   开发中的大部分问题都是由沟通问题引起的
   XP的目标是通过使用许多没有交流就无法完成的实践来保持正确的通信流

2. Simplicity
   做到简单并非易事，世界上最难的事情就是不去考虑自己明天、下星期乃至下个月的任务。
   XP是在打赌. 它打赌今天做得简单一些，然后在明天需要时再花些功夫进行改进，要比今天做得很复杂，但以后再也用不到要好得多
   简单和沟通之间有一种奇妙的相互支持的关系。
   –沟通得越多，就越清楚哪些工作需要做，并能更加确信哪些工作不需要做。
   –系统越简单，需要的沟通越少，但是沟通会更加全面

3. Feedback
   －－客户和测试者为需要系统实现的所有故事编写功能测试，能够得到有关系统状态的具体反馈。
   －－客户隔2－3周检查一次日程，查看开发团队的整体进度是否与计划相符，并随之调整计划。
   沟通, 简单和反馈是相互联系的；
   –反馈越充分，沟通越容易。
   –系统越简单，就越容易测试和提供反馈

4. Courage
   沟通支持勇气，因为它带来了高风险、高回报的试验的可能性。
   简单支持勇气，因为有了一个简单的系统，你可以比以前勇敢得多，你无意中将其破坏的可能性也大大减少。
   勇气支持简单，因为只有你有可能简化系统，你就会尝试。
   反馈支持勇气，因为如果你按下按钮就能够看到测试结果通过（或不通过，这时你可以将代码扔掉），那么即使对代码进行根本的改动你也会感觉安全得多。

5. 管理

   发布(Release)：每一期开发结束时提交给用户的一个可运行的系统。
   迭代(Iteration)：一期开发过程中的一个开发周期。它有明确的目标，计划和实现方式，它包含了需求分析、设计、编程、测试等完整的开发过程。一个迭代的长度为1到3 周。在一期开发过程中，所有迭代的长度是相同的，比如都是3周。
   小发布(Small Release)：处于开发中的系统，每集成一个新功能，都可以称为一个小发布。
   理想开发时间：估计完成一项工作所需的持续工作时间，不考虑意外因素

• 需求

  SPIKE：对不确定的需求和设计等，通过写一些程序、进行详细设计或者演算等等方式做探测和尝试，以确定可行性。这些探测过程称为SPIKE。
  User Story：是对用户的一个需求的一段简洁清晰的描述，该段描述有三个属性，即商业优先级、开发时间和风险。从某个角度看，XP过程是面向User Story的。
  故事卡：用户把User Story的内容和属性写在一张卡片上，该卡片即故事卡。

• 设计

  CRC： Class – Responsibility – Collaboration。1989年， Kent Beck和Ward Cunningham提出的OO分析和设计方法，现在得到了广泛应用。
  Responsibility：Class的行为。
  Collaboration： Class之间的相互联系和作用；Collaborator指和某行为(Responsibility)相关的Class。
  可以在卡正面加上父类名，子类名；可以在卡背后加上属性。
  Engineering Task：Team一起分析设计一个User Story，把该Story要完成的事情分解，就形成了一些任务(Engineering Tasks)。这些任务要足够小，以至于每个程序员都非常清楚要做什么，并能估计出完成该任务所需要的理想开发天。
  每个程序员挑选了一个Task后，就成为该Task的Owner，并估计完成该Task所需的理想开发天数。
  Task的粒度由理想开发天限制，大于1天且小于3天。
  从某个角度看，程序员的工作安排是面向Task的。
  Task卡：Task的内容、Owner和理想开发天都记录在一张Task卡上。

. XP的基本原则
1.Rapid feedback 快速反馈
指开发人员通过短的迭代周期，得到反馈信息，并迅速查验他们前面的工作是否满足客户要求。
2. Assume simplicity 假定简单
指将系统开发中的每个问题以尽量简单的方法来解决。没有人能够准确预知未来的需求，因此设计只需要满足现阶段的需求即可。
3. Incremental change 递增改变
指用一系列的小改变来逐步解决一个问题。这一原则可用于计划、开发和设计等。
4. Embracing change 拥抱变化
指在解决紧迫问题时，采取的一种包容的策略。程序员要明白客户的要求并不是固定的，因此功能的优先级和功能需求都是在变化的。
5. Quality work 优质产品
指工作和产品的质量是不容忽视的，不可以因为时间而放弃质量，并作出让步。