结论  

    RUP 是一个良好的开始方法。它是一个非常好的框架，可以为福特这样的公司提供所有工具和必要的信息。这个框架是非常容易定制以满足我们的需要的。我们发现的一个重要的事情是集成是关键。 RUP 是一个打包的解决方案。如果你将它带入你的组织，你仍然必须做一些工作。你不能直接为一个项目使用它。在福特信贷公司我们拥有自己的项目管理过程和其他必须集成的过程。定制是重要的。最重要的是，对于我们来说指导是制度化象 RUP 这样的过程的基本要素。

    我们得到的下一个结论是保持过程的简单性。我们有项目管理、六个 Sigma 、拥有自己过程的服务团队和 RUP 。我们应该尽量简洁、清晰的显示这些过程的连接点，这样可以产生更少的产物和有限的文书工作。

    在最后的分析中我们觉得与你正在通过得到有价值的反馈支持的团队享受你们的成功乐趣是重要的。

    网站演示 — 关键的特点

    USDM 的一个关键特点是开发案例，一个我们用来为项目配置过程的重要产物。我们识别出了三个不同的项目类型：构建新应用的项目；对一个应用系统范围进行增强的项目；修改 bug 的维护项目。

    使用用例模型，我们识别出对于哪些个迭代哪些用例要被开发。然后我们进行了初始的计划，计划中安排了迭代的时间。这就是我们如何开始每一个项目的。我们了解项目的范围，然后通过对时间线和迭代如何被定义的理解来创建定制的开发案例。然后开发我们的工作计划（进度表）。

    基于项目的类型，我们建议哪些产物应该被使用。这是一个协作的团队工作。作为指导人员，我们与团队站在同一立场上，并讨论项目的需要。此外，在每次迭代和阶段的结束我们来确定被使用的产物是否是有价值的。如果产物没有提供价值，我们将停止使用它。

    USDM 的另一个特点是为不同类型的项目工作流程的定制。对于增强或者维护项目的工作来说，你可能仅仅需要一定的活动；因此你可以重用已有的产物。例如，在增强路径的活动中，“设计用户界面”，我们也许只是检查已有的 GUI 以确定用户的交互，从而了解增强如何能够被集成到这个流程中。对于所有的工作流程或者活动，我们为增强类型的项目识别关键的事情。

    过程的下一个关键特点是一个服务团队连接点的 Web 页面。我们为福特公司和福特信贷公司各建立了一个页面，因为我们每个公司有不同的服务要求。再一次说明，服务团队是提供公共资源的项目外的组织。服务团队的例子比如 DA/DBA 、可重用的团队、框架架构师、构建团队和生产管理。当应用团队使用服务团队连接点网页时他们了解在过程中服务团队应该在什么时候被联系。

    USDM 的另一个关键特点是针对过程改进指导人员的使用。指导人员能够带来很大的帮助，因为他们能够始终如一的和不断的提供关于什么产物正在被使用、什么过程正在被使用和什么没有被有效的使用方面的反馈。我们就像记录变更请求一样记录了被建议的改进。然后变更控制委员会对于变更请求说可以或者不可以。如果答案是可以，我们就实施变更。

    此外，我们保存了一个指导请求日值。当一个指导人员被分配到一个项目中时，我们记录一些信息，比如指导人员被估计参与项目指导的时间和针对项目的指导人员的资源分配。我们计划使用这些信息进行度量。我们正尽力的构建允许我们执行趋势分析的统计数据。我们希望使用这些信息来改经我们的过程。我们也从我们的用户得到过程改进的建议。他们使用一个简单的网站反馈表单来提交建议的改进。然后这些建议被提交到变更控制委员会。

    对于培训，当团队开始一个项目时，我们为他们提供几个过程的展示。我们没有打印的过程指南。以前，福特公司的开发过程包括巨大的活页封面，有时是几卷的纸张。这一次我们决定将过程的每一件事情发布到网站上，并提供可下载的页面。这是节约成本的方法，但它的更大的好处是我们每两个月就要更新一些东西。人们可以访问这个网站，并可以得到他们需要的更新材料。我们认为这是一个有效的沟通过程和在过程中交流知识的方法。

    USDM 过程的另一个特点是指导人员的网站。这个网站为我们的指导人员收藏了信息，包括一个文档化的指导过程。过程列出了当指导人员参加项目时他们要做的事情。他们要做的事情从初始阶段就开始了，也包括其他三个阶段。这是一个我们的指导人员要遵守的以在指导工作中促进一致性的指导方针。我们也有一个指导认证程序，新加入的指导人员必须通过这个认证过程以确保他们理解了福特公司和福特信贷公司特定的组织过程，从而使他们能够一致的指导我们的应用团队。

    我们的 USDM 网站非常类似于 RUP 的过程工具，但用起来更加简单。在 RUP 中有更多的特性，我们主要是为我们的指导人员使用这些特性作为辅助的工具。我们的所有的工作产物和模板都存储在 USDM 网站上。

    问题 & 解答

    你什么时候开发 Web 网站，你使用了 WorkBench 或者 任何其他的 Rational 工具了吗？

    我们唯一使用的工具是 RUP 的过程工具。我们没有使用 WorkBench 或者其他的工具。我们开发了我们自己的 Web 网站； RUP 不在下面。我们作为方法专家在我们的桌面是有 RUP ，但是团队并不能访问它。

    在未来你将包括遗留的、非面向对象的开发吗？

    目前来看，我们还没有这方面的计划。组织，福特公司，也有另一个 SDM ，被叫作 Classic SDM ，我们使用它来进行我们的主机系统和瀑布型的开发。那就是我们现在的计划，虽然我们有对 USDM 进行一些变化以使我们能够为两种开发使用我们的基于 RUP 的过程的想法，但是从策略上看还不能立即实施。目前来看，我们只是对我们的使用了对象技术的开发项目使用 USDM 。

    在应用 RUP 后，你看到了在时间和质量上的改进了吗？

    我的确看到了在质量上的改进。项目按时完成了，客户对项目更加的满意了。商业客户自始自终的被包括在项目中。他们能够更早的在细化阶段对系统进行测试，这导致在项目的后期有更少的痛苦。

    什么样类型的信息被用来定义方法论的成功？

    我们有一个正在进行的工作来定义一个能够证明价值和捕获一些其他关系的信息的度量模型。我们目前的基本反馈来自于我们的客户、我们的服务团队和我们指导管理的会议。此外，在项目结束的时候，我们有一个总结经验教训的会议，在会议中我们可以直接得到回复。我们有一个提交给项目经理和项目团队成员的评估表格，他们能够在过程和指导工作中提供反馈。

    在时间上你的最大挑战是什么？

    这个过程是非常简单的，并且很多人都想用它，但是我们没有足够多的支持人员。因为在福特信贷公司，一个非常大的组织，这个过程正慢慢的变成主流，我们没有足够的支持服务来为所有需要帮助的团队提供支持。第二点是我们只关注在 基于 OO 的项目、使用 J2EE 平台的项目和使用组件架构的项目上。如果你正工作在一个大的组织中，所有数据都被存储在主机系统中，那对我们来说将这个过程扩展到遗留类型的项目上挑战是巨大的。

    你为什么将开发和部署分离开来？这样做对我们有什么意义？

    我们做的第一件事是开发方法论。我们用了六个月开发这个方法论，然后用了另外五个月将它部署到我们的组织中。我们的 Web 网站在开发项目结束时是可得到的，然后在部署项目期间我们建立了指导服务。我们确定了指导的过程是怎样的，培训了我们的服务团队，并且与我们的服务团队达成了协定。

    你指导的项目使用什么类型的迭代时间周期？
   
    这依赖于项目，但是我们尽量的保持那些迭代在两周到六周，迭代的周期也依赖于什么被包括在项目中。指导人员与团队一起来帮助确定迭代的周期。