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