本文来自于 Rational Edge：许多项目经常忽略和低估了它所采用的工具的作用。尽管团队倾向于重复地使用熟悉的工具，但是对工具进行明智地选择、适当地采用和部署可以产生更大的效用和带来更高的生产率。

　　We 我们最近正在进行一个高风险的应用开发项目，这个项目面临着很多挑战，包括：

　　有一个严格的时间限制（在两个月完成动这个应用的原型）

　　有一个非常紧迫的最终期限（在四个月内必须完成一个完全具有功能性、交互性和集成性的应用版本）

　　并不完整的需求

　　当进行软件应用开发时面对的是一个无经验的客户团队

　　这是一个地理位置分散的应用开发团队。

　　这个应用开发团队成员的技能水平参差不齐

　　尽管困难重重，我们仍然决定对这个客户积极做出相应，减小这个项目的风险，最终达到成功的目的。为了达到我们的目的，我们在思考如何最大化我们所具有的优势。我们的团队具有使用各种不同工具和方法的经验，这些工具是我们过去曾经使用过的，包括 IBM Rational 方法和工具包。我们本应该可以选择这些工具中的任何一种，然而，由于这个项目的特性，我们认为 Rational 方法和工具可以为我们提供最好的优势。

　　有了这个工具包，我们不仅可以从每个工具的单个能力上获得收益，还可以利用这个工具之间的良好集成获得额外的收益。基于这个项目的需求，我们选择了 IBM Rational 统一过程(RUP)，IBM Rational Application Developer (RAD)，以及 IBM Rational ClearCase 和 ClearQuest。这篇文章描述了我们是怎样利用这些工具来使我们的工作效率更高，同样重要的是，它还描述了一旦我们不能使用这些工具，这个团队将遭受什么样的挫折。

　　项目启动

　　我们的客户想尽快看到结果，但是他们对这个应用程序将看起来会是什么样子并没有一个清晰的想法，或者说对所做的一切都没有清晰的概念，他们只有强硬的时间限制和他们想要达到什么要求，以及他们收集的一些必要的用例。他们问我们，“您们最快能什么时候开始项目的开发？”

　　除了客户所要求的一些挑战外，我们还需要考虑我们工作环境的灵活性。我们是一个地理位置分散的团队。因为在客户工作场所中只有很有限的空间可以被我们的开发团队使用，一些工作人员在 IBM 公司，一些则在家中进远程办公。将开发团队的全体成员都集中在 IBM 意味着我们可以迅速扩大开发环境（但是在客户工作场所中并没有已经设立好的我们可以利用的开发环境）。

　　我们利用 Rational 统一过程 (RUP)来开始我们的项目，因为 RUP 是一个非常适合这个客户的工具，它可以处理我们的最大风险，并使我们尽可能早地交付最高的价值。我们为 RUP 项目的每个阶段都严格限定了时间，这意味着我们可以精确地说明这个项目的时间进度表，每个阶段需要的资源，这样这个项目的成本就可以在每个阶段的末尾显示。我们的客户将会发现这是一个颇有价值的方法。

　　我们很快开始了这个项目的开发工作。我们的客户不想我们的开发工作等到全面的设计工作完全完成之后才开始。他们有一些需求，并且想看到可运行的应用程序代码，可以尽可能快地将应用程序展示给他们的涉众来看。RUP 是这样帮助我们的：我们在多个有时间限制的迭代中开发应用程序，这意味着我们要为每一次迭代规划好确定的起始和结束日期（连同一个良好定义的设有目标的计划）。我们在每一个限制的时间段里都交付一些新的成果，有时我们可能不能在这个时间段完成任务，那就将剩下的部分转移到其它的迭代中去完成。这样保持这个项目不断向前进展。

　　工具选择

　　我们不需要 IBM 所提供的 Rational 包含的所有工具，但是我们的需求让我们来选择一定范围的工具能力。

　　首先，我们想要一个能够帮助我们使用 Rational 统一过程的工具。有些团队成员对 RUP 并不熟悉。从理论上讲，RUP 是一个不需要安装就能够被使用的概念框架。但是 RUP 工具在帮助我们管理过程和识别关键角色、工件以及我们所需的关联关系中的确有极其重要的作用。这个 RUP 工具帮助我们理解和沟通这个团队的角色、任务和职责。

　　我们需要一个强大的集成开发环境（IDE）来对我们的代码进行开发和单元测试。我们选择 Rational Application Developer (RAD)来进行应用开发和单元测试，不仅仅是因为它提供了完善的功能，而是因为它支持我们其它工具的选择。

　　我们需要一个有效管理代码的方法。假定我们的团队是地理位置分散的，并且我们需要支持并行开发流程,那么拥有一个有效管理我们软件开发工件的工具是十分有必要的。由于紧迫的时间期限，我们需要一个工具来支持开发人员在下一个版本上进行工作，同时让其它开发人员对当前的版本进行交付。另外，我们想要一个集中的存储库来为这个团队管理代码。ClearCase 为我们提供了所有这些。

　　我们需要一个更好的测试和修复我们代码的方法。客户承担了许多测试的责任。不管怎样，我们在这个项目的整个过程中都执行了质量保证的测试任务。在早期，我们将应用程序交给顾客之前，我们的开发人员就利用 RAD 进行了最初的单元测试。后来，我们使用 Rational Robot 和 Rational Test Manager 来确保这个应用程序的良好运行。

　　我们需要一个有效跟踪缺陷和管理变更的方法。对于这一点，我们选择了 ClearQuest。我们可以利用 ClearQuest Web 工具来提供对我们分布式团队的访问入口。1 这个工具允许我们的团队成员在分布式的位置，仅仅通过网页浏览器就可以访问整个 ClearQuest。在我们将工作版本交付给客户并由他们完成测试以后，我们在 ClearQuest 中获得报告的缺陷，对它们进行评估并将它们分配给开发人员，然后再在随后的版本中对这些修正进行打包和交付，所有这些在 ClearQuest 中都有跟踪。

　　有了 ClearQuest，我们可以向我们的客户提供最新的项目度量，这是一种在项目快要结束时变得非常重要的能力，此时我们处于交付最终构建版本的压力之下。因为客户可以访问我们的 ClearQuest Web 工具和缺陷库，客户就不必购买他们自己的 ClearQuest，并搭建他们的基础构架。