David Kohrell 在2005年2月的 Rational Edge 期刊上指出,Rational Unified Process,® 或者称 RUP,®为项目的推进提供了一个灵活的过程 -- 从先启阶段,经过细化阶段、构建阶段,以及产品化阶段 -- 给予指导和说明。本文特别关注RUP如何同样能为小项目和团队提供指导。另外,在用于敏捷开发环境的能力方面,我们也观察了RUP和其它指导(比如,项目管理协会的项目管理知识体系,或PMBOK®)。
小型项目和团队的背景
通常看来,如果被安排来管理一个小项目,也就意味你是新人或者你已经落伍了。大家都认为“一流的资源”应该被分配给大型的、企业级的、全特性的发布项目。这种认识是错误的,让我们来看一下市场,特别是2001年 .com 破碎之后,小型项目和敏捷团队的时机成熟了。公司在一个月、一个季度、或者一年之内完成的项目越小,那么,产生收益、减少成本、或者拓展品牌和价值的机会就越多。
明确以下一些定义之后,我们继续这个话题的讨论:
- 大型项目:预算超过$500,000,团队规模为十三人或者更大,项目进行时间超过一年。
- 中等项目:预算$100,000-$500,000,团队规模为六到十二人,项目进行时间为六个月到一年。
- 小型项目:预算低于$100,000,团队规模少于六人(包括在该项目和其他项目之间共用的团队成员,以及每日必须的人员)。项目进行时间少于六个月。
- 变更请求:预算低于$50,000的所有任务都是被一个人在几周之内来完成。
RUP同样适用于小型项目
在 Michael Jordan、Greg LeMond、Tiger Woods之前,Bo Jackson统治着整个体育世界。19世纪80年代后期流行着这样一句话:“Bo 懂得篮球、足球、投资”。
过去的三个多月里,在研讨会或课堂上,我引用Bo Jackson的例子来反驳RUP“不适”小型项目的错误观点。我认为RUP“适合”于所有类型的项目,这让很多人都感到惊诧。就我在过去几年使用RUP的经历而言,它能够用在所有大型、企业级项目,并且组织变更请求。它不仅仅是一个可有可无的方法论。
下面是人们经常提起的用来说明“RUP不适用于小型项目”的两个方面,我将逐一解答这些问题,来证明他们的看法是错误的:
- 敏捷方法考虑到迅速和紧密的增加或者阶段;减少开销;并且确保开发人员与客户之间的紧密联系。
我的回答:敏捷方法以及类似的方法(SCRUM,Paired Programming)在软件构建中是革新的、有用的。然而,在RUP中也可以使用敏捷方法。那些轻量级的方法可以很好地在新系统的构建阶段、解决方案,或者程序中得到运用;但是仍然需要管理其它三个阶段的上游和下游活动,比如决定需要做什么(需求)以及操作环境将受到什么影响(发布管理)。RUP并不关注先启阶段、细化阶段、构建阶段和产品化阶段所有业务原则的使用,事实上,它是为这些活动提供了一个最佳框架。 - RUP以及类似的指导,比如PMBOK, 软件工程协会(SEI)的集成的能力成熟度模型 (CMMI),或 UK 的 IT Infrastructure Library (ITIL)标准给小型项目强加了一些不必要的过程。他们其实仅适用于一千万以上的大型项目。
我的回答:方法、知识体系,或者成熟模型不会强加过程。他们只为估算需要做什么,以及如何做得更好而提供一定的基础。“如何做”这部分是由实施组织来决定的。
PMBOK并没有规定2000版本中的39个过程或者2004版本中的44个过程在项目中都必须得到使用。它是一个知识体系,为项目管理者可能遇到的各种情况提供了一个起点。例如,它有助于定义组织的变更控制过程应该包括哪些内容。现在,项目管理专业人员(PMP®)在项目管理协会(PMI)监督之下,当然必须遵循PMBOK。PMI提供PMP资格认证,这样,聘用专业人员的组织机构就能够放心该专业人员懂得PMBOK。但是这并不意味着专业人员必须在每个项目中都使用到PMBOK的每一项知识。
SEI的能力成熟度模型(CMM)和CMMI从五个级别来评估并验证某组织的成熟度。按照SEI的规定,很清楚地评估和验证一个组织做什么,以及在某种程度上,他们如何完成。然而,这并不是规定一个“可重复过程”(二级)必须利用过程、工具和组织角色来完成。
相似地,“RUP的精髓”-- 以及已开发的许多实施RUP的工具 -- 培养逐渐细化的理念,即增量开发的本质。RUP的观点是组织应当设计并构建部分而不是全部解决方案,需求是已知的。现实中,验证某特色或者系统是“受人欢迎的应用程序”(比如,想法),还是“失败”(比如,Coca-Cola's New Coke,自1984)的一个最有效办法就是将产品交付给用户。
应用RUP,探寻SEI CMM/CMMI评估,或者使用PMI PMBOK时,最佳实践是成体系地使用这些向导。例如,你应该首先懂得业务需要(a.k.a 需求),从本质的用例开始,基于那些用例和UML的强大功能进行建模。在2004年《The Rational Unified Process Made Easy》一书中,Per Kroll和Philippe Krutchen很好地描述了这个方法:
...也许,人们采用RUP时最常出现的错误是使用太多工件或者做太多活动。过量使用RUP将会降低你的开发效率;RUP过程框架类似于自助餐,如果你还想保持健康和快乐,那么就不能吃光所有的饭菜。 1
RUP应用在小型项目环境中
现在,让我们举两个例子,来验证RUP在小型项目环境中的使用。首先是公共部分项目 – 更新一个使用了十五年的打印工作过程。第二个项目涉及将RUP用于创建一个学习管理系统入口,称为“TAP University”。两个项目预算均低于$100,000,由小型团队在90到120天以内完成。
打印服务更新项目
Bill Wonch,本文作者之一,是 Nebraska 州劳工部的兼职讲师和软件架构师。他最近负责更新一套已使用20年的程序,合计并打印出成千上万份报表和帐单,以下是他的故事。
这只是一个小项目。但是,它却是系统的核心,称为 Mix,而且,必须支持部门内其它系统的更新。这个大框架说明了RUP中可交付的软件体系架构文档 -- 理解每个项目、变更命令,或者任务都影响着工作的进展,如同高尔夫球的每个线都与其它相关联一样。
当即有系统需要更新,以便与公司现代化的失业保险利益支付系统一起运作的时候,“Mix更新项目”开始了。原先的系统Mix是用COBOL构建的,运行于一个主机系统上。“Mix”并不是一个简称;1987年起名为“Mix”是因为它混合了进行大量打印工作的主框架数据和窗体。
新系统将在Java中使用成熟的商业化(commercial-off-the-shelf,COTS)应用和组件来构建,生成必要的XML文件。
项目的先启阶段,我们为系统定义三个参与者:
- 抽象应用类,表示使用即有Mix应用程序的所有系统。
- 操作类,表示员工管理打印的操作。
- 业务使用者,即使用该文档存储库的人员。
如图1所示,每个参与者均与相应的用例关联。记住这些参与者和用例,我们可以为更新系统选择最佳的商业应用。通过这个信息,我们可以精确地计算出更新所需的成本。那些是项目合同与计划中有限的内容。基于此,我们可以估算出项目的资金。
图1:在项目先启阶段为系统定义的三个参与者
根据先启阶段确定的计划和捕获的用例,RUP指引着项目的进行。RUP精髓的一部分就是可以将需求划分成不同的组,并根据需要将各组归入先启、细化、构建和产品化阶段。Mix系统中包括106个打印程序,从先启阶段到产品化阶段,将这些程序分成几个组,然后再单独迭代地处理,经过四个阶段的每次进展都是低风险的(验证方法),然后再将大大小小打印程序集成。以上做法是有意义的。
TAP University
TAP (Technology As Promised) University是一个在线学习管理系统项目。TAP University的目标是延伸这种由TAP伙伴提供给公司客户的面对面培训,并为公司、公共用户及学生提供在线服务。2
这是一个小型的项目。改进一个开源的学习管理系统。 该项目的可视化文档草案于2005年2月22日提出,项目计划完成于2005年5月3日,包括需要的资源、成本和范围。表1描述了每个迭代和用例。
表1:TAP University项目的迭代和用例
从设想到实施,这个项目只有不到六个月的时候;从正式的项目工作开始到功能的完成,从项目计划到支持这个产品仅花费了90天。
这里涉及到了8项资源;估计完成该项目所需的小时数为652。成本主要是“人力资本” -- 低于 $15,000。
RUP在本项目中的应用主要包括以下两方面:
- 在迭代和用例的组织方面,RUP已经提供了一个框架。表1所示的用例与包含MS project 进度表输出的两页项目计划共同构成了文档文件。CVS 1.12 和 LMS 充当共享库的作用。
- RUP指导我们如何构建和产品化,甚至在仅仅已知80%需求的情况下。例如,有三个可选的电子商务解决方案有待评估。决定使用哪个电子商务工具并不排除在迭代1众的产出。这意味着公司客户能够立即地使用迭代1。
结论:RUP的确也适合于小型项目
文章中提到的两个小型项目呈现了不同类型的组织的需要:大型公共部门办事处与新近发展起来的小公司。项目的关注点也不同:更新使用15年之久的打印集合工具和在线学习管理系统。两个项目共同之处是,他们的规模都很小,并且RUP都可以提供一套严格而灵活的方法。
Gary Pollice 等几位作者在《小型团队的软件开发》一书中为小型项目的管理者提出了一些有价值的建议:
面对不断的变化,项目团队如何掌握怎样应对变化才能获得最大的生产率?我们认为,关键在于尽可能多地学习不同技术,学习如何有效地使用工具来支持不同的技术,以及决定联合起什么作用和什么时候起作用。 3
RUP以及各种支持RUP的工具,确确实实也“适用于小型项目”,另外,项目管理者应懂得如何最好地发挥RUP的优势。
注释
1 Per Kroll and Philippe Kruchten, The Rational Unified Process Made Easy: A Practitioner's Guide to the RUP, Addison-Wesley: 2004, pp. 244-245.
2http://www.tapuniversity.com/
3 Pollice, Augustine, Lowe, and Madhu, Software Development for Small Teams: A RUP-Centric Approach, Addison-Wesley, 2004. p. xix.
参考资料
- 您可以参阅本文在 developerWorks 全球站点上的 英文原文。