关于工作量估算，你知道的和你不知道的一切

怼烎@ 2022-08-07 02:49 206阅读 0赞

越来越多证据表明这样一个趋势：软件项目的成本和工作量超出限度，泛滥成灾。平均来看，这种泛滥大约在 30% 左右。而且，对比 1980 年代和最近的调查中的估算准确程度，可以看出基本上没有改善。估算方法也没有太多变化。尽管对于正式的估算模型有很多研究，“专家估算”依旧占据主导地位。  
        估算准确度明显缺乏改善，但我们对工作量估算比以前有了更多了解。本文中，我试图总结获得的一些知识。其中有些知识有可能提高估算准确度，有些能告诉我们什么样的做法不可能带来改善，有些是关于我们对于工作量估算已知和未知的事情。文中用以得出结论的一整套经验证据，可以在其他地方看到。

## 我们知道的 ##

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

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

众多研究对比了多种估算模型和方法的准确度，哪一种是最佳选择，众说纷纭。结果不稳定，主要原因似乎在于几种不同的核心关系，比如开发工作量和项目大小之间，这些关系在不同上下文中也不一样。此外，影响开发工作量的最大因素似乎也不一样，这表明估算模型和方法应该根据所处上下文剪裁。  
        核心关系不够稳定，同样可以用来解释，相比更简单的模型，为什么统计方法先进的估算模型，对于估算准确度没有多大改善，甚至根本没有改善。统计方法先进的估算模型会更贴近历史数据，因此当上下文改变时，相比简单的模型，准确度更渣。这个结论告诉我们，软件公司应该尝试构建自己的估算模型，而不是期望某个通用的估算模型和工具在他们的环境中能够表现准确。

### 2、客户着眼于降低价格，是工作量泛滥的主要原因 ###

低估工作量的趋势，在基于价格的竞争情形中最为明显，比如在投标之中。在价格竞争不那么重要的情形下，比如内部软件开发，这样的趋势就不明显。实际上，你甚至会看到相反的结果。由此说明：工作量泛滥了的主要原因之一，就是客户在选择软件开发供应商时，倾向选择价格低的一方。因此，低估工作量的项目投标书更有可能启动。这些观察说明：客户在选择供应商时，少关注价格，多关注能力，就可以避免工作量泛滥。

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

最大-最小工作量之间的差距，比如 90% 置信区间，过于接近，无法反映实际情况中的不确定性。尽管存在有力证据表明，我们无法准确设定最大和最小工作量值域，但目前的估算方法还是假定可以做到这一点。这在基于 PERT 计划评价与审查技术（Program Evaluation and Review Technique）的估算方法（三点估算）中尤为明显，其中中值工作量常常由最小和最大工作量计算得出。  
        软件从业人士应该利用历史数据和此前的估算误差，设定比较现实的最小和最大工作量，而不是使用专家的判断。

### 4、工作量估算易于走偏，一旦走偏，难以恢复 ###

所有的软件开发工作量估算，即使使用正式的估算模型，都需要专家判断。但即使专家判断可以很准确，也很容易走偏。最严重的走偏很可能发生于如下情形：负责估算的人，在估算前或者估算中，了解到预算、客户期望、可用时间或其他所谓的“估算锚点”因素。在没有意识到的情况下，估算者的估算结果可能很接近这些锚点。比如，知道客户期望低价格，或者较少的工作小时数，就有可能造成低估工作量。如果估算请求中包括某些引导性词语，比如“这个项目这么小，又简单，大概要花多少钱”，这就会误导专家的估算。  
        有很多研究，针对如何从误导中恢复，或者如何纠正估算的偏差，但没有发现可靠的方法。由此可以推导出：负责工作量估算的人，应该尽量避免看到误导或无关信息，比如，应该将需求文档中的误导和无关信息去除。

### 5、相关历史数据和检查列表可以改善估算准确度 ###

充分证据表明：使用历史数据和估算检查列表，可以改善工作量估算准确度。当历史数据与项目相关，检查列表也根据公司情况进行裁剪之后，这就不太可能遗漏某些工作了，而且很可能加入足够的应急措施，应对某些风险，之前的经验也可以重用。因此可以产生更为现实的估算。特别是当类似项目可用于类比或是参考类【7】估算中时，估算准确度可以提升。  
        虽然历史数据（比如有百分之多少的工作量用于未规划的工作和项目管理上）和估算检查列表（比如针对易于忘记的工作提醒）有其作用，还是有很多公司没有使用任何一个，因此无法提升估算工作量准确度。

### 6、结合多个独立估算可以提升估算准确度 ###

比起单独的工作量估算，来自多方的估算准确度平均值可能更准确。这样做有一个关键前提，就是估算都是独立完成的，也就是说估算者的专业知识、背景和估算过程都不一样。类似德尔菲的估算过程，比如“规划扑克”，软件开发者在其中会同时展示各自独立做出的估算（他们的扑克卡片），这在软件工作量估算上下文中尤其有用。  
　　基于小组的、结构化的估算过程，能够让估算的机械组合更有价值，因为知识的分享能够增加知识的总量，比如完成一个项目需要的工作总和。小组估算判断的负面影响，比如“集体思考”和在小组中承担更多风险，还没有在软件工作量估算的相关文档中看到。  
        一般来说，估算模型要比专家估算准确度更低。不过，如果能结合起来，模型和专家之间的差异反而可能提升估算准确度。

### 7、估算有其害处 ###

估算不仅预测未来，而且会频繁影响未来。过低的估算会导致过低的质量，以后可能要返工；过高的估算可能降低工作效率，遵从“帕金森定律”——工作会自动占满所有可用的时间。  
        因此，必须考虑是否的确需要工作量估算。如果可有可无，或是以后才有必要，可能不做更好，或是推迟估算，直到可以得到更多信息。敏捷软件开发——只估算下一个 sprint 或者发布版本的工作量，而且必须使用此前 sprint 或者版本发布的反馈信息——可能是避免过早估算带来的潜在危害的良好方法。

## 我们不知道的事 ##

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

### 1、如何准确估算超大型——即大型复杂项目的工作量 ###

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

### 2、如何准确估算软件大小和复杂度 ###

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

### 3、如何度量、预测工作效率 ###

即使可以出色估算软件的规模和复杂度，你还是需要可靠地预测个人或团队完成工作的工作效率。这种预测很复杂，因为不同软件开发者和团队之间的工作效率差距很大。同时也没有什么好的预测方法，除了某些比较实际的编程测试（比如：trialsourcing）之外。  
　　目前，我们甚至不知道软件项目中是否存在“规模经济”效应，或是“规模不经济”效应。很多基于经验的研究表明：一般软件项目都有规模经济效应，但是软件实践者们基本上都相信“规模不经济”。然而，对于规模经济的研究结果，似乎要视乎分析的实施方法而定，而且也没有揭示多少规模和工作效率之间的关系。  
　　就我们现在对软件工作量和成本估算的了解，基本上不能让我们解决软件行业中的估算挑战。不过，它的确指出多种措施，可以提升估算准确率。特别要指出，如果软件公司能执行如下举措，就可以提升估算效率：  
                制定并使用简单的估算模型，并要根据实际情况剪裁，同时和专家估算一起使用。  
                使用历史估算的误差，设定最大—最小工作量区间。  
                避免曝露易于误导和无关的估算信息。  
                使用针对本组织调整过的检查列表。  
                使用结构化的、基于小组的估算过程，要保证估算的独立性。  
                避免基于高度不完整信息的早期估算。  
        在竞争激烈的投标轮次中，客户很容易重点关注低价格，这很容易导致投标人过于乐观，最终导致成本泛滥，软件质量低下。这在其他领域称为“赢家的诅咒”。长远来看，很多软件客户会开始了解，他们对于软件项目应该固定成本和低价格的看法，会对项目成功造成负面影响。在那之前，软件公司应该意识到：处于这种情况时，他们被选中，是因为他们自己对成本过于乐观；此时要有策略准备，以管理或者避免赢家的诅咒。