2.2  关于测验结果的讨论

测验的目的并不是确定你是否真的知道亚历山大大帝的出生时间或上海的纬度，而是确定你对自己的估算能力有多少了解。

2.2.1  “90%置信度”的置信度

上面的测验说明中特别指出了测验的目的是以90%的置信水平进行估算的。由于测验中有10个问题，如果确实是以90%的置信水平进行估算的，那么应该可以得到大约9个正确答案。

如果你比较谨慎，保守地把估算范围取得较宽，就有可能答对全部10个问题。如果你比较草率，做出估算的范围比需要的范围窄，那么在10个问题中就可能只答对了7到8个。我让数百个估算人员做过这个测验。图2-1中展现了最近600个估算人员参与这个测验的结果。

图2-1 “你的估算水平如何？”测验的结果。大部分受测人员只答对了1-3个问题

对于图2-1中展示的这些受测人员，他们平均答对的题目数是2.8个。只有2%的受测人员答对了8个以上问题。还没有人答对所有10个问题。我得出的结论是大部分人直觉上的“90%置信度”实际上相当于“30%置信度”。其他研究也证实了这一重要发现（Zultner 1999，J ø rgensen 2002）。

与之相似，我看到过许多项目团队提出了具有“90%置信度”的进度表，然后常常看到这些项目团队超出他们的“90%置信度”的进度表——超出的情况比不超出的情况多。如果这些进度表真正具有90%的置信度，那么项目团队超出它们的可能性就只会有10%。

我的结论是，除非通过某种统计分析方法来提供支持，否则类似于“90%”的这种百分比就仅仅是一些没有实际意义的如意算盘而已。本书后续部分将讨论如何达到真正的90%置信水平。

提示#5  除非有定量推算的方法，否则不要提供“百分率的置信度比率”形式的估算值（尤其是“90%置信度”）。

如果你没有进行本章开头的测验，现在可以回过头去做一次。我想你会对自己在阅读了这些解释后答对的问题仍然那么少而感到吃惊。

2.2.2  估算的范围应该取多宽？

当我发现某个人很罕见地答对了7到8个问题时，就会问他：“你是怎么答对这么多题的？”典型的回答是：“我把范围取得太宽了。”

我回答他的话是：“不，并不是太宽。你取的范围还不够宽！”如果你只答对了7~8个问题，你取的范围仍然太窄，包含的正确答案数量还没有达到你应该答对的数量。

我们习惯于认为用较窄范围表示的估算值比用较宽范围表示的估算值更准确。我们认为较宽范围会让我们显得无知或能力不足。而事实往往与这种看法相反（当然，如果有具体数据的支持，我们也希望取较窄范围的估算）。

提示#6  避免使用没有依据的较窄范围。确保在估算值中使用的范围和你给出的估算值的置信度相匹配。

2.2.3  使用较窄范围的压力来自何方？

进行测验时，你是否感到要让范围取得更宽的压力？或者是要让范围取得更窄的压力？大部分人报告说感觉到让他们把范围取得尽可能窄的压力。但是如果回头再看一下测验的说明，你会发现说明中并没有鼓励使用较窄范围。实际上，我特意说明了应该让范围既不太宽也不太窄——只要宽到让你有90%的把握来包含正确的答案就够了。

在与数百名开发人员和管理人员讨论这个问题之后，我得到的结论是很多时候提供较窄范围的压力来自给出估算值的人员自身。部分压力来自人们的职业荣誉感，因为他们认为较窄范围意味着更好的估算，不过事实并非如此。与坚持使用过窄范围估算的老板或客户打交道的经历也会带来部分压力。

从客户和估算人员之间的交互中，也发现了这种来自估算人员自身的压力。Jørgensen和Sj ø berg报告说客户的期望会对估算值产生强大的影响，而且估算人员通常并未意识到他们给出的估算值受到影响的程度有多大（Jørgersen and Sjøberg 2002）。

提示#7  如果感受到把范围取得更窄的压力，就要核实这种压力确实来自外部而不是你自身。

对那些压力确实来自外部的情况，第22章“估算的表达方式”和第23章“策略、谈判和解决问题”讨论了如何处理这些压力的方法。

2.2.4  该测验对真实软件估算的代表性

在软件行业中，不大可能要求你估算北美五大湖的总水量或者太阳的表面温度。尤其是如果你不在美国的话，期待你能够估算美国货币的流通量或美国出版的书目数量是不是不合理呢？

常常要求软件开发人员对不熟悉业务领域中的项目、采用新技术实现的项目、新编程工具对生产率的影响、尚未确定的人员的生产率等问题进行估算。面对不确定性进行估算是软件估算人员的常见工作。本书的其余部分说明了是如何在这样的环境中取得成功的。

 [c1]