|
|
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营销过程
下一篇：软件质量管理体系概论 |
|
service@step365.com
0571-87357690
狗仔卡
发表于 2008-4-12 19:16:53
QQ好友和群
QQ空间
腾讯微博
腾讯朋友
收藏
转播
分享
淘帖
支持
反对
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡
发表于 2008-4-16 14:21:46
