极限编程简介

现在我们有很多敏捷过程：SCRUM，Crystal，特征驱动开发（Feature Driven Development，FDD），自适应软件开发（Adaptive Software Development，ADP）以及极限编程（eXtreme Programming，XP）。今天这里简述一下极限编程。

极限编程是敏捷方法中最著名的一个。由一系列简单却互相依赖的实践组成。

客户作为团队成员

首先谁是客户？甲方人员么？是但不全是。XP中的客户指定义产品特性并排列这些特性优先级的人或团体。

XP希望客户能够可开发人员坐在一起紧密的工作，便于知晓对方面临的问题并共同去解决这些问题。

用户素材

为了进行项目计划，必须要知道和项目需求有关的内容，但是却无需知道得太多。对于做计划而言，了解需求只需要做到能够估算它的程度就足够了。

在XP中我们可以和客户反复谈论，以获取对需求细节的理解，但不需要去捕获它。我们可以在卡片上写下一些短语来帮我们记录这些谈话细节，并根据堆细节的理解写下它的估算。这些卡片就可以说是用户素材（user stories）--正在进行的关于需求谈话的助记符。

一开始我们不会试图确认所有的用户素材，随着项目进展，客户会不断编写新的用户素材，素材的编写会一直持续要项目结束为止。

时间估算

客户可以使用它并根据它的优先级和估算代价来安排实现该需求的时间。估算时使用的是相对时间而不是绝对实践。

过大或过小的素材都很难估算。开发人员往往都会低估那些大的素材高估小的素材。所以，任何大的素材都应该分解成小的部分；任何小的素材都应该和其他小的素材合并。

短交付周期

每2周交付一次可以工作的软件。

迭代计划

每次迭代的预算有开发人员通过度量以前迭代中完成的工作量来确定。只要估算成本总量不超过预算，客户就可以为本次迭代加入任意数量的用户素材。

迭代期间客户不会在加入任何素材，由开发人员根据技术、商务情况来确定开发顺序。

任务计划

每个素材都可以分解为开发任务，一个任务就是一个开发人员4~16个小时之内能实现的一些功能。

发布计划

一个发布计划差不多涵盖6个迭代计划的内容。发布计划由客户根据开发人员给出的预算所选择的、安排好优先级的用户素材组成。

发布计划可以由客户根据情况随时变更。

验收测试

验收测试可以用自动的可以反复运行的脚本语言来写。用户素材的验收测试要在实现该用户素材之前或同时编写。

结对编程

由2为开发人员在同一台电脑上完成。可以一个写测试代码，另一个负责写实现，并不停的互换角色。

这么做很有利于知识在团队中的传递。

测试驱动的开发方法

TDD，优先写出测试代码，然后完成实现代码，要求恰好满足测试代码即可，一定要注意恰好二字，可以避免设计过度，减少代码不必要的复杂度。

集体所有权

代码是针对团队中所有开发者的，不存在那块代码由某某负责的情况，每个人都可以接触到所有的代码。当然，对于你擅长的部分还是要多花功夫的，呵呵

持续集成

始终确保系统可以正常的工作。应该是每次check in代码后就应该进行的。

可持续的开发速度

软件项目不是全速的短跑，是马拉松长跑。所以为了可以保证长期效果就应该始终保持稳定、适中的速度。

很多资料把这一条解释为每周工作40小时。唉~~~，真希望我参加的项目可以真的做到这一点啊。

开放的工作空间

大家坐在一起，并总是充满了讨论声。这点效果真的很好，尤其是要充满讨论声，我们有些同学很害羞的，只有在这种讨论的大环境中才会放开一些。

计划游戏

这里是划分业务人员和开发人员的职责。业务人员决定特性的重要性，开发人员决定实现一个特性所花费的代价。

简单的设计

XP团队的设计要尽量的简单、具有表现力。只需要考虑本次迭代的用户素材的设计，不需要考虑未来的用户素材。

1.考虑能够工作的最简单的事情

XP团队总是尽可能寻找能实现当前用户素材的最简单的设计。如：能用平面文件就不去使用数据库或EJB。

2.你将不需要它

但是总有一天我们会使用数据库，会有多个用户使用。那么我们现在就需要将它引入么？开始时我们假设不需要，只有真的有迹象表明需要引入比等待更合算时，才引入。

3.一次，并且只有一次

不能有重复的代码。

重构

随着项目的进展，我们添加了一个又一个特性，处理一个又一个的错误，代码结构会逐渐的退化，就需要我们进行重构。当然重构不是在特定时间才执行的，它是持续的、不定时的。

隐喻

隐喻是将整个系统连接在一起的全局视图；是系统未来的景象，是它使得所有单独模块的位置和外观变得明显直观。

我个人认为隐喻，应该是一种将抽象系统用自己熟悉的方式表达的一种手段。如：很多资源共享的例子都可以用消费者-生产者来理解，这里消费者-生产者就是一种隐喻。