4

我的意思是请说出你做过的一个编程项目以及花了多长时间。老板从来没有抱怨过，但我有时觉得事情太久了。但这可能是因为我也没有耐心。让我知道您的经验以进行比较。

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

瑞安

4

8 回答 8

7

最好简单地给自己计时，记录你的估计并确定你的平均百分比。鉴于此，只要您始终如一，您就可以根据您认为可以完成它的时间来适当地估计实际时间。这不仅仅是确定你在估计方面有多糟糕，而是要考虑到不可避免的干扰的规律性（个人和基于老板/客户的）。

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

于 2008-09-21T21:08:00.063 回答
2

基于直觉的估计伴随着经验，但您确实需要详细说明所涉及的任务才能获得合理的结果。

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

完成此操作后，将其加起来并加倍。如果你将不得不与他人协调，那就三倍。

边走边详细记录你的实际时间，这样你就可以评估你在项目完成时的准确程度，并磨练你的估算技能。

于 2008-09-21T21:03:15.813 回答
2

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

我在一个较小的团队中工作（5 名开发人员，1 名领导），我们中的许多人同时从事多个项目——有些大，有些小。根据项目的优先级、管理层的突发奇想和其他团队的可用性（如果需要），项目的工作会分散在其他团队中。

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

于 2008-09-21T21:14:57.317 回答
1

我自己完成了 1 到 6 个月的项目，而且我总是倾向于将我最初的估计增加一倍或四倍。

于 2008-09-21T20:58:54.187 回答
1

实际上不可能比较两个编程项目，因为有太多因素意味着仅来自的指标不适用于另一个（例如，使用的特定技术、开发人员的先前经验、不断变化的需求）。除非您要淘汰另一个与您之前构建的系统几乎相同的系统，否则您的估计准确的可能性很小。

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

我在估计方法上看到了太多尝试，但都没有奏效。它们可能具有伪科学的魅力，但它们在实践中根本行不通。

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

于 2008-09-21T21:12:26.917 回答
1

霍夫斯塔德定律：

“即使考虑到霍夫施塔特定律，它也总是比你预期的要花更长的时间。”

我相信这是因为：

  • 工作扩展以填补可用的时间。无论你如何无情地削减不必要的功能，如果最后期限更紧，你会更加残酷。
  • 项目过程中出现意想不到的问题。

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

我几乎肯定会忽略所有正在进行的非编程工作：会议、架构设计、咨询其他被困在我碰巧知道的事情上的人、管理员。因此，在“坐在那里编码”方面考虑一个看似合理的工作速度，并期望它一直持续下去，这对你自己是不公平的。这是在您“应该更快”之后产生很多感觉的来源。

于 2008-09-21T22:41:21.663 回答
0

我做的项目从 2 周到 1 年不等。一般来说，我的估计是相当好的，后验的。然而，在项目开始时，我通常会因为我的估计被认为太大而受到抨击。

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

  • 错误修复时间
  • 部署时间
  • 管理/会议/互动时间
  • 是时候让需求所有者改变主意了
  • ETC

诀窍是使用基于证据的调度（参见 Joel on Software）。

问题是，如果您计划多花一点时间，如果没有出现问题，您将使用它来改进代码库。如果出现问题，您仍在估计范围内。

于 2008-09-21T21:04:39.197 回答
0

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

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

于 2008-09-21T21:15:59.077 回答