|
我们的项目大部分是数据库四轮马车的操作(查询、增加、修改、删除)，功能点法从比较高的层次对这些工作进行抽象，有一套严密的规则可以让你将需求分解成一个一个的功能点。代码行法思路也类似，不过分解的结果是代码行而已。但一般来说代码行与软件的实现技术相关度太大，大家会更加偏爱功能点法。项目管理者联盟
功能点法和代码行法有比较长的历史，也有很多详细资料，大家可以去查阅一下。这方法理论上很理想，但实践效果很差，我还没有见到一家能成熟应用并且取得比较好效果的公司。功能点法和代码行法有这样的一些难以解决的问题：项目管理者联盟
1.只适用于数据库四轮马车的操作的项目，高技术含量、创造性高的软件不适用，如游戏软件、计算机负责计算与决策软件等。PgMp.mypm.net
2.我们绝大部分项目是需求不明确、设计不明确，并且工期很赶的，这两个方法都无法适应这样的现实条件。需求不明确基本上无法得到软件规模，建筑工程为什么能做到，是因为需求和设计都十分明确了。项目管理者联盟
3.两个方法的规则都很详细，要花大量时间学习和实战才能掌握。项目管理者联盟
4.由工作规模导出工作量这样的思考方式，难以适用于软件项目。项目组还是习惯列出具体的任务，逐条任务估计时间，而且只有这样的工作方式才能让项目组感觉更加踏实。service.mypm.net
Dephi估算法是比较符合大家实际工作习惯，也是比较容易掌握的估算办法。项目管理者联盟
Delphi法的大致方法如下：项目管理者联盟
1.找几名资深专家，一起对项目进行WBS，把项目的工作分解为十几条最多二三十条的工作项。项目管理者联盟
2.全部专家各自估计每条工作项的工作量，并向其他专家阐述自己的理由。项目管理者联盟
3.第一次各专家估出来的结果可能差异比较大，每位专家听取别人的意见后，重新估算。转自项目管理者联盟
4.按照上述办法，各专家反复估算几次，一般次数就是2-4次，各专家估计的工作量会越来越趋近，这个时候取全部专家的平均值。项目管理者联盟
普遍认为各专家的经验与知识水平会严重影响结果的准确性，而我的实践经验是：应该让项目组每个人自己来估算，也就是让大家来当专家，在这个基础上可以再增加一两名来自项目组外部的专家。项目管理者联盟
有时候觉得估算这个问题搞得太复杂了，各式各样的方法是不是太夸张了?其实最简单的方法就是让负责该项工作的人自己来估计工作量，微软的由底而上的估算方法就是这样做的，可谓返璞归真啊!项目管理者联盟
微软由底而上的估算方法大致是这样的：对项目各项工作进行分解后(即俗称的wbs：work breakdown structure，工作分解结构)，每个任务落实负责人，由负责人对自己的任务进行估计。这个办法有以下好处：项目管理培训
1. 最终该任务是由这个人来完成的，他估计多少时间才能做完，这个时间才是最接近实际的。talent.mypm.net
2. 负责该任务的人进行估算的时候，肯定需要认真思考这个任务的风险，需要做哪些具体的工作，这样更容易在未开始工作之前就发现更多的潜在问题。相反如果由项目经理来分配时间，这个人就可能不会去思考这个任务了。bbs.mypm.net
3. 做这个任务的人会有被重视和尊重的感觉，他会很重视自己承诺的完成时间，并且想法设法按时间完成。这样会减少很多项目管理时间，因为每个任务负责人都会主动地跟踪好自己的工作。项目管理者联盟
其实微软这个方法根本就没有什么特别，所有正常人都可以想到这个方法，但仍然有很多人去追求那些不太靠谱的估算方法。项目经理圈子
这个方法还是有这样的一些问题的：转自项目管理者联盟
1.有人会估算偏小，比方他说需要5天，但往往10天还完不成。项目管理者联盟
2.有人估算过于保守。项目管理者联盟
3.项目的进度要求就是很紧，基本上你必须在指定时间内完成，估算显得毫无价值。talent.mypm.net
第一个问题是比较常见的，但我们要这样想：估不准也比不估算好，估算偏差哪怕超过100%，也比不估算好，至少有个谱。项目管理者联盟
大家是会进步的，估不准往往是对任务和自己能力认识不到位，要让大家不害怕估算，只要敢于估算，问题才会暴露出来，才能持续进步。项目管理者联盟
|
