在 Rational Unified Process(RUP)中对许多工作产品、任务和角色排序时,您可能会自问这些问题:
-
我需要这个吗?
-
如何对所有这些项排序以确定我的项目所需的项?
-
RUP 不是明显只适用于大项目吗?
定制的主题回答了所有这些问题。
软件项目用于生产产品。好的流程使项目能在预算内按时生产出满足其项目干系人需要的产品。关于其他信息,请参阅 工件:产品。
好流程的关键在于坚持主要原则的同时尽量将流程定制得简单。
定制流程时应考虑此处所包含的指南。概念:RUP
定制中提供了更详细的指导信息。
许多项目的常见问题在于:通常过分注重某个特定区域,以致他们陷入该特定区域的细节中,而无法确保他们能够很好地了解在生产高质量产品的整个流程生命周期内所涉及的“关键”元素。
在着重于任一特定问题域之前,轻松地处理流程中的所有关键元素,这通常是较好的办法。
一旦某个质量软件流程的框架到位,项目就可有效地着重于已确定为造成问题的主要因素的某个特定区域。通过确定项目风险和对这些风险进行排序并针对这些已确定的风险确定早期风险减轻策略,进行此项选择。
不要包括无法明确判断的任务和工作产品
善意的项目经理或流程工程师可能有关于乐意拥有的度量值、控制、报表等的很大一个愿望名单。但是,任务和工作产品都是要花时间和金钱的。这些成本中有些(例如环境工具集的日常交互)是可能看得到也可能看不到的,但对于标准任务,它们都只是折合为低生产力。
您必须区分愿望名单中的关键流程需要,并确定收益是否超过成本。
将开发人员与流程隔离
您可能有经过高度培训的员工,他们具有设计、实施和测试方面的重要技能。不要让他们每周都花数小时来填写表格、改进文档或是使用难以控制的工具。如果需要这些任务,则考虑由合格的支持人员来完成这些工作。
使正式中间工作产品最小化
中间工作产品(不用作最终产品的那些工作产品)的形式没有任务那么重要,但还是需要生产中间工作产品。只要它们起到应有的作用,其外观以及用于构建的工具是不重要的。正如 Dwight D. Eisenhower
所说,“计划算不了什么,规划才是一切。”
人们易犯过快给工作产品定形的错误。工作产品的早期版本通常很快得到改进,而在探究其牵连因素的同时,它们以多种表示形式在一段时间内保持可变性。 正式文档可能会阻碍该流程;您会浪费大量时间来完善很不必要的工作产品。
手绘图和索引卡上的简短描述对于工作产品的早期阶段通常就足够了;而对某些项目来说,这可能就是所有的要求了。
可对工作产品进行定制,使其可以任何形式进行维护。例如,“远景”文档可保存为 Web 页面,“项目计划”可保存为 Microsoft Project 文件,而“风险列表”则可保存为 Rational RequisitePro 需求类型。
在可能时生成
某些项目花大量时间通过手动剪切和粘贴信息来填充正式文档的模板。而考虑使用诸如 Rational SoDA
之类的工具从源文件生成所需的文档,或协商出更为简单的方法来提供相同信息,例如使用 Rational
Rose Publisher 生成基于 Web 的设计模型。
在许多情况下,由于环境中提供的信息不明确,您完全可以跳过某个工作产品。例如,您可能只想提供已定制的 Rational RequisitePro
项目以及适用的需求类型和可跟踪性(而不是通过生成“需求管理计划”部分来列出需求类型的属性),然后由有关的各方来查看整个项目。另一示例为,向有关各方提供只读版本的 Microsoft Project
文件,而不是将图形复制到单独的“软件开发计划”中。
使用 Web
有用的工作产品是指传达有价值的信息的工作产品。对于需要这些信息的人而言,这些信息应该随手可得。 Web 技术就是针对该用途的一种优秀机制。 如果在 Web 中提供需求、设计和实施,则无需生成大量很快就会过时的书面文档。
使用集成工具
选择适用于流程的工具,并根据工具来定制流程。期望的结果是一个好用的流程和工具集。与未集成的工具相比,集成的工具通常提供更高的一致性、更有参考性的度量值和报表。
定期重访流程可优化流程并减少其复杂性。如果您的员工不确信流程中的每一步骤均为最终产品提供增值,那么流程就有可能中断。
在保留最佳实践的同时进行定制
RUP 鼓励定制。但是,定制并不表示许可完全忽视流程。RUP 的实践中体现了 RUP 的基本要素。 根据需要定制任务和工作产品时,应遵循这些实践的主旨。
|