问题标签 [estimation]

我们的项目经理通常会咨询开发人员他们需要多少小时来实现客户要求的某些功能。这是否符合管理原则？您或您的项目经理是否也这样做？

在做一个项目时——我总是估计我的任务并计算我需要多长时间才能完成。所以最后我得到了一个项目应该完成的时间跨度（很少是这样）。

我的问题是 - 您是否在项目期间记录您在估算中使用的数据和假设，并将它们用于以后的项目或对同一项目的改进估算？

如果是这样 - 您如何记录这些数据以及如何存储它们？

我使用了一个 excel 表 - 但不知何故（无法想象这是怎么发生的；））我倾向于忘记填写新的假设或获得的信息。另一方面，它对于在完成项目后评估我的预测并没有真正的可读性或有用性——在下一个项目中从中学习。

由于今天对SO IRC的讨论，我对轨道力学很好奇，并且

• 解决轨道问题所需的方程
• 解决复杂问题所需的计算能力

尤其是计算地球何时会进入太阳的问题（反之亦然，取决于参考系）。

我怀疑我们太阳系内的所有引力可能都需要计算，这让我想知道需要什么类型的计算机集群，或者这可以在一个盒子上完成吗？

我没有在这里做餐巾纸背面测试的经验，但也许你有？

此外，非常感谢 Gortok 的原始灵感（见评论）。

-亚当

似乎无论我的项目是什么，我都能很快完成 80% 的工作。用户和管理人员兴奋地认为事情比计划提前了很多，但剩下的 20% 令人讨厌的工作似乎需要之前 80% 的 4 倍。当我们对项目进行定期检查或站立时，我觉得自己就像一个破纪录的人说：“是的，到目前为止一切都很好，但还有很多事情要做……”

在大多数情况下，我的估计是相当准确的，但我是人。让用户相信最后 20% 的工作确实需要 80% 的时间的最佳方法是什么？似乎越来越多的用户和管理人员相信 IT 很简单，神奇的事情发生在弹指之间……

一般来说，我们确实在我认为相当低的水平上跟踪任务。不一定在创建标签或文本框中，但我们非常详细......我们还跟踪我们对所有任务的估计完成情况，我觉得当您处于项目中间时，这个数字比原始估计更重要.

我认为这归结为用户和管理层的看法。即使他们可能知道要完成的估算，他们仍然会沉浸在对所见事物的情绪和看法中，而估算数字则处于次要地位。这就是我试图弄清楚如何控制或管理期望的原因。

我刚刚参加了关于谁最适合对给定工作进行估算的讨论。

在详细的层面上，我总是说最好的估计来自实际必须做这项工作的人，因为他们有充分的理解，这让他们完全接受，但是在更高的抽象层次上（即在整个项目级别）我不太确定。

我想起了 Peopleware 中的第 5 章，它给出了 1985 年澳大利亚研究的结果——我能找到的最佳链接在这里。

我对您在这里的关注点特别感兴趣——您是作为开发人员、架构师、项目经理还是其他人回答问题？

我正在寻找的东西非常简单：我想要一个工具来计算计算的，而不是基于置信区间估计的，发货日期给定一个任务列表，其中包含总估计和当前进度，而不会像我想要的那样引入进一步的不确定性从外部处理。

我希望它考虑工作日持续时间和用户输入的假期等。

我知道 Fogbugz 的 Evidence Base Scheduling 做的事情非常接近，但我希望它没有统计方面和相关的置信区间。我知道这是一个极大的简化，统计估计是 EBS 的本质，但我不是在这里寻找主观讨论，我只是希望能够在任何给定的情况下访问这个简单的信息（所谓的确切发货日期）项目期间的时间，而不必自己计算。

所以我正在寻找以下三件事之一：1）一种自定义 Fogbugz（6.0）的方法，以向我展示除置信区间之外我想要的信息 2）一种自定义 Fogbugz 以将估计不确定性设置为 0 3）另一种工具（免费) 这正是我想要的。

编辑：我所说的“假定准确”或“经过计算”，并不是指实际将要发生的事情，这确实是在试图预测未来。我的意思是关于输入的信息，以及它明显的不确定性。在这种情况下，我想对单个任务的估计应该更多地被视为支出限制或上限。我希望能够计算出的信息非常简单：如果一切都完全按照规定进行，那么它将带我们去哪里？然后，通过有关如何进行估计的信息，例如每个开发人员做出良好估计的能力，我可以推导出置信区间。EBS 会自动执行此操作，毫无疑问，这非常好，这就是我使用它的原因。我想要的是再获得一点点信息，

我被要求对此进行克隆：http : //www.bragster.com/ 好吧，本身不是克隆，而是具有类似功能且预算较低的网站！有人会问多低？低于 10K，可能低于 5K。

我的问题：我如何向不懂技术的朋友解释这是不可能的，用最好的术语来说，并说服他们不要去rentacoder.com 并尝试付钱给别人不要为他们做这件事。

你有没有遇到过这样的事情，你是怎么处理的？

我在工作中参与了一个关于不同人构建的软件系统最大的讨论；在这种情况下，最大的问题是系统复杂性和实施难度的结合。

由于经验丰富的程序员往往会对项目的规模有直觉，即使他们不会把它写下来，我想我会向 SO 提出这个问题。

正在讨论的系统是：

• 电信计费系统。4个主要特点：
  • 实时呼叫控制，其中每 60 秒从数据库中保留一次呼叫信用，
  • 可定制的呼叫计划、最低成本路由、自定义每用户费率、
  • 每个计费服务器可同时处理 1000 个呼叫，
  • 365x24x7 和 99.999% 的可靠性。
• 赛车行业的核心投注系统。4个主要特点：
  • 客户端/服务器应用程序支持大约。1000 个现金网点和 200 个座位的呼叫中心，
  • 不是一个固定的赔率系统，根据扣除佣金和获胜者之间的共享池计算支出，
  • 大约 20 种不同的投注类型，最大组合投注为前 4 名，
  • 350x20x7 和 99.9% 的可靠性。
• 客户关系管理系统。4个主要特点：
  • AJAX 用户界面，
  • 电子邮件集成根据收件人地址发送到不同的队列，
  • 开票，
  • 具有 3rd 方集成授权的 Web 服务 API。

缺少大量细节，但问题的重点是按“大”降序对系统进行排名（定义见上文）。任何比例都是任意的，但为了给它一些相关性，建议使用以下比例：

• 100航天飞机生命支持系统，
• ?? 应用 X
• 1 Hello World 控制台。

我很想看看上面 3 个系统的排名以及人们曾参与过的任何其他大型系统的排名，以提供观点。

我知道我不是唯一一个不喜欢在软件中给出不切实际估计的进度条或时间估计的人。最好的例子是安装人员在 10 秒内从 0% 跳到 90%，然后花一个小时完成最后的 10%。

大多数时候，程序员只是估计完成任务的步骤，然后将当前步骤/总步骤显示为百分比，而忽略了每个步骤可能需要不同时间才能完成的事实。例如，如果您将行插入数据库，则插入时间会随着插入行数的增加而增加（简单示例），或者复制文件的时间不仅取决于文件的大小，还取决于文件的位置。磁盘以及它的碎片程度。

今天，我问自己是否有人已经尝试对此进行建模，并且可能创建了一个带有可配置的鲁棒估计器的库。我知道很难给出可靠的估计，因为外部因素（网络连接、用户运行其他程序等）发挥了作用。

也许还有一种解决方案可以使用分析来设置更好的估计器，或者可以使用机器学习方法。

有人知道这个问题的高级解决方案吗？

与此相关，我发现重新思考进度条的文章非常有趣。它展示了进度条如何改变对时间的感知，以及您如何使用这些见解来创建似乎更快的进度条。

编辑：我可以想办法如何手动调整时间估计，即使使用“估计器库”，我也必须微调算法。但我认为这个问题可以用统计工具来解决。当然，估算器会在此过程中收集数据，以便为后续步骤创建更好的估算。

我现在要做的是取上一步所花费的平均时间（按类型分组的步骤并按例如文件大小、事务大小进行标准化）并将这个平均值作为下一步的估计（再次：计算不同的类型和尺寸）。

现在，我知道有更好的统计工具来创建估算器，我想知道是否有人将这些工具应用于这个问题。

我在一个神话般的人月中读到，集成所需的时间是开发单个组件所需时间的 3 倍。

你们经历了什么？