所以你刚刚被老板放在了现场。您有 15 分钟的时间来估算添加一些新功能的信封背面。你的老板（幸运的是）认识到你无法在那个时候提供准确的估计，所以期待一些正确数量级的东西。
问题是你如何在时间范围内给出一个精确到一个数量级的估计？
请注意，这是一个快速而肮脏的估计，而不是像这样的问题所期望的
Andrew Edgecombe
问问题
1453 次
17 回答
17
将手指放在嘴里，舔舐，在空气中挥动，根据过去的经验编一个数字。然后加倍。
真的，重要的是经验。你想象任务需要你做什么，你知道你需要多长时间才能完成。将意外物品加倍。这也是为什么您从不向初级程序员询问此类估算的原因。
于 2008-09-20T22:55:22.043 回答
7
最好的方法是尝试快速分解所有主要子组件，例如
- 更新数据模型脚本（2 个表中的 3 个项目）
- 更改输入屏幕（3 个新输入）
- 检查输入（3 个新输入）
- 更新数据。
- 显示结果等...
- 构建单元测试
对每一项进行粗略的猜测，如果你想不出一个至少需要 2 小时，因为即使是最简单的项目也可能需要至少一个小时，但 2x 将允许不确定性。
至少你会想到你必须做的所有项目，这样它就会按照要求的数量级进行。
于 2008-09-20T22:54:41.327 回答
5
回想一下您过去完成的类似任务以及它们花费了您多长时间。
如果您之前没有做过类似的事情，请尝试将任务分解为子任务，然后将每个子任务进一步分解，直到没有留下任何子任务，这听起来像最天真的原型需要超过 1-2 天的时间方法; 如果您无法将估计超过 3 天的任务分开，这通常意味着您并不真正了解执行该任务所涉及的内容；做一些快速的研究。一旦所有的东西都被分解得足够多，就把它加起来，把结果加倍，然后把它作为你的估计。
如果您不知道如何解决问题足以完成上述工作，并且您的老板正在扼杀您的脖子，因此您觉得自己无法在那里进行研究，然后尝试给您的老板估计需要多长时间将带您进行所需的研究，以充分了解问题，从而给他一个正确的估计。
于 2008-09-20T22:53:56.057 回答
3
我无法想象我真的无法做出估计的情况——更常见的情况是，我可以想象多种场景，这将导致项目的时间框架大不相同，具体取决于可以合理裁剪的各种事情向上。而且我不想撒谎——你能对你的老板做的最糟糕的事情就是编造一些东西。
所以我解释了每一种可能性。当然，这只适用于理解力强的上司，但如果你的上司无知或愚蠢到拒绝听完整的解释，你就有其他问题了。
例如，对于最近的一个案例，我是这样做的，实际上我必须这样做。
我工作的视频编码器 x264 实现了一种非常原始的隔行编码形式，之所以选择它，只是因为它很容易实现。我们想实现这种编码的完整形式，但我不知道有多少简化版本的假设在这种情况下会失败。
所以我仔细考虑了可能需要改变的各个层面，并做出了一个范围的估计——好吧，充其量，它可能已经接近工作了，但这是值得怀疑的。最坏的情况是有一大堆东西需要改变。所以，我告诉我的老板，最好在这里假设最坏的情况，因为规范非常复杂，尽管不知道任何复杂性，我怀疑由于程序中主要缺乏相关代码，几乎没有这种复杂性实际上已经实现。最后，我是对的——所需的更改最终变得相当复杂，他们将项目外包给了一个在 H.264 交错编码的复杂性方面拥有更多专业知识的承包商。
于 2008-09-20T22:55:27.363 回答
3
除了必要的细分之外：我从实用程序员那里学到的一条建议是以周为单位表达超过 15 天的估计，以月为单位表达超过 8 周的估计；以便单位反映估计的准确性。在 30 周内要非常小心。
您还可以根据您已经完成的类似任务做出估计。
于 2008-12-06T21:43:25.067 回答
2
如果您真的需要非常快速的估算，您可以对每个任务进行 1-2 天或更短的工作分解结构，然后通过提供最小和最大估算值来估算每个任务。
最小值和最大值之和指定整个任务的间隔。这为您的老板提供了有关风险的信息，这总是非常有用的。
您将获得一些间隔，例如 12-15 天或 5-30 天 - 这比 16 天而不是提到的间隔更有用。
Steve McConnel Software Estimation: Demystifying the Black Art 的好书对你很有用。
于 2008-09-20T23:16:48.420 回答
2
想一个数字，把它加倍，然后再加倍（即四倍于你脑海中出现的第一个数字）
当老板说“完成项目需要多长时间”时，他指的是项目完成并实时部署给用户的时间。程序员（自然）只会考虑完成编程所需的时间（实际输入问题解决方案的时间），因此您通常会低估。
经验法则是：
“第一个数字”是您认为根据刚才描述的任务范围完成任务所需的天数。（当然，你还没有被告知一切）。
第一个倍数是在给老板第一个演示/原型后重新编码所需的额外时间，他说“很好，很好。但是你能添加......”
第二个倍数是将重新编码到正确的生产标准所需的时间。
第三个倍数是测试、文档和部署的时间，以及你需要做的所有其他管理工作才能真正把事情拿出来并投入使用。
第四倍数是您对上述情况的意外情况。
这应该给你一个安全的估计。当然，您应该坚持进行更彻底的计划和估算工作。
于 2009-06-01T22:17:18.353 回答
1
因素 #1 是未知数，你是对的，你不可能全部知道。但是，您通常会知道一些当时没有人可以为您回答的主要问题。
因素 #2 是手头的工具和资源的感知难度和可用性。
结果 = 大约是您估计的两倍
于 2008-09-21T02:15:24.137 回答
1
将任务分解为多个部分并为每个部分分配时间
以每天不少于1/2的单位工作。这将防止微调度
项目估算的最大问题是低估。如果您对任务非常了解并且几乎可以看到代码，则将任务加权 1。如果存在一些不确定性或任务需要未知技术，则将其乘以更高的因子，具体取决于不确定性的程度
不要太担心每个部分的准确性。错误往往会抵消，因为唯一真正重要的是总持续时间
采用乐观的时间尺度并将其乘以 PI 始终是一个很好的旧备用方案。比它应该更频繁地工作！
于 2008-09-21T07:45:53.390 回答
1
我最近一直在阅读Agile Estimating and Planning，并且推荐得还不够。
于 2008-09-20T22:58:26.937 回答
1
如果我被迫提供估计而没有足够的时间来正确调查手头的主题，我往往会严重高估。修复几乎总是比我想象的要困难。如果我认为某件事需要一天的时间，那么我会说两天。如果我说某件事需要一个小时，那么我会说一天。我试图用这些评论来说明的是，除了拼写错误等最平凡的任务之外，即使是很小的代码更改也可能会爆发一整天。对于我认为可能需要一天或更长时间的任何事情，我将估计值加倍。我知道这可能很难做到。管理层想要小数字。您想在其他开发人员面前显得聪明而有能力。另见斯科蒂工厂。
即使您有 QA 团队成员来测试您的代码，您也必须记住，测试代码也是您的工作。确保将其纳入任何估计。这是我看到很多开发人员在他们的估算过程中遗漏的东西。
于 2008-09-20T23:02:24.913 回答
0
我通常将任务分解成几部分，但我不会在小于半天的时间段内估计这类事情。只要故障后该功能至少有 5 或 6 个部分，我发现错误大部分会自行平衡（某些任务需要不到一个小时，等等）
当然，一定程度的舒适度所需的最小时间划分和件数需要根据问题领域而有所不同——至少 5 或 6 个半天的块似乎适合我最近被问到的东西，但这需要每隔几个月进行一次审查。
当我被要求代表其他人进行估算时，我会更加抗拒，并使用慷慨的填充系统遵循类似的做法（上面提到的“加倍并添加 x”可能是一个很好的近似值）
于 2008-09-20T23:19:17.383 回答
0
“六到八周”的效果非常好，另一件有效的事情是基于数据模型。
想象一下应用程序所需的数据库表（或类似表）的数量，乘以您需要为每个表编写模型、CRUD、UI 等的天数，然后在上面增加 30% 到 50% 的时间那。
于 2009-07-30T14:07:18.197 回答
0
要以正确的数量级进行估计，您需要：
- 没有为想要的功能引入新技术或框架；
- 将您对纯开发时间和开发人员（以及客户和测试人员）可用性的估计分开。
- 获得有关您先前估计的反馈；
- 您安全估计范围内的特征大小（不是 2 倍大，2 倍多的人）
- 稳定的开发团队。
- 没有项目启动开销。
- 只估计你自己做的工作。
于 2008-12-06T22:06:20.840 回答
0
我个人拒绝这种事情。但后来我为自己工作，所以我不回答老板。只是一个客户，但更容易让他们理解它很难在现场做。
于 2008-09-20T22:50:35.253 回答
0
在这样的时候，我记得麦肯齐兄弟关于转换为公制的规则：“加倍，再加上 30。”
我通常会想出我最初认为做一件事需要多快，然后加倍因为我总是低估，然后添加 30 进行测试，具体取决于我使用的单位。
于 2008-09-20T22:52:08.807 回答
0
我相信答案总是“六到八周”。
于 2009-07-01T08:07:24.457 回答