ACM通信
软件业务
数石量山
关于尼泊尔喜马拉雅山脉的第一次试图精确测量山峰高度的探险，有一个不可信的故事，西藏人称之为Chomolangma(“宇宙之母”)，尼泊尔人称之为Sagarmatha(“天空女神”)，而有些冷漠的英国人则称之为Peak XV(“15”)。1856年，一支由当时的印度测量长率领的探险队，长途跋涉进入印度北部的山脉，并向北进入尼泊尔。考察队没有爬到目标山的山顶，尽管他们确实到达了一个可信的高度，比之前的测量更高，更接近山峰。他们用他们的测量工具在山周围进行了多次测量，进行了计算，并根据传说，确定了山的高度完全29000英尺。
除以10
我们人类对测量做了一个有趣的假设。如果它们恰好落在一个能被10整除的数上;或者10这个数字的任何大幂次，我们假定这个数字的某些特性，比如它的精确性和重要性。任何能被100整除的东西都很有趣。在英国，如果你有幸活到100岁，君主会给你发一封生日电报。出于某种原因，女王很可能会忽略你和你所有人的生日，直到你达到那个神奇的数字。10的倍数越大，可能会吸引更大的注意力，几年前的千年庆典就是一个很好的例子。有趣的是，虽然我们大多数人似乎都认为在任何单位中，我们的基本基数的任何倍数既具有重大意义，又具有一定的不准确性，但这一倍数似乎也吸引了一些精确的书呆子。你在报纸上看到过多少信抱怨说，千禧年实际上直到2000年才开始结束2000年的吗?正是因为推断出的整数不精确，才使第十五峰的勘测员们大为震惊。
在比喻意义上，软件项目与山脉有一些相似之处，但是我们通常以不同的，有时不太符合逻辑的方式来度量软件项目。
完成任务并评估工作
一个项目经理(PM)评估一个考虑中的项目通常会做以下工作:
- 获得在可用时间内可以定义的项目的最详细描述。这通常从相对不完整到极度不充分不等。
- 尽可能多地收集专家，并愿意花时间“确定”项目的范围。这通常不是一个受欢迎的任务。
- 确定完成项目所需要的所有任务，有时是非常详细的。
- 按照假定的顺序安排这些假定的任务，识别任何假定的依赖性。这个顺序通常是基于PM的经验，而PM的经验是基于一组先前的项目，当然，与这个项目有些不同。
- 利用上述专家和管理经验，试着确定每个任务的“大小”。这可以通过多种方式来实现，最常见的方式是有根据的猜测。
- 然后对任务进行汇总，得出项目的总工作量。沿着最依赖的任务的预期关键路径计算持续时间，得到项目持续时间，并将在任何给定时间点完成任务所需的所有人员加起来，得到人员配置。
这一切都很好。在某些情况下，基于任务的工作分解结构(WBS)评估项目的方法是一种可靠的管理实践。当我们不知道任务是什么时，问题就出现了，因为这个项目是新的。虽然它可能与以前的项目有一些相似之处，但这个项目所构建的系统至少有一部分必须始终是“新的”。我们可以说，项目的“旧”部分——那些与之前的项目非常相似的任务——真的不应该花费太多的时间或需要大量的努力;毕竟我们至少已经做过一次了。如果我们真的能够从之前项目中的错误中吸取教训，那么这个项目中唯一困难的部分便是我们之前从未做过的事情。问题是，最难估计的恰恰是这些新东西。
WBS的创建级别通常会给出外观精确，因为它非常详细。但这可能并不准确。
项目经理如何思考
项目经理在评估项目时采用基于任务的WBS方法的原因很简单:这是他们看待项目的方式。让一个项目经理描述甚至思考一个项目，你会得到一个任务列表。对PM来说，是一个项目是一组任务。这个观点不一定被其他涉众所认同。大多数客户对构建系统所需的任务知之甚少，也不太关心。对客户来说，项目就是用户界面、功能、价格和交付进度。对于开发人员来说，项目更像是一个复杂的技术难题。对于一个高管来说，一个项目可能看起来像一个黑洞，钱消失了，光也接收不到。但是对于PM来说，项目是一组相互依赖和独立的任务。
这并不奇怪，如果我们要求PM评估一个项目，反射性的反应将是创建一个基于任务的WBS，这仅仅反映了PM是如何理解一个项目的。任务的识别和跟踪是PM最重要的职责之一，毕竟，在某些时候PM将不得不构建一个详细的计划来安排、执行和跟踪这些任务。
最后，如果不允许他们识别进入评估的详细任务，大多数pm在维护评估时会感到不确定和不舒服。然而，尽管令人欣慰，但在许多情况下，这种级别的细节是没有保证的，它可能意味着某种程度的精确度是不存在的。
测量山脉
有两种方法可以估算一座山的大小。一种方法是绕着山走一圈评估所有进入这个结构的巨石。所示图1在美国，可能有大卵石，小卵石，甚至小卵石。这座山的体积和质量可以通过把所有的巨石加在一起来计算。这些巨石是如何相互靠在一起的，这就是这座山的高度。
另一种方法是对山脉进行三角测量，并从不同的地方进行几次全球测量，如下所示图2．或者我们可以将这座山与其他已知大小的山进行比较。只要给出一些这种类型的测量数据，以及一些公式来将角度和距离转换为高度，将高度转换为锥体的体积，并使用岩石密度来确定质量，我们就会得到定义这座山的关键指标。
同样只是更快
我经常在一些公司里看到这种“计数巨石”的现象，在这些公司里，经理们工作是识别和汇总他们的任务，以得出他们的评估结果。得出的估计结果可能是好的，也可能是坏的，但它们肯定需要很长时间来产生。
在一个客户那里，一位副总裁告诉我:“……他们要花六周的时间才能做出一个糟糕的估计，如果你能让他们在几个小时内做出一个同样糟糕的估计，那你就是帮了我们一个忙他是在开玩笑，但他也谈到了在做出这些极其详细的估计时，确实浪费了时间和生产力。同一家公司的一个PM向我展示了一个8MB的电子表格，上面列出了数千个任务，可以在4个小时内完成。任务的大小甚至是基于谁会做这些任务的假设，很多谈判都是沿着“……是的，但是如果我们把它交给比尔去做，只需要两个小时而不是四个小时……”首相感叹道，他和他的同事们会花上数小时的时间进行谈判和辩论，用他们的小任务填满所有的小格子。然后，他们会转动手柄，把所有的数字滚动到顶部，以创建估计。他们会把这个项目提交给高管审批和承诺，结果却被告知“……我们不喜欢这个答案，再给我们一个……”于是，他们又重新踏上岩石堆，重新排列，重新计算那些巨石和鹅卵石，几天后，他们又重新出现，得到了一个不同的答案。这种说法有时会一遍又一遍地重复，正如高管们所说的，实际上“……我们不喜欢这块石头，再拿一块来……”
至少我们还有个计划
这并不是说这个过程毫无价值。正如一位从业者指出的，当评估最终被接受时，他们同时也获得了对计划的批准。但这暴露了计数巨石的本质——它是一种规划活动，而不是评估活动。计划是必要的，也是有价值的，但是最好的计划如果没有人手，或者公司负担不起，或者客户不愿意为它买单，那么它就没有多大用处。计数巨石的方法倾向于把任务规划的推车放在范围估计马的前面。
基于范围的估计使用三角测量方法。它依赖于预测一个代表系统“规模”的值，然后使用一个公式将其转换为项目估计的关键输出:可能的持续时间、工作量/成本，以及创建该“规模”系统所需的人员。当然，问题是如何确定规模。在你建立一个系统之前，你怎么知道它会有多大?或者，给定创建评估的正常时间框架，在您了解系统应该做什么之前，您如何知道系统的范围?答案是:很难。
垃圾,垃圾N出
基于范围的评估的挑战之一是大多数评估方法，比如COCOMO模型中使用的那些方法[1或SLIM-Estimate®工具,1使用最终系统大小的指数作为计算工作量和进度的主要因素之一。这将放大输入大小/范围上的任何差异。期望和实际之间的任何大小差异都将导致输出值的功率差异。然而，这是对现实的正确解释。我们可以合理地预测一个项目的努力和进度，只有在我们的范围内可以合理地计算任务有多大。
这个困境的答案很简单。现代软件开发的典型特征是不确定性。这种不确定性不仅存在于测量活动中，也存在于开发活动中。当我们开始一个软件项目时，我们不知道具体需要做什么。作为软件开发人员，我们的主要工作就是解决这个问题。一旦该活动被排除在外，构建系统通常是非常简单的。由于它是工作固有的，任何合法的评估过程都必须包含和模拟这种不确定性，否则它就是不诚实的行为。也许我们无法测量系统有多大，但也许我们可以测量我们无法测量的系统有多大。
最好的评估方法和工具可以做到这一点;他们期望系统范围的定义是根据可能的范围来给出的。然后，他们将这个范围转换为输出成功的概率分布。范围上的差异变成结果上的风险。事实上，我们也需要承认，我们常常不知道我们在构建这个规模不确定的系统时到底有多有效。认识到这一点意味着估计过程必须适应另一个不确定性来源。但这是唯一诚实的估计方法，如果我们真的不知道这个东西有多大，我们不知道我们有多好，我们真的不知道我们要花多长时间来建造它。我们只需要使用一个过程来量化这种不确定性，并允许我们在此基础上做出明智的决定。
29002英尺
当安德鲁·沃(Andrew Waugh)为纪念他的前任印度测量总长而重新命名第15峰时，他也决定他需要“调整”地球上最高点的测量高度。他非常正确地认为，如果人们恰好落在1000的倍数上，他们会认为他的测量是不准确的。然后，随着故事的发展，安德鲁爵士去把山的高度增加了几英尺，因为这个假设。所以很长一段时间，珠穆朗玛峰的高度都被引用为29002英尺，2额外的“2”清楚地显示了测量师精湛的技术和安德鲁爵士为确保测量的准确性而付出的细心。
但请注意，他并没有计算山上所有的巨石。
©2006 acm 0001-0782/06/0100 $5.00
允许制作本作品的全部或部分的数字或硬拷贝用于个人或课堂使用，但前提是该拷贝不是为了盈利或商业利益而制作或分发，并且该拷贝在第一页上带有本通知和完整引用。以其他方式复制、重新发布、在服务器上发布或重新分发到列表，需要事先获得特定的许可和/或付费。
数字图书馆是由计算机协会出版的。版权所有©2006 ACM有限公司
没有发现记录