做一些事情需要多长时间？

Question

我的意思是说你做了一个编程项目的名字，请花多长时间。老板从来没有抱怨，但我有时觉得事情需要太长时间。但这可能是因为我也不耐烦了。让我知道你的比较经验。

我也注意到，事情总是比原计划花费更长时间，有时甚至更长。我不知道为什么我们不开始计划，但我认为这可能是出于激励目的。

赖安

Answer 1

最好只是简单地计时，记录您的估算并确定平均百分比。鉴于此，只要您保持一致，您就可以根据您认为完成的时间来适当地估计实际时间。这不仅仅是为了确定你估计的糟糕程度，而是考虑到不可避免的干扰（包括个人和老板/客户）的规律性。

这是基于Joel Spolsky的Evidence Based Scheduling，这是必不可少的阅读，因为他解释说，主要的另一个重要方面是将你的任务分解成一口大小（最多16小时）的任务，估计并将它们加在一起到达你的最终项目总数。

Answer 2

基于肠道的估计有经验，但你真的需要详细说明所涉及的任务以获得合理的东西。

如果你有一个规范或至少有一些约束，你可以开始创建任务（设计用户页面，设计标签页面，实现用户页面，实现标签页面，写标签查询，......）。

完成此操作后，将其添加并加倍。如果你打算与其他人协调，那就加倍。

随时记录您的实际时间，以便评估项目完成时的准确程度并提高您的估算技能。

Answer 3

我完全同意以前的海报......不要忘记你的团队的工作量。仅仅因为你估计一个项目需要3个月，这并不意味着它会在那附近的任何地方完成。

我在一个较小的团队（5个开发人员，1个领导者）工作，我们中的许多人一次在几个项目上工作 - 一些大，一些小。根据项目的优先级，管理的一心一意和其他团队的可用性（如果需要），项目的工作可以穿插在其他团队中。

所以，是的，3个月的工作可能已经死了，但在6个月的时间内可能需要3个月的工作时间。

Answer 4

我自己做了1到6个月的项目，而且我总是倾向于将我原来的估计值加倍或成组。

Answer 5

实际上不可能比较两个编程项目，因为有太多因素意味着指标仅适用于另一个（例如，使用的特定技术，开发人员的先前经验，转移要求）。除非您要删除与之前构建的系统几乎完全相同的另一个系统，否则您的估计值准确度很低。

需要注意的是，当您使用同一个团队构建现有系统的下一个版本时;获得的具体经验确实提高了估计下一批工作的能力。

我在估算方法上看到了太多的尝试，但都没有奏效。他们可能具有伪科学的吸引力，但他们只是在实践中不起作用。

唯一有意义的答案是敏捷倡导者所倡导的相对较短的迭代：选择可在短时间内执行的工作范围，交付，然后进入下一轮。然后在短期内分配预算，利益相关者能够评估他们的资金是否得到有效支出。如果要花费太长时间才能到达任何地方，他们可以抛弃这个项目。

Answer 6

霍夫施塔特定律：

'即使考虑到霍夫施塔特定律，它总是比你预期的要长。'

我相信这是因为：

• 工作范围扩大以填补可用时间。无论你如何无情地削减不必要的功能，如果截止日期更加严格，你会更加残酷。
• 项目期间出现意外问题。

无论如何，比较轶事真的是误导，部分原因是人们有选择性的回忆。如果我告诉你它曾经花了我两个小时来编写一个完全优化的快速排序，那么也许我忘记了事实，我知道我提前一周完成了这项任务，并一直在考虑想法。也许我忘记了它有一个错误，我花了两个小时修复一周后。

我几乎肯定会遗漏所有正在进行的非编程工作：会议，架构设计，咨询其他人，他们会遇到我碰巧知道的事情，管理员。因此，考虑到“坐在那里编码”似乎看似合理的工作速度对你自己是不公平的，并期望它一直持续下去。在你“应该更快”之后，这就是很多感受的源泉。

Answer 7

我从2周到1年做项目。一般来说，我的估计非常好， a posteriori 。然而，在项目开始时，由于我的估计被认为太大，我通常会受到抨击。

这是因为我考虑了很多人忘记的事情：

• 修复错误的时间
• 部署时间
• 管理/会议/互动时间
• 允许需求所有者改变主意的时间
• 等

诀窍是使用基于证据的调度（参见软件上的Joel）。

事情是，如果您计划多一点额外的时间，如果没有问题，您将使用它来改善代码库。如果出现问题，您仍然在估计范围内。

Answer 8

我相信Joel写了一篇关于此的文章：你可以做什么，要求团队中的每个开发人员详细列出他的任务（需要做的所有步骤是什么），并要求他们估计所需的时间每一步。之后，当项目完成后，将实时与估计时间进行比较，您将获得每个开发人员的偏见。当一个新项目启动时，要求他们再次评估时间，并将其与每个开发人员的偏差相乘，以获得接近实际预期的值。

在几个项目之后，你应该有很好的估计。