XP的十二种方法

XP的十二种方法将其定义为规则，下面我们来简单地看看到底是哪十二种“极限”方法：

[b]规划策略(The Planning Game) [/b]
这一方法背后的主要思想是迅速地制定粗略计划，然后随着事物的不断清晰来逐步完善。规划策略的产物包括：一堆索引卡，每一张都包含一个客户素材，这些素材驱动项目的迭代；以及对下一两个发行版的粗略计划。

[b]结对编程(Pair programming)[/b]
就是在开发中两个程序员一起编写一个项目的一种技术。两个程序员工作在同一台机器上，当一个程序员在写代码的时候，另一个程序员在一旁观看，同时认真地审查代码。写代码者从战术上考虑具体实现，其伙伴则从战略上考虑整个程序。他们之间频繁地交换角色，这样将使得可以更快写完代码，并且减少错误。

[b]测试(Testing)[/b]
包括单元测试和验收测试。就是开发人员在编写代码之前先写单元测试代码，以便告诉开发人员系统在某一点上是否正常“工作”。而客户在开发人员定义了素材后就写验收测试计划，以告诉团队系统是否执行用户希望它执行的操作。

[b]重构(Refractoring)[/b]
重新划分是实现特性之前和之后的两个时机，并且在不更改功能性的前提下对代码加以改进。

[b]简单设计(Simple Design)[/b]
使用能够工作的最简单的设计，然后不断随着现实的显现来更改这些设计，而不是一开始就把额外的特性设计给包含进来。

[b]代码集体所有权(Collective Code Ownership)[/b]
就是项目小组中的任何人都应该有权对代码进行更改，以求改进整个项目。

[b]持续集成(Continuous Integration)[/b]
XP 团队在一天中集成了代码几次，每次都在所有单元测试对系统运行后执行。经常进行代码集成可以帮助您避免集成梦魇。

[b]现场客户(On-site Customer)[/b]
要使功能最理想，XP 小组需要现场有一位客户来明确素材，并做出重要的企业决策。开发人员是不允许单独做这些事情的。让客户随时在场可以消除开发人员等待决策时出现的瓶颈。

[b]小型发布（Small Release）[/b]
发行版应该尽可能地小，同时仍然提供足够的企业价值以证明它们值得。

[b]每周40小时工作制（40-hour Week）[/b]
长时间地持续工作会扼杀工作绩效，疲劳的开发人员会犯更多错误。XP将按正常的每周40小时工作时间表来进行工作。

[b]编码规范（Code Standards）[/b]
目标不是创建一个事无巨细的规则列表，而是将能够确保您的代码可以清晰进行交流。

[b]系统隐喻（System Metaphor）[/b]
比喻为团队提供了一致的画面，他们可以用它来描述现有系统的工作方式、新部件适合的位置，以及它们应该采取的形式。它与大多数软件开发方法中被称为体系结构的差不多。