论在瀑布式开发模型中使用项目管理方式的不合理

论在瀑布式开发模型中使用项目管理方式的不合理

 转载请注明出处，作者：Lingch

 

1.        软件开发的一般过程

对于传统的软件工程来说，教科书上一直教导我们软件开发要分为需求、设计、实施、测试等阶段进行，这种划分逐渐也被人们接受并广泛认同，形成经典的瀑布式的开发过程，瀑布式开发过程归纳出了从需求提出到形成最终软件产品的一般过程，他是正确的。

 

2.        项目管理过程

项目式管理是对一次性执行的任务的一般管理方式，通常一个项目被分为多个阶段分别计划和执行。项目式管理一切讲究计划与控制。

2.1.       任务分解

在项目计划中，最终的工作任务被分为一些较小的任务组成，这些较小的任务又再次被分为更小的任务组成，直到任务能够被有效管理无须再细分，如此形成一棵树状结构的任务树，称为工作任务分解（work breakdown structure, WBS）。由于WBS是由项目总目标分解而来的，因此可以认为WBS每个叶子节点的任务完成也就意味着项目任务目标达到。

2.2.       项目的工作量估算

项目的总工作量估算是基于WBS的，一种可行的办法是自下而上估算每个小任务的工作量最后汇总为整个项目的工作量。

2.3.       项目进度估算

在得到项目的工作量数据后，对每项工作分配劳动力资源，每项工作的工作量除于劳动力资源即得到各项工作的持续时间，又自下而上汇总成项目的总持续时间。

2.4.       项目的成本估算

软件开发项目的成本很大程度来源于劳动力成本与软硬件成本，软件硬件成本属于固定成本很容易就算出来了，劳动力成本用劳动力单位价格乘于劳动力消耗得到劳动力成本，自下而上汇总又得到了项目的成本。

一切看起来都很美，我们知道要做什么了，也知道项目的进度了，同时成本开支也算出来了。

 

3.        在瀑布式开发中使用项目管理方法的问题

项目管理与瀑布式开发不谋而合，同样是分阶段，做计划，按计划顺序执行，因此很多项目也自然将瀑布式的各个阶段套用到项目中，以瀑布式开发的各个阶段作为项目阶段，在各阶段内分解任务，估算、汇总，问题就出现了。

3.1.       任务分解的不合理

对于一个项目来说，我们首先是建立WBS，建立WBS要求对项目总目标进行分解，直到任务能够被有效管理而无须再细分。所谓‘有效管理’，是对管理的目的来说的，很明显最直接的目的就是预测进度和成本。问题是：在需求工作完成之前我们怎么知道要做哪些事情呢，我们充其量也就能估计出需求阶段需要分析哪些需求，但在需求分析完成之前我们根本无法估计设计工作的任务组成，他可能需要设计一个服务器程序也可能不需要，他可能需要建立数据库也可能不需要，我们只知道他需要‘设计工作’，‘设计工作’显然不是足够有效管理的粒度。

3.2.       进度估算的不合理

前面已经讲到进度估算依赖于WBS，只有WBS细分粒度足够的时候进度估算才有精度可言，对‘设计工作’估算进度那偏差率就不是百分之一两百的事情了。

3.3.       成本估算的不合理

前面已经讲到软件开发项目的成本主要还是劳动力成本和软硬件成本，甚至一些纯软件开发项目只有劳动力成本。劳动力成本是与工作进度计划相关的，如果进度计划本身就不精确成本估算也必定不精确，相比起进度偏差来说，成本偏差带来的影响更加大，如果编码工作是外包的，有可能导致因为付不起外包费用直接终止项目。

 

4.        与其他行业的比较

如果项目式管理在软件开发行业有这么多问题的话，那为何项目式管理仍然这么受欢迎？这个问题可以与其他行业的状况对比一下。

从www.mypm.net的调查来看，项目式管理应用最广的是IT行业和建筑行业，建筑行业名声很大，建设部甚至制定了一系列行政指令和标准要求建筑行业执行项目式管理，而且似乎执行的非常好，据说估算偏差率在+-15%，预算偏差率达到+-5%，因此建筑行业的经验对软件开发行业是有一定意义的。

通过对比建筑行业的项目管理发现，建筑行业的图纸设计并不包含在项目管理范围内，建筑工程项目是在图纸设计完成后的施工过程使用了项目式管理。图纸设计为什么不包含到项目过程中去？因为图纸设计是一项不确定性很高的工作，他可能变化比较大，根据用户的需求不断修改完善，在图纸设计出来之前施工过程是没法估计的。对比起软件开发过程，在需求完成之前设计是无法确定的，在设计完成之前编码过程是无法估计的，根本的差异是软件开发项目中我们把需求、设计、编码合并到一个项目中去了。

 

5.        问题所在

很明显在一个项目中，后阶段的工作组成结构如果依赖于前阶段的工作成果的话，前阶段的变动必然会导致后阶段工作结构的变动，变动幅度甚至会被放大。项目式管理的一个主要优点是他的计划性和可预测性，过大的变动幅度使项目的预测效果大大降低，这时使用项目式管理就没法带给我们什么好处了，甚至误导决策，还不如不用。

 

6.        改良

IT项目的失败率和偏差率明显高于建筑项目估计与前面所说的原因不无关系。既然提出问题，就可以尝试探讨一下解决方法，可能的解决方法包括

1)        将设计与实施分离

学习建筑工程项目，将设计与实施分析，在设计阶段采用其他管理方式运作，在实施阶段采用项目式管理，这样最起码实施项目成功率会提高偏差率降低，但估计这样会跟建筑行业一样，将IT人员分为白领设计工程师和编码民工了（对应建筑设计师和工地工人），不过我认为这对企业来说应该是一件好事，因为现在的软件开发方式把设计与编码混在一起，实际上编码工作是把成本很高的设计师调去做增值很低的编码工作了，资源没有有效利用。

2)        采用其他估算方法

自底向上只是估算的其中一种方法，如果自底向上不可行，那就可以采用其他估算方法，如类比估算。因为最起码在需求阶段的任务分解还是比较准确的，如果企业有历史数据的话，可以通过需求工作的工作量估算结合需求阶段占整个项目工作量百分比的历史数据计算出后续工作的工作量，但这要求企业有比较丰富的历史数据，相信大部分企业没有这个数据。