规模，工作量，资源和工期
软件项目的复杂性就在于这几个因素间基本都没有简单的线性关系可寻。在项目过程不成熟或积累的历史数据不够的时候，慎用直接估算规模的方法，因此及时估算了规模也不清楚团队的实际生产率情况，无法根据规模推出具体的工作量。在这种情况下一般可以直接估算工作量，在项目进度跟踪过程中再收集产出物的规模数据以积累历史数据，方便后期建立相关的预测模型。 转自项目管理者联盟
功能点和代码行是可采用的规模数据，但采用代码行时候往往无法区分不同的代码类型本身往往具有不同的复杂度，对于逻辑层实现算法的代码和UI层实现简单完整性代码，虽然可能相同的代码行，但其复杂度不同将直接导致工作量的不同。对于任意一个功能点的开发基本都会涉及到DB,逻辑层和UI代码，因此可以给出一个综合的代码生产率数据，然后根据该数据到计算工作量。
项目管理者联盟文章
当新项目的规模比历史项目规模大几倍的时候，往往工作量会成指数级增长，在这种情况下要谨慎采用原来的线性比率关系。可以借鉴Cocomo模型来估算项目的工作量和项目工期。当预计出项目工作量人月后，最好能够根据历史经验和模型来预测在不考虑人力资源限制情况下项目可以完成的最短周期。虽然这个时候还没有考虑活动任务排序和资源约束，但基本可以得出一个经验数据。
WBS分解和估算的关系
项目在做详细估算的时候往往项目周期已经确定，因此为了可以满足进度WBS的分解粒度和进度的安排就至关重要了。比如在开发阶段现在有四个人可以进行并行开发，这个时候WBS最好能细化出四个可以并行的任务,当发现预排的进度无法满足要求的时候，需要再投入4个人，这个时候就需要WBS进一步分解以满足8 个人能够同时进入并行开发。当WBS分解导致后期集成工作量超过并行节约的时间时候，基本就到了进度能够压缩的极限。所以WBS和估算没有完全的先后关系，分解后进行估算，在估算过程中又在调整和分解WBS。 项目经理圈子
当项目人力资源很固定的时候，WBS分解更需要按现有人力资源情况进行考虑和分解，这个时候分解的粒度最好和项目可用人力资源匹配。总体原则仍然是前紧后松，让项目人力资源在项目一开始就能够完全动起来，而不是要漫长的等待前续工件和任务。
当考虑了人力资源仍然无法满足进度要求的时候，需要考虑我们采用的方法论，如是否可用增量迭代的方法替换瀑布模型，如果可以则需要完全根据增量迭代思路重新分解WBS，对于采用不同生命周期模型情况下WBS往往存在较大的差异。 blog.mypm.net
当以上仍然无法满足进度要求的时候，我们可以考虑对过程进行裁剪，重点保证对产品质量又重大影响的核心过程元素。当进行过程裁剪仍然无法满足的时候，你需要考虑的是人的因素，去寻找开发生产率比一般人高5倍以上的开发高手，而不是在明知WBS无法细分的情况下继续往项目里面投人。 项目管理者联盟
此文章共有2页 1 2 下一页
文章来源：中国项目管理资源网
|
Leadge.com首页 > 知识库 