软件开发评估-——投入知多少？

英文原文地址：

http://www.infoq.com/articles/software-development-effort-estimation?utm_source=infoq&utm_medium=popular_links_homepage

     众所周知，成本和精力是软件开发的两大主要投入。许多不容置疑的证据表明，软件开发的投入正朝着超支的趋势演化，那么这个超支的幅度到底有多大呢？您又对自己研发项目的投入了解多少呢？下面我们就来谈谈软件开发过程中对投入进行评估的那些事，那些您知道与不知道的事儿。

    总体来说，这个预计误差的平均水平约为30%[1]。另外还有大量证据表明，从二十世纪八十年代开始就保持着这个误差水平一直没有太大的改观（注：仅有Standish Group 得出的结论是估计精度得到了大大的改善，即估计误差变小了，但是他们的结论并不具有普片性[2]），评估方法也没有很好的改进。尽管现在评估模型五花八门，占主导地位的仍然是专家评估。

    评估误差没有改观并不意味着我们对软件开发的评估水平相对二十世纪八十年代没有进步，本文将对软件评估中我们所获得一些经验进行综述。有些经验或告诉你怎样减小潜在的误差，有些则告诉你为什么误差没有改进，还有的会告诉你对投入的估计什么是可预测的和什么是不可预测的，更多的资料请参考我的其他文章[1]。

 

那些我们所知道的：

    为了支持我的论点，我选择了以下了七个研究结果作为论据。

 

1 永远没有最好

    目前有大量的研究总是试图在众多的评估模型和方法中评选出误差最小的那一个[4]。但这样做的问题是，一些诸如项目大小与开发投入之间的核心关系的不确定性将会导致这种研究结果不具备稳定性。此外，影响投入的最大要素也是可变的，因此，评估模型和方法应该根据具体的项目来量身打造。

    核心关系的不稳定性也可以说明为什么误差水平长时间以来没有改观。换句话说，如果有稳定的核心关系就可以使用更加简单的模型了。当核心要素发生变化时，先进的统计模型就会对历史数据产生过拟合现象（过拟合是机器学习中常用的一个术语，反映的是在学习训练过程中，NN对训练集达到非常高的逼近精度，但对测试集的逼近误差随着NN的训练次数而呈现先下降，后反而上升的异常现象，即过拟合现象会导致更大的估计误差）。所以，具体的评估方法就根据你的项目来定制吧。

 

2 评估超支的主要原因：用户想要最低的成本

    项目夺标的竞争压力迫使开发人员尽量减少预算，如果在没有价格竞争压力的环境下就不会出现这种趋势，反而会朝着相反的方向发展。显而易见，来自客户的压力是导致预算过低的主要原因，因为客户比较乐意选择成本更低的开发商。

 

3 “峰峰值”过小

    “峰峰值”指评估方案中的最大值和最小值之间的距离。这种方法是有缺陷的，例如置信区间是90%也不能全部囊括实际情况的不确定性。尽管事实证明我们没有办法确定精确的最大最小值，但是目前仍然使用这种办法，最常见的是基于PERT（三点评估）的方法，投入的期望值很可能就出现在最大最小值之间。

对最大最小值的估计就是专家发挥的地方，优秀的软件开发者通常有如何评估最大最小值的历史经验，并且能根据经验做出合适的评估。

4 误导效应（评估很容易被误导并且难于从误导中恢复过来）

    所有对软件开发的评估都需要专家的指导，即使使用正式模型评估也不例外。专家的评估很精确，却也容易造成误导。最易被误导的是投入估计的负责人，当他们考虑到预算，客户要求，日程等因素时，专家的评估指标就成了参考指标。如果不注意到这点，你很可能就会把专家的评估当成了标准，并且在项目进行的过程中不断地去接近这些指标。

    尽管对如何从误导中恢复过来做了大量的研究，目前仍然没有找行之有效的方法。所以项目负责人需要对这个这些指标有个清晰地认识，并且自己能量化这些指标。

5 历史记录有助于提高精确度

    使用历史数据和清单撰写的文档有助于提高估计的精确度。当有可参照的历史记录时，一些注意事项就不会被遗忘，以前的经验能重新利用，还能避开以前走过的弯路。特别是在进行相似的项目时，就可以使用类比来进行估计[7]，历史文档的好处就显而易见。

    尽管历史记录有着诸多的好处，很遗憾好多公司还没有把他们当做一个工具用起来。

6 结合独立估计，提高估计精度

    不同渠道评估的均值一般要比单独个体评估的结果精确。其中有一个重要的假设就是评估是相互独立的，评估者来自不同的企业，具有不同的背景，使用不同的方法。即这是一个类似Delphi的评估方法（Delphi，一种在专家个人判断法和专家会议法的基础上发展起来的专家调查法，它广泛应用在市场预测、技术预测、方案比选、社会评价等众多领域。），比如Planning Poker（计划扑克（Planning Poker）的目的是确保开发团队中的每个人都积极地参与到评估过程并贡献他或她的知识。该活动在可能有很多未知变量且为了得到精确的估计，需要很多领域的专业知识。扑克会话通常是开发团队、项目负责人和引导人参与。在计划扑克（Planning Poker）开始前，引导人将开发团队聚在一桌并给每个成员分发一副专用牌，这也是扑克这个名字的来由。引导人和负责人没有牌。）就是基于这种方法的。

    一个基于组的结构化的方法因为知识和经验的共享比机械的合并会产生更好的效果。当然这种方法也存在风险性，比如组内的某种思想会滋生消极因素。

    总体看来，评估模型的精度并没有专家评估的精度高。但是能将这两种方法结合起来就可以相互取长补短。

7 评估的危害

    评估不仅仅是预测未来，更多的是约束未来。估计得太低会产生豆腐渣工程，根据帕金森定律，估计得太高又会降低生产力。

    这就是为什么你要考虑到底需不需要进行评估的原因。如果你压根不需要评估或者后期才需要评估，不进行评估和后期来评估才是妥当的做法。敏捷开发就是避免早期评估潜在危害的一种好办法，它是根据前期的反馈来制定后期计划的一种方法。

 

那些我们不知道的：

    尽管进行了大量的研究，评估工作仍然面临着诸多挑战，但至今仍然没有十分令人满意的方案。以下三大挑战表明，我们自身的知识还远远不够。

1 如何精确评估大型复杂项目

    大型的项目对投入有更高的要求，不仅因为大型项目具有更多的因素，还因为它可参照的经验和历史记录比较少。由于大型项目还涉及到业务流程的变化以及和现有软件利益对接等问题。

2 如何精确评估项目规模和复杂度

    长时间以来的研究仍然没有找到十分有效的方法来评估项目的规模和复杂度。

3 如何衡量和预测生产力

    即使你有好方法来计算项目的规模和复杂度，你依然要估计团队或个人的工作进度和生产力。这是很难的，因为不同的软件开发者或团队，工作效率很有可能大不相同。这项指标的估计除了跟进工作进度来评估之外没有更好的办法。

    目前，我们还不知道项目规模和经济效益是正相关还是负相关。大多数基于经验的研究表明：软件项目的规模关系着经济效益是正相关的，而软件从业者却认为是负相关的。不过这两种观点至今仍没有定论。

   我们目前所掌握的软件开发投入评估的相关知识还不足以应对评估工作中面临的挑战，然而，这些知识可以为我们提供指导。特别是如果软件公司做到了以下几点，评估的精准度有望提高：

● 将简单模型和专家评估相结合，为你的项目量身打造评估模型。

● 使用历史记录设置合适的最大-最小值。

● 避免专家误导和不相关信息的干扰。

● 使用自己组织特有的文档清单。

● 使用基于独立性假设的有组织的，有结构的评估方法。

● 避免基于不完整信息的前期估计。

    来自投标的压力会迫使评估者去降低预算，从而可能会导致豆腐渣工程，这中现象在别的领域称之为“赢家的诅咒”。从长远来看，客户应该要意识到他们对固定价格、低价格的执着将对项目产生的消极作用。到那时，软件公司也应该提高自身的意识，当他们因为价格优势而中标时，应该考虑考虑如何避开这“赢家的诅咒”。

参考文献：

1.  T. Halkjelsvik and M. Jørgensen, “From Origami to Software Development: A Review of Studies on Judgment-Based Predictions of Performance Time,” Psychological Bulletin, vol. 138, no. 2, 2012, pp. 238–271.
2.  M. Jørgensen and K. Moløkken-Østvold, “How Large Are Software Cost Overruns? A Review of the 1994 CHAOS Report,” Information and Software Technology, vol. 48, no. 4, 2006, pp. 297–301.
3.  M. Jørgensen, “A Review of Studies on Expert Estimation of Software Development Effort,” J. Systems and Software, vol. 70, no. 1, 2004, pp. 37–60.
4.  T. Menzies and M. Shepperd, “Special Issue on Repeatable Results in Software Engineering Prediction,” Empirical Software Eng., vol. 17, no. 1, 2012, pp. 1–17.
5.  J.J. Dolado, “On the Problem of the Software Cost Function,” Information and Software Technology, vol. 43, no. 1, 2001, pp. 61–72.
6.  M. Jørgensen and D.I.K. Sjøberg, “An Effort Prediction Interval Approach Based on the Empirical Distribution of Previous Estimation Accuracy,” Information and Software Technology, vol. 45, no. 3, 2003, pp. 123–136.
7.  B. Flyvbjerg, “Curbing Optimism Bias and Strategic Misrepresentation in Planning: Reference Class Forecasting in Practice,” European Planning Studies, vol. 16, no. 1, 2008, pp. 3–21.