极限编程图示

1996年，Kent Beck提出 “极限编程”（Extreme Programming，简称XP）这一新的软件开发观念。XP是一种专注于编程技术、团队协作的软件工程方法学，基于沟通、反馈、简洁、勇气和尊重的价值观。

极限编程通过以下 五种基本方式实现一个简单、高效的合作环境。

• 团队奉行 “简洁”价值观，利用现有投资实现价值最大化，在实现目标的时候尽可能地用简单的步骤，以防试错成本过高；
• 成员之间 面对面“沟通”，对开发过程中的每一件事都共同寻求最优解；
• 每一次迭代成果都尽早演示，通过 “反馈”及时调整流程来适应整个项目的进行；
• “尊重”团队成员所付出的努力，客户与开发人员、管理层三方互相理解；
• 信任自己的伙伴， 有“勇气”说出自己的失败或者错误，以确保团队及时适应变化。

XP地图解析：

1.用户故事：

用户故事由客户编写，是站在用户角度描述具体的期望需求。它不局限于只描述用户界面，还推动了验收测试的创建。开发过程中，团队必须创建一个或多个自动接受测试，以验证产品是否正确实施了用户案例。

用户故事不宜过大。每个故事的“理想开发时间”分别为1、2或3周，理想的开发时间是在团队没有正在进行的其他任务，没有干扰，并且有明确计划的情况下用代码实现用户故事所需的时间。

2.spike方案架构：

当团队开发过程中遇到棘手的技术或者技术问题的时候，需要创建一个spike解决方案。

spike解决方案是一个非常简单的程序，通过构建峰值来解决正在检查的问题。因此团队往往将它用于探索潜在的解决方案，以降低技术问题的风险或增加用户故事估算的可靠性。

3.发布计划：

该计划对整个项目进行总体布局，再为每个迭代周期创建迭代计划，其实质是让开发团队根据理想的编程周来评估每个用户故事。

发布计划的基本原理是，一个项目可以通过四个变量来量化。范围、资源、时间和质量：范围是要完成的工作量；资源是多少有空的人；时间是项目或发布完成的时间；质量是软件的质量以及测试的质量。没有人可以控制所有4个变量，当一个变量改变时，其他三个都会随之变化。因此，发布计划会议中最重要的是，客户、经理、开发团队需要协商出一个可接受的发布计划，然后在执行计划中合理地控制变量以达到理想效果。

4.迭代开发：

极限编程将复杂的开发过程分解成一个个小的开发周期，对需求分析、设计、编码、测试进行反复迭代。每个迭代周期为1到3周，在每次迭代开始都召开一次迭代会议，计划要完成的工作，及时调整工作规划。

在每个开发周期中，通过客户、业务人员和开发人员的交流、反馈能够清楚地发现软件开发过程中现存的问题并进行及时调整。另外，极限编程还要求将每次迭代看作最后一次迭代，团队中每个人都要时刻为按时交付产品做好准备。

5.验收测试：

在迭代过程中，迭代计划会议期间选择的用户案例将转换为验收测试。该客户指定测试场景，以验证用户故事是否被正确执行。

每个验收测试代表系统的预期结果。客户负责验证验收测试的正确性，并检查测试分数，以确定哪些失败的测试需要优先进行调整。在最终产品发布之前，验收测试还用作回归测试。

此外，每个迭代中都要创建验收测试，只有通过了验收测试才能进行迭代的交付，否则进度依然为零。

6.频繁发布小版本：