1       估算的含义

1.1    估算,目标,承诺

估算:是对项目将持续多长时间,花费多少成本的预测;

目标:描述期望达到的业务的目的;

承诺:许诺载特定的日期之前以特定的质量交付规定的功能,可以比估算激进,也可能比估算保守;

1.2    估算,计划

估算是客观的分析过程,计划是主观的目标求解功能.

当有人要你提供估算值时,要确定他是期望你进行估算还是期望你给出如何达到这个目标的计划.

看到单点估算结果时,要问清这是个估算值还是一个事实上的目标;看到一个单点估算值时需要问清楚这个估算值的概率,因为任何一个单点估算值都与一个概率关联.

1.3    良好估算的定义

一个良好的估算方法应该在75%的时间内提供与实际结果相差不超过25%的估算结果.但是仅仅通过估算实践本身并不能获得准确的估算结果,还需要通过有效的项目控制.

1.4    估算与项目控制

海森堡不确定性:仅仅对事物的观察就会改变事物的本身,因此只有看到事物的表现时才会知道它的表现是什么样的,而不可预知它的表现;

项目中会受到各种各样的因素的影响导致对最初进行项目估算时的假设失效,但如果最终提供了与估算一直的结果,那么就说明这个估算是个良好的估算,所以评价一个良好的估算不能基于它的预测能力,而是要基于估算为项目成功提供支持的能力.

1.5    估算的真正目的

估算的首要目标不是预测项目结果,而是确定项目目标是否能够足够的现实.事实证明:如果初始目标与初始估算值的之间的差距不超过20%时,项目经理可能调节项目参数从而达到业务目标.

2       你的估算水平

大部分人的90%的置信度其实只有30%,所以除非有定量的推算方法,否则不要提供百分率的置信度,尤其是90%置信度.

避免使用没有依据的较窄的范围,确保估算值中的范围与你给出的估算值的置信度相匹配.

3       准确估算的价值

3.1    高估好还是低估好

3.1.1   反对高估的观点

如果项目被高估了,帕金森法则就会起作用:如果给一名开发人员5天的时间完成4天的工作量,他就会在额外的一天找些其他的事情做,另外的顾虑就是学生综合症:给开发人员太多的时间,他们就会一直拖到项目快结束的时候才匆忙完工,结果反而可能无法按时完成项目.

3.1.2   反对低估的观点

降低了项目计划的有效性;

从统计角度降低项目交付的可能性;

未做好基础工作导致项目的实际结果比名义上可取得的结果更差;

项目后期破坏性的变因导致项目实际结果比名义上可以取得的结果更差;

3.2    权衡各种观点

采用积极的任务跟踪和缓冲管理(即项目控制),而不是人为的降低估算值.所以不要低估,低估带来的损失比高估带来的损失可能更严重,应通过计划和控制来解决高估的顾虑.

3.3    软件行业估算的详细记录

行业数据显示:软件行业普遍存在系统性低估的问题,我们首先要让估算变大,才能让估算更准确.

3.4    准确估算带来的好处

更准确的显示项目状态:进度跟踪的最佳方法是将计划与实际进度进行比较;

更高的质量:准确的估算有助于避免因进度压力而导致的质量问题,软件40%的错误是由于进度不合理导致;

更好的于软件以外的活动进行协调;

更好的编制预算;

提高开发团队的可信度;

更早的获得风险信息:认清项目业务与估算结果存在不一致的含义:这是表明项目无法成功的高价值的风险信息.

3.5    可预测性与项目其他属性的价值比较

进度

成本

功能

对于很多业务而言:可预测性比开发所花的成本,时间或者具备的灵活性更有价值.

4       估算误差的来源

估算值中误差的来源可能是下面四个方面:

有关被估算项目的不准确信息

和被实施项目的开发组织能力能力相关的不准确信息;

项目过于混乱;

估算过程本身带来的误差

4.1    估算不准确性的来源

对于给定的特性,在如何说明,设计,和实现单个特性上的潜在的差异可以导致在实现时间上累积产生100倍以上的差异,大型特性集中有成百上千的特性,而每个特性都有这样的不确定性,其结果就会导致项目本身存在不确定性非常大.

4.2    不确定性锥

项目早期建立的估算值可能存在很高程度的误差,在初始阶段误差可能达到4倍,

软件估算的准确度取决与对软件定义的细化程度,定义的越细化,估算越准确.

减少估算值的可变性的唯一办法是减少项目的可变性.

通过估算值中使用预先确定的不确定性范围来考虑不确定性锥的影响.

由一个人估算”有多少”,由另一个人来估算”有多不确定”,从而考虑不确定性的影响.

在项目早期锥面还较宽的时候不可能做出有意义的承诺,高效的开发机构会推迟到完成那些让锥面缩小的工作后才作出承诺.

4.3    混乱的开发过程

常见的项目混乱:

一开始没有很好的研究需求;

在需求确认阶段没有与最终用户沟通;

导致代码中寻呼现无数错误的不良设计;

引发大量排错工作的不量代码实践;

缺乏有经验的人员;

不完整或不熟练的项目计划活动;

“首席女歌手”成员;

开发人员增加不必要的功能或采取不必要的方法;

缺乏自动化源代码控制.

Note:不要期望更好的估算实践能为混乱的项目提供更准确的估算,不可能精确估算一个失控的项目,作为起始步骤,消除混乱比改善估算更重要.

4.4    不稳定的需求

在运行良好的项目上中,会以一组初始需求集作为基线,然后根据该需求集的基线来估算成本和时间进度,在增加新需求或修改旧需求时,就要对成本和进度的估算值进行修正来反映这些变更,但很多项目会在需求变更时忽略了对有关成本和进度的假设进行更新,尽管增加了需求项目上看起来更合理了,但是项目还是被看作延误了.

如果所处的环境不能让需求稳定下来,就要考虑使用针对那些高可变性环境的其他方法:短迭代,scrum,极限编程,dsdm,时间框开发等等.

4.5    遗漏的活动

被遗漏的工作主要有三类:遗漏的需求,遗漏的软件开发活动,遗漏的非软件开发活动,

被遗漏的需求譬如安装程序,帮助系统,部署方式,外部接口等

被遗漏的软件开发活动譬如:新成员的准备,指导新成员,交接部署,安装,定制,参与技术评审,集成工作,维护修订控制系统,维护每日构建等等;

被遗漏的非软件开发活动:休假,病假,培训,周末,假日,所以在持续时间为数周的项目需要为休假,病家,培训,公司会议等开销留出空间,

4.6    没有理由的乐观主义

开发人员给的估算值一般是过于乐观,

软件估算会受到”乐观主义共谋”现象的破坏,需要看这些估算值是否有可靠的基础.

4.7    主观性和偏差

估算方法的控制按钮越多,受主观性影响的可能性越大.所以估算模型中控制按钮越多可能偏差越大.

4.8    即兴估算

不要做即兴估算,即使经过15分钟考虑的估算也会更准确.

4.9    无根据的精度

准确度和精度的区别

准确度表明离真实值有多远

精度表明一个数值有多精确

不要给出毫无根绝的精度来给人带来估算很准确的错觉.

5       影响估算的因素

5.1    项目规模

项目规模有很多种表现方式:代码行,功能点,需求数目,web页面等等,但无论什么方式,变化特性都是一样的,所以应投入适当的精力来评估待构建的软件规模,因为软件规模是影响软件工作量和进度的最主要因素.

5.1.1   规模不经济

不要以为工作量是随着项目规模的扩大呈线性增长,实际上是呈指数增长;

5.1.2   何时可以安全的忽略规模不经济

在一定的范围内,软件规模估算值的线性估算值与指数估算值相差不大,(最大规模和最小规模相差3倍)就可以安全的使用基于产能(如每月完成代码行数的估算方法)来估算新项目.

5.2    待开发软件的类型

电信软件:一万行代码:200-3000人月;十万行代码:50-600人月,二十五万行代码:40-500人月.

5.3    人员因素

不需要考虑太大的差异:因为最好的开发人员和最差的开发人员都喜欢跳到那些雇员水平和他们相当的组织中.

5.4    编程语言

变成语言不会影响估算的结果,但会影响估算本身,

5.5    影响项目的其它因素

譬如用户重用,平台经验,提供文档的程度,产品复杂度,软件工具的使用等等,其中影响比较大的有产品复杂度,需求分析师的能力,程序员的总体能力,时间限制,人员持续性,多场所开发,要求的软件可靠性等等,来源于cocomo2调整因子.

5.6    再论规模不经济

五个规模因子:开发过程的成熟度,架构和风险的化解,有先例可循度的程度,团队凝聚力和开发灵活性.这些因子在cocomo2中是影响最小的因子,但是这些会在不同的规模产生不同的影响.随着规模的变大,这些因子的影响变的很显著.