|
WBS(Work Breakdown Structure)是项目规划的重要元素,我们在进行项目规划的时候,常常犯的一个错误,就是从直接选择一个项目发展的策略(或模型)(例如, Waterfalls、Incremental、Evolutionary,或者Spiral等),再设法套到项目里,然后从这个模型所规划的产出去订里 程碑。这种做法,以笔者的经验来说是不可行的。因为,不论是多大的项目,在产品上、技术上的决策,事实上远比决定项目发展策略来得更为复杂。因此,我们在项目规划上若是以过程为着眼,就算是采用的是Grand Design Strategy(亦即“瀑布式”发展过程),也将无法做完项目,因为你会陷在过程阶段划分的泥沼中,不知道项目的下一步该怎么走。而就在这当中,耗尽了 时间与预算。
WBS是产品导向的,透过树状结构的方法,将项目产品分割,直到可以管理的最小单位(但也不能太细,否则会使整合与管理 的成本升高)。接着我们就可以根据这些细分出来的工作项目元素,去估算工作时间、成本、所需资源、技术、相关风险。由于这些工作产品的项目是可以管理的,因此,我们也就可以从WBS转出产品的组态项目(CI)。另外,我们也可以经由WBS的阶层关系,了解各工作产品间的相互关系、工作次序等等。由此,我们 就可以订出整个项目工作网状图,并以每个工作的工时,订出项目的要径(Critical Path)。另外,每个工作产品都是以由上而下的设计、由下而上整合与测试的瀑布式开发方式产出。由于每个产品已经明确地划分出来,因此,可以很明确地指派出去给功能单位,或开发单位负责实作。而最重要的是,项目的成本就可以精确地计算出来。
产品在经过WBS划分之后,我们就可以预判 出项目的可能风险。以绩效要求为例,我们要求系统的整体绩效每分钟应能处理1000笔数据,如果没有以WBS来看,我们实在看不出来达到每分钟处理 1000笔数据的风险何在,但如果我们从WBS来看,我们会发觉,影响每分钟1000笔数据之绩效达成的风险,可能会有网络的问题、硬件的问题、数据库的 问题、系统架构的问题、程序设计的问题、甚至于使用者操作习惯的问题等等……。而种种这些项目都将会是项目管理的重要议题,相对于管理规划、技术规划、财 务规划、人力资源规划、风险管理规划等等纳入项目管理计划书的相对段落中。
从软件开发项目来看,初步的WBS是从功能架构转过来的(从产品的生命周期来看,是系统需求分析、系统架构设计等阶段的产出),对于获取者 (acquirer)而言,初步的WBS又会转成SOW(工作条款),通常厂商(supplier)拿到的案子应该是已经有初步的WBS。如果获取者无法 发展初步的WBS,那么,他们就该找另一个supplier来帮忙做这件事(找出系统的需求)。
当然,厂商拿到初步的WBS还是要再 经过一些确认及再发展的工作,将初步的WBS再向下展开至可以管理及指派给各产品组件开发小组作业的规模。这些被细分成为一个个WorkPackage的组件或工作项目,在执行时,就可以用生命周期的观点(划分成软件需求分析、软件架构设计、软件细部设计、程序编码与测试、软件整合......)来划分其发展的阶段。以协助进度的掌握及报告。
当然,有些标准文件,例如ISO 9001及ISO/IEC12207会提醒你在发展阶段的时候,要找一个适用的生命周期模型。这个工作对于发展初步或细部WBS都是有帮助的,因为有些隐含在产品发展期中的工作,可能是看不到、想不到的,例如,功能组态稽核(FCA)、物理组态稽核(PCA);另外,就是生命周期模型也会协助定出所谓整品的整合策略、交付时程、以及交付项目。但是如果仅从软件生命周期过程的阶段来划分WBS,则是会有风险的(这是个人先前有应用的经验,因此不再建议用这种方式),因为你定出的工作 项目会是:系统分析、系统架构设计、软件需求分析、软件架构设计......,然后定出他们的duration,这样做似乎是把系统开发的工作通通列入 了,事实上并非如此,因为还有技术上的复杂度、相关的风险而产生的其它工作事项及产出,例如风险管理计划,另外就是一些像产品组件的make-or- buy策略(哪些组件技术要自己开发、经由教育训练获得技术移转,然后再发展自行发展产品组件,或者根本就是用COTS产品来代替)、以及相关的项目规划 及执行的作为,你可能就没有办法在先前就考虑到,而且,这些多半是因为交付的产品或服务需求特性所引起的。
有关于您所指WBS工作项 目元素彼此没有关连,无法安排其先后顺序,其实这是两个层次的问题,以您所提的人事系统为例,系统被展开成为五至六层的WBS及组件之后,你会获得的东西 除了工作项目之外,当然还有组态管理的整个架构,你可以从中挑选出要纳入构型管理制度中严格控管的项目(这段是题外话,但的确就是如此),另外,划分时, 有个原则:“有拆解出来的工作,就会有将之整合的工作”。而彼此先后的关联,是会受到合约要求的影响,例如,甲方要求先交付系统的哪些功能,这些功能要先设计、实作、整合及交付;会受到组件设计的自然律的影响,甲功能与乙功能之间需要丙接口才能够运作,要先发展丙接口、甲功能、还是乙功能,这也许又与您的 资源及人员技能水平会有关联;会受到测试策略的影响,例如采用的是由上而下、由下而上或是骨架式测试策略?外界环境的影响,例如,某些开发中会使用到之软硬件组件交付的前置时间(lead time)(向其它的厂商采购,运用在项目的产品当中)....,这些都是工作间关连的来源。
在 实务上,有了WBS之后(从功能架构转出,以及生命周期模型的工作要求与产出),将WBS映对至ISO/IEC 12207主要生命周期活动与工作、CMMI的工程PA、项目管理PA、支持PA中的SP;或ISO 9001质量管理制度第7章产品实现部分的要求项目,就可以汇整出整个项目全部的工作项目(tasks)。此项工作可以使用WBS与软件生命周期工作矩阵 交叉考虑而达成。相关做法个人于2003年4月份有关于ISO/IEC 12207在项目中的实践方法研讨会中已经说明。
有关于如何导出项目的WBS可以参考这份文件:
MIL-HDBK-881.pdf
(683.07 KB, 下载次数: 23)
,这份文件也是SEI在CMMI中谈项目规划时,对于WBS所参用的文件。
[ 本帖最后由 step365he 于 2008-4-12 19:28 编辑 ]
上一篇:林锐系列之集成化软件研发流程IDP5.0--第3章 IDP营销过程 下一篇:软件质量管理体系概论 |
|