构建阶段

    构建的目标是完成系统开发。构建阶段从某种意义上来看是一个制造过程，其中重点工作就是管理资源、控制操作以优化成本、日程和质量。从这个意义上来讲，管理理念应该进行一个转换，从起始阶段和细化阶段的知识产权开发转换到构建和交付阶段的部署产品的开发。

    XP 侧重构建阶段。构建阶段是编写产品代码的阶段。XP所有阶段的目的都是为了进行计划，但是 XP 的关注焦点是构建代码。

    构建阶段的每次迭代都具有三个关键活动：

    管理资源与控制过程。每个人都需要了解自己的工作内容和时间。您必须保证工作负荷不会超过您的能力，而且工作可以按计划进行。

    开发与测试组件。您构建组件以满足迭代中用例、场景以及其他功能的需要。您对其进行单元测试和集成测试。

    对迭代进行评估。在迭代完成时，您需要判断是否已经达到了迭代的目标。如果没有，您必须重新划分优先级并管理范围以确保能够按时交付系统。

    不同类型的系统需要使用不同的技术。RUP 为软件工程师提供了不同的指导，以帮助他们创建恰当的组件。以用例和补充（非功能）需求的形式提出的需求是足够详细的，可以使工程师开展工作。RUP 中的若干活动为设计、实施和测试不同种类的组件提供了指南。一名有经验的软件工程师不需要详细查看这些活动。经验稍欠缺一些的工程师可以通过非常好的实践获得很大的帮助。每个团队成员都可以按需要深入研究过程或者只是稍微了解一下。不过，他们都参照一个单独的过程知识基础。

    在 XP 中，"故事"驱动实施过程。在 Extreme Programming Installed 一书中，Jeffries等人认为"故事"是程序员的"会话承诺"（promises for conversation）。 持续有效的交流大有裨益。虽然总是需要澄清一些细节，如果"故事"不够详细，而使程序员不能完成他们大部分工作，那么可以说"故事"还没有就绪。用例必须足够详细以方便程序员实施。在许多情况下，程序员会帮助编写用例的技术细节。Jeffries 等人认为，会话应该记录在文档中并且附加到"故事"中。RUP 也同意这个观点，除了以用例规格说明的形式，可以按需要使用非正式的形式。捕获并管理会话的结果是您必须管理的任务。

    XP 的长处在于构建阶段。对于大多数团队来说，都存在适用于他们的"智慧与指南的结晶"。XP 中最显著的实践包括：

    测试--程序员不断地随着代码的开发编写测试。测试反映了"故事"。XP提倡您首先编写测试，这是一项优秀的实践，因为它可以迫使您深刻地理解"故事"，并且在必要的地方提出更多的问题。不论在编写代码之前还是之后，一定要编写测试。将它们加入到您的测试包中，并且保证每次代码变更时都运行测试。

    重构--不断重构系统的结构而不改变其行为，可以使其更加简单或灵活。您需要判断对您的团队来说是否存在一个较好的实践。简单与复杂的判别否因人而异。有这样一个例子，一个项目中的两个很聪明的工程师每晚都要重写对方的代码，因为他们认为对方的代码过于复杂。这产生了一个副作用，也就是他们总是干扰第二天其他成员的工作。测试是有帮助的，但是如果他们之间不陷入代码之争的话，那么团队的处境就会更好一些。

    结对编程--XP 认为结对编程可以在更短的时间内创建出更好的代码。有证据表明这是正确的 。如果您遵照这项实践，就需要考虑许多人文与环境的因素。程序员愿意对此进行尝试吗？您的物理环境可以满足这种情况吗，即有足够的空间使两个程序员在一个单独工作站中有效地工作？您如何对待远程工作或者在其他地点工作的程序员？

    持续集成--集成与构建工作需要持续进行，可能每天不止一次。这是一种确保代码结构完整的很好的方式，它还允许在集成测试过程中进行持续的质量监控。

    集体代码所有权--任何人都可以随时修改任何代码。XP 依赖这样一个事实，即一组好的单元测试将会减少这项实践的风险。让大家将每一件事都搞清楚的好处不能局限在一定的尺度上--是 1 万行代码、2 万行代码还是一定要少于 5 万行？

    简单设计--随着重构过程的进行，需要不断地修改系统设计使其变更简单。再一次重申，您需要判断这项工作进行到何种程度才恰好合适。如果您在细化阶段中花费了必要霎时间来设计构架，我们相信简单的设计将会很快完成并且很快变得稳定。

    代码标准--这一直都是一项良好实践。标准是什么都没关系，只要您使用它们而且每个人都认可就可以。

    RUP 与 XP 都认为您必须管理（和控制）迭代过程。衡量标准可以提供较好的计划信息，因为它们可以帮助您选择对于您的团队来说什么是最适合的。需要衡量三件事：时间、规模和缺陷。这样您就可以获得所有类型您所感兴趣的统计数字。XP 为您提供简单的衡量标准来判断进展并且预测成果。这些衡量标准围绕着完成的"故事"数量、通过测试的数量以及统计中的趋势这些问题。XP 为使用最少量的衡量标准做出了一个优秀的表率，因为查看太多并不一定会增加项目成功的机会。RUP 为您提供了对于您可以衡量的内容以及如何衡量的指导，并且举了有关衡量标准的例子。在所有的情况中，衡量标准必须简单、客观、易于搜集、易于表达，并且不易产生误解。

    在构建阶段的迭代过程中将会产生哪些工件呢？这取决于迭代是处于构建阶段的早期还是后期，您可以创建以下工件：

    组件--组件代表了软件代码中的一部分（源代码、二进制代码或者可执行程序），或者包含信息的文件，例如，一个启动文件或者一个 ReadMe 文件。组件还可以是其他组件的聚合，例如由几个可执行程序组成的应用程序。

    培训资料--如果系统的用户界面比较复杂，那么请在用例的基础上尽早编写用户手册和其他培训资料的初稿。

    部署计划--客户需要一个系统。部署计划描述了一组安装、测试并且有效地向用户交付产品所需的任务。对于 以Web 为中心的系统来说，我们已经发现，部署计划的重要性又提高了。

    交付阶段迭代计划--临近交付时，您需要完成并且评审交付阶段迭代计划。

    代码完整吗？

    认为代码就是设计并且设计也就是代码。代码与自身总是一致的，这一点是千真万确的。我们认为花费精力进行设计并且沟通设计是很值得的，而不仅仅是创建代码。下面的小故事会说明这一点。

    RUP 与 XP 间的差异除了建立构架的方法以外，还包括其他方面的不同。其中一点就是关于设计概念的沟通方式。XP

    一名工程师曾有两次这样的软件项目经历，设计体现在代码中，并且只能在代码中找到设计信息。这两个项目都是关于编译器的：一个是改进与维护用于 Ada 编译器的优化程序，另一个项目是将一个编译器的前端移植到一个新的平台上，并且连接一个第三方的代码生成器。

    编译器技术是比较复杂的，但也是广为人知的。在这两个项目中，该工程师想要概览编译器（或者优化程序）的设计和实施。在每个案例中，他都接到一堆源代码清单，大概有几英尺厚，而且被告知"查看这些信息"。他本应被提供一些带有支持性文字的构建很好的图。优化程序的项目没有完成。但是编译器项目确实取得了成功，由于在代码开发过程中进行了广泛的测试，所以代码质量很高。这位工程师花费了数天时间研究调试器中的代码以弄明白其作用。个人的损失尚在其次，团队的损失代价就更不值得。我们并没有按 XP 所示的那样在 40 小时后完成开发，我们反而花费了大量个人努力来完成工作。

    只开发代码带来的主要问题就是无论代码文档编写得多么好，它都没有告诉您它本身要解决的问题，它只提供了问题的解决方案。一些需求文档在最初用户和开发人员继续工作很长时间以后，仍然可以很好地解释项目的原始目标。为了维护系统，您往往需要了解最初项目团队的设计目标。一些高级设计文档都是相似的--代码经常没有经过高度的抽象，所以无法提供任何信息以表明整体的系统能够实现什么功能。在面向对象的系统中，这一点尤其是正确的，因为仅仅查看里面的类文件是很难甚至无法得出执行线程。设计文档指导您在后期出现问题时该查看的内容--在后期经常会出现问题。

    这个故事说明花费时间创建与维护设计文档确实会有所帮助。这可以降低误解的风险，并且加速开发过程。XP 的方式就是花费几分钟勾画出设计的大概内容或者使用 CRC 卡片。 但是团队不主张这样，而只是进行代码开发。他们有一个隐含的假设，那就是任务很简单，我们已经知道该如何进行了。即使我们成功地完成了任务，那么下一个新来的人可能就不会如此幸运。RUP建议您多花费一些时间创建并维护这些设计工件。

    交付阶段

    交付阶段的焦点就是确保软件对于最终用户是可用的。交付阶段包括为发布进行产品的测试，在用户反馈的基础上做微小的调整等几方面内容。在生命周期的这个时刻，用户反馈主要集中在精确调整产品、配置、安装，以及可用性等问题上。

    较早发布、经常性发布都是很好的办法。但是，我们通过发布要达到的目的是什么呢？XP 没有清楚地解释这个问题，也没有处理发布商业软件所必须制造问题。在内部项目中，您可以为解决这些问题找到捷径，但是即使这样，您仍然需要编辑文档、员工培训等工作。那么技术支持与变更管理又如何呢？希望现场客户控制这些内容，这是可行的吗？Bruce Conrad 在他的 XP 的 InfoWorld 评论 中指出用户并不希望得到的软件总是在持续变更。您必须对快速变更软件的利益和变更的劣势及可能带来的不稳定性进行权衡。

    当您决定发布的时候，您必须为最终用户提供比代码多得多的东西。交付阶段的活动和工件会指导您完成本部分软件开发过程。这些活动主要是为了向您的客户提供可用的产品。交付阶段的关键活动如下：

    确定最终用户支持资料。该活动比较简单，您只需提供一个清单即可。但是务必要确保您的组织已准备好对客户进行技术支持。

    在用户的环境中测试可交付的产品。如果您能够在公司内部模拟用户环境，那是最好不过的。否则，就到客户的公司去，安装软件并且保证其可以运行。您一定不想尴尬地回答客户："但是在我们的系统上工作很正常。"

    基于用户反馈精确调整产品。如果可能的话，在您向有限数量客户交付软件时计划一次或者多次 Beta 测试周期。如果进行该测试，那么就需要对 Beta 测试周期进行管理，并且考虑您"收尾工作"中的客户反馈。

    向最终用户交付最终产品。对于不同类型的软件产品和发布版本，需要处理许多有关打包、制造和其他产品问题。您肯定不会仅仅将软件复制到一个文件夹中，然后向客户发一封邮件告诉他们软件已经到位了。

    与其他阶段一样，过程的格式与复杂度都有所不同。不过，如果您没有注意部署细节，那么可能导致数周或数月的良好开发工作前功尽弃，从而在进入目标市场时以失败告终。

    在交付阶段中您可以生成若干工件。如果您的项目涉及到将来的发布（有多少项目没有涉及到呢？），那么您就应该开始为下次发布确定功能和缺陷。对于任何项目，下列工件都至关重要：

    部署计划--完成您始于构建阶段的部署计划并且将其作为交付的路线图。

    版本注释--它是一个比较少见的软件产品，不包含对最终用户至关重要的指令。可以对其做出计划，对于注释要有一个可用的、一致的格式。

    交付阶段资料与文档--这类资料可以采取很多形式。您可以在线提供所有内容吗？您会进行指导吗？您的产品帮助完整并且可用吗？不要认为您所了解的，客户也同样了解。您的成功就在于帮助您的客户取得成功。