关于工作量估算，所有你知道的和你不知道

本文首次公布于 IEEE Software 杂志，由 InfoQ 和 IEEE Computer Society 为您呈现。

　　越来越多证据表明这样一个趋势：软件项目的成本和工作量超出限度，泛滥成灾。平均来看。这样的泛滥大约在 30% 左右【1】。

并且，对照 1980 年代和近期的调查中的估算准确程度，能够看出基本上没有改善。（仅仅有 Standish Group 的分析指出估算精确度有显著提升。

只是，在他们的 Chaos
Reports 中提到的估算精确度显著低声。或许仅仅是因为他们自己分析方法的改变，他们曾经选择了太多有问题的项目分析，如今选择的项目更具代表性。【2】）估算方法也没有太多变化。虽然对于正式的估算模型有非常多研究，“专家估算”依然占领主导地位。

【3】

　　估算精确度明显缺乏改善，但我们对工作量估算比曾经有了很多其它了解。本文中。我试图总结获得的一些知识。当中有些知识有可能提高估算精确度，有些能告诉我们什么样的做法不可能带来改善。有些是关于我们对于工作量估算已知和未知的事情。文中用以得出结论的一整套经验证据，能够在其它地方看到。【1】

　　我们知道的事

　　研读过关于工作量估算的研究之后，我选出 7 种证据充足的结论。

　　不存在“最佳”的工作量估算模型或方法

　　众多研究对照了多种估算模型和方法的精确度，哪一种是最佳选择【4】，众说纷纭。

结果不稳定，主要原因似乎在于几种不同的核心关系，比方开发工作量和项目大小之间。这些关系在不同上下文中也不一样【5】。此外。影响开发工作量的最大因素似乎也不一样。这表明估算模型和方法应该依据所处上下文剪裁。

　　核心关系不够稳定。相同可以用来解释。相比更简单的模型，为什么统计方法先进的估算模型，对于估算精确度没有多大改善，甚至根本没有改善。统计方法先进的估算模型会更贴近历史数据。因此当上下文改变时，相比简单的模型，精确度更渣。这个结论告诉我们，软件公司应该尝试构建自己的估算模型。而不是期望某个通用的估算模型和工具在他们的环境中可以表现准确。

　　客户着眼于减少价格。是工作量泛滥的主要原因

　　低估工作量的趋势，在基于价格的竞争情形中最为明显，比方在投标之中。在价格竞争不那么重要的情形下，比方内部软件开发，这种趋势就不明显。

实际上。你甚至会看到相反的结果。由此说明：工作量泛滥了的主要原因之中的一个，就是客户在选择软件开发供应商时，倾向选择价格低的一方。

因此，低估工作量的项目投标书更有可能启动。

这些观察说明：客户在选择供应商时。少关注价格，多关注能力，就能够避免工作量泛滥。

　　最大工作量和最小工作量区间过于接近

　　最大-最小工作量之间的差距，比方 90% 置信区间，过于接近，无法反映实际情况中的不确定性。虽然存在有力证据表明。我们无法准确设定最大和最小工作量值域，但眼下的估算方法还是假定能够做到这一点。这在基于 PERT 计划评价与审查技术（Program Evaluation and Review Technique）的估算方法（三点估算）中尤为明显，当中中值工作量经常由最小和最大工作量计算得出。

　　软件从业人士应该利用历史数据和此前的估算误差，设定比較现实的最小和最大工作量，而不是使用专家的推断。【6】

　　工作量估算易于走偏。一旦走偏。难以恢复

　　全部的软件开发工作量估算，即使使用正式的估算模型，都须要专家推断。但即使专家推断能够非常准确。也非常easy走偏。最严重的走偏非常可能发生于例如以下情形：负责估算的人，在估算前或者估算中，了解到预算、客户期望、可用时间或其它所谓的“估算锚点”因素。在没有意识到的情况下，估算者的估算结果可能非常接近这些锚点。比方。知道客户期望低价格，或者较少的工作小时数。就有可能造成低估工作量。

假设估算请求中包含某些引导性词语。比方“这个项目这么小。又简单，大概要花多少钱”，这就会误导专家的估算。

　　有非常多研究。针对怎样从误导中恢复，或者怎样纠正估算的偏差，但没有发现可靠的方法。由此能够推导出：负责工作量估算的人，应该尽量避免看到误导或无关信息，比方，应该将需求文档中的误导和无关信息去除。

　　相关历史数据和检查列表能够改善估算精确度

　　充分证据表明：使用历史数据和估算检查列表。能够改善工作量估算精确度。当历史数据与项目相关，检查列表也依据公司情况进行裁剪之后，这就不太可能遗漏某些工作了，并且非常可能增加足够的应急措施，应对某些风险，之前的经验也能够重用。因此能够产生更为现实的估算。

特别是当类似项目可用于类比或是參考类【7】估算中时，估算精确度能够提升。

　　尽管历史数据（比方有百分之多少的工作量用于未规划的工作和项目管理上）和估算检查列表（比方针对易于忘记的工作提醒）有其作用。还是有非常多公司没有使用不论什么一个，因此无法提升估算工作量精确度。

　　结合多个独立估算能够提升估算精确度

　　比起单独的工作量估算，来自多方的估算精确度平均值可能更准确。

这样做有一个关键前提，就是估算都是独立完毕的，也就是说估算者的专业知识、背景和估算过程都不一样。类似德尔菲的估算过程。比方“规划扑克”。软件开发人员在当中会同一时候展示各自独立做出的估算（他们的扑克卡片），这在软件工作量估算上下文中尤事实上用。

　　基于小组的、结构化的估算过程，可以让估算的机械组合更有价值。由于知识的分享可以添加知识的总量。比方完毕一个项目须要的工作总和。小组估算推断的负面影响，比方“集体思考”和在小组中承担很多其它风险。还没有在软件工作量估算的相关文档中看到。

　　一般来说，估算模型要比专家估算精确度更低。只是，假设能结合起来，模型和专家之间的差异反而可能提升估算精确度。

　　估算有其害处

　　估算不仅预測未来。并且会频繁影响未来。过低的估算会导致过低的质量。以后可能要返工；过高的估算可能减少工作效率，遵从“帕金森定律”——工作会自己主动占满全部可用的时间。

　　因此，必须考虑是否的确须要工作量估算。假设可有可无，或是以后才有必要。可能不做更好。或是推迟估算，直到能够得到很多其它信息。敏捷软件开发——仅仅估算下一个 sprint 或者公布版本号的工作量，并且必须使用此前 sprint 或者版本号公布的反馈信息——可能是避免过早估算带来的潜在危害的良好方法。

　　我们不知道的事

　　估算活动中存在一些问题。我们就是找不到好的解决的方法，就算进行再多研究也不行。有三方面的挑战，说明我们的知识远远不能令我们惬意。

　　怎样准确估算超大型——即大型复杂项目的工作量

　　超大型项目对工作量估算提出了更高要求。不仅是很多其它价值面临风险。并且相关经验或历史数据也相对较少。非常多超大型项目中的典型活动。比方组织层面的问题——太多项目干系人參与，本来就非常难估算，由于当中经常涉及流程变更，以及项目干系人之间、与现有软件应用之间的复杂互动。

　　怎样准确估算软件大小和复杂度

　　尽管对软件规模和复杂度的度量研究经年，但说到估算软件开发工作量。没有哪种方法特别有效。有些软件规模和复杂度的上下文有可能产生准确估算。但这样的情况非常少见。

　　怎样度量、预測工作效率

　　即使能够出色估算软件的规模和复杂度。你还是须要可靠地预測个人或团队完毕工作的工作效率。这样的预測非常复杂，由于不同软件开发人员和团队之间的工作效率差距非常大。同一时候也没有什么好的预測方法。除了某些比較实际的编程測试（比方：trialsourcing）之外。

　　眼下。我们甚至不知道软件项目中是否存在“规模经济”效应，或是“规模不经济”效应。非常多基于经验的研究表明：一般软件项目都有规模经济效应，可是软件实践者们基本上都相信“规模不经济”。然而。对于规模经济的研究结果，似乎要视乎分析的实施方法而定，并且也没有揭示多少规模和工作效率之间的关系。

　　就我们如今对软件工作量和成本估算的了解，基本上不能让我们解决软件行业中的估算挑战。只是，它的确指出多种措施，能够提升估算准确率。特别要指出，假设软件公司能运行例如以下举措，就能够提升估算效率：

• 制定并使用简单的估算模型，并要依据实际情况剪裁，同一时候和专家估算一起使用。
• 使用历史估算的误差，设定最大—最小工作量区间。

• 避免曝露易于误导和无关的估算信息。
• 使用针对本组织调整过的检查列表。
• 使用结构化的、基于小组的估算过程，要保证估算的独立性。
• 避免基于高度不完整信息的早期估算。

　　在竞争激烈的投标轮次中，客户非常easy重点关注低价格，这非常easy导致投标人过于乐观。终于导致成本泛滥，软件质量低下。

这在其它领域称为“赢家的诅咒”。长远来看。非常多软件客户会開始了解。他们对于软件项目应该固定成本和低价格的看法。会对项目成功造成负面影响。在那之前。软件公司应该意识到：处于这样的情况时，他们被选中，是由于他们自己对成本过于乐观；此时要有策略准备，以管理或者避免赢家的诅咒。

　　參考资料

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.

版权声明：本文博主原创文章，博客，未经同意不得转载。