极限编程开发实践：如何开启使用极限编程的第一步？

在一个新项目开始时，操作者决定使用极限编程（ XP）。

首先，开始收集用户故事，并为看起来有风险的事情执行专项解决方案，这只需花费几个星期的时间。 然后安排发布计划会议，邀请客户、开发人员和经理商议后制定时间表，从迭代计划会议后开始启动迭代开发。

通常，项目只有在遇到麻烦时才会寻求极限编程等新方法的帮助。在这种情况下，启动 XP的最佳方法是仔细研究您当前使用的软件方法，并找出是什么拖了您的后腿。 接下来将列举一些问题及 XP 解决方案。

 例如：

• 如果您发现在整个开发过程中，需求规范有 25% 是完全无用的，那么您可以与客户一起编写用户故事。
• 如果您经常遇到需求变更的问题，导致您频繁地重新创建您的计划，那么尝试每隔几次迭代就召开一次更简单、更容易的发布计划会议（但您首先需要用户故事）。尝试一种迭代式的开发风格，并及时进行编程任务的规划是解决此问题的关键。
• 如果遇到最大的问题是生产中的 bug数量，那么请尝试进行自动化验收测试，使用此测试套件进行回归和验证测试。
• 如果过程中最大的问题是集成 bug，那么请尝试自动化的单元测试。在将任何新代码发布到代码存储库之前，要求所有单元测试都通过（达到 100％）。
• 如果一两个开发人员因为拥有系统中的核心类而成为瓶颈，并且必须进行所有的更改，那么清尝试集体代码所有权。（您还需要进行单元测试）让每个人都可以在需要时对核心类进行修改。

您可以一直沿用这种方式，直到没有问题为止，然后尽可能地添加剩下的项目进行实践。您添加的第一个练习看起来很简单，而且遇到的第一个、第二个问题解决起来似乎也很简单。但是，在拥有一些 XP规则和所有 XP规则之间，需要一些持久性才能使 XP继续发挥作用。简单运用了 XP之后，您的问题将得到解决，您的项目将得到控制。在问题得到解决的时候，放弃新的方法并回到熟悉和舒适的环境似乎不错，但继续使用下去，最终会有更大的收获，您的开发团队将变得比您想象的要高效得多。

在某种程度上，您会发现 XP规则不再是规则。规则之间有一种协同作用，在你完全融入之前是很难理解的。

在结对编程实践中，这种爬坡情况尤为常见，但是这种技术的回报是非常大的。同样，单元测试需要时间来收集，但是单元测试是许多其他 XP实践的基础，所以回报也是非常大的。

XP项目并不是安安静静、各自为政的项目，在实施过程中，总有人在谈论问题和解决方案。人们不约而同地聚在一起解决难题，然后又分开。团队管理者鼓励这种互动，提供一个会议区域，并建立专门的工作空间，这样两个人可以很容易地凑在一起工作。