我怎么知道需要多少天？

Question

我是一名PHP开发人员，而且我常常不知道几天 - 更不用说时间了 - 工作需要花多长时间。我经常写新东西，将它与旧的遗留垃圾合并。我可以告诉我的老板，哪一周我可能会做些什么 - 也许是一周的一半 - 但我知道世界上我究竟知道什么日子会做什么？考虑到经常会出现错误和其他未知因素并节省时间，这不是有点不切实际吗？我只能把这些东西减到极少......

我想说的是：

“看，我明白我说”明天！明天！“没有帮助。我能为你做的最好的事情就是告诉你，在给定的一周中，我可能会完成它的一半。如果它看起来我可以通过在给定周的星期五，然后我们会更好地移动到下周。“

Answer 1

时间估计很难。

但是，我做得好的时候都有几个共同点：

1.）我收到了非常好的和完整的项目要求。这很重要，您应该提出棘手的问题，以确保要求尽可能完整。

2。）我将项目分成几个部分，在白板上写下每个部分，然后单独估算每个部分的完成时间。我让我的团队其他成员做出了贡献，所以我不会忘记任何事情。这看起来很简单，但效果很好。我认为通过减少忽略可能耗时的项目的一部分的可能性，可以让您更加真实。如果你可以在这样的细微层面上写下并规划出项目，那将会非常有用。

在整个时间估算过程中，您甚至可以更好地了解项目以及需要完成的工作。这可以防止错误，写作＆amp;重写代码等等。这对每个人都有好处。

Answer 2

继续你的预感，然后增加50％的时间。你会遇到截止日期，不会给自己带来压力，你的老板会看到高质量的代码而不是快速的代码，你可能会偶尔比预期更快。每个人都赢了:)）

Answer 3

更好的估计来自经验。

你也可以使用Function Point Analysis方法来获得一个好的起点。然后，为您的项目经理定期更新。因此，在周五项目需要进入下周时，您的项目经理不会感到惊讶。

Answer 4

这篇文章很好地描述了知道需要多长时间的唯一方法：http://www.joelonsoftware.com/items/2007/10/26.html

Answer 5

• 被要求在几天内引用是荒谬的，你能做的最好的就是估计。
• 不惜一切代价避免被强迫进行彻底的猜测，你几乎肯定会犯错。花一些时间做出更好的估计总是一个更好的主意。
• 如果您正在处理更改或与之前没有经验的代码接口，请尝试估算出如何执行您需要的操作需要多长时间，当你更准确地知道你需要做多少估计时，再回到他们身上。
• 对于你以前从未做过的事情也是如此，如果你对其他人如何解决类似的问题进行研究，你很可能会更快地完成。
• 将您的任务分解为更小的块（尽可能小）以更准确地估计。这样你可以说“我认为A，B和C总共需要6天左右，但D是我需要看的东西”。这听起来好于“我不知道”或“只要它需要”。
• 您无法估计查找错误所需的时间。你可以估计修复它需要多长时间。一个棘手的错误很容易需要2-3天来追踪和修复。您已交付的代码中的错误会影响您在后续开发中的时间。
• 当您遇到问题时，请务必告知他们，以便在截止日期前让您的截止日期顺利。这样，在与老板/客户交谈时，你的老板就会被预先警告。
• 如果你过度估计并且有幸有一些额外的时间，可以再测试一下，或者花时间开发一些对开发人员的工作效率有用的东西。
• 如果你不断被欺负同意仲裁期限，不断骚扰或觉得你的解释被收回，好像他们是彻头彻尾的谎言那么悄然开始在一家了解软件项目管理的公司寻找另一份工作，然后你的健康不可避免地会受到影响。 / LI>

Answer 6

之间也存在差异

• 完成任务所需的时间（您应该学习估计何时获得经验）
• 和延迟：完成该任务的时间，以及做其他更紧急事情的时间

关于做某事所需时间的估计：

• 你第一次做某事时，很难知道完成它需要多长时间
• 但是，随着时间的推移，你会做出越来越多不同的东西;而且，每一次，你都会记得你花了多长时间。

过了一会儿，当被问到“这需要多长时间？”时，你会想到：

• “that”与我在项目X上做的其他事情非常类似，而我在项目Y上做的其他事情
• 我在项目X上花了8天时间，在项目Y上花了6天时间;但在Y上要容易得多，因为我已经知道如何做到这一点（已在X上完成）
• 所以，在这个新项目中，它不应该花费比项目Y
更多的时间
• 实际上，我现在更好，更有经验......所以它应该需要大约5天
• 并且不要给自己施加太大的压力，并保留一些误差，你说6天，或6天半给你的老板。
• 并且，在他的脑海中，他将再添加一天^^ （或者，如果他是那种在他听到6时数为4的人，只要告诉他8，他就会明白6 ^^ ）

随着时间的推移，你会越来越好;最后，你可能会成为：

• 估计你应该花多长时间做一些你从未做过的事情
• 估计另一位开发人员需要多长时间才能完成
  • 这对于经验丰富的开发人员来说都是
  • 或初学者
  • 或仅针对某个特定人

何，我忘了：我通常会增加大约15％的“开发时间”用于测试和修正错误，顺便说一下 - 这是我工作的项目的标准费率，而且通常非常准确（当然，对于一个初学者，谁可能会创造更多的错误，你会增加一点;对于一个经验丰富的开发者，少一点）。

是的，当然，有时候，你会完全错了;它发生了，就是这样：每个人偶尔会犯错： - ）

关于延迟：好吧，我通常会告诉我的老板“如果我不需要做别的话，我应该花X天”;然后，如果我的老板告诉我在我的任务中间做了2天的其他事情，那就是“他的错”^^

当单独在一个项目上工作，或者是“我自己的老板”时，我通常知道我需要花多少时间在“其他东西”上。
在我前一段时间工作过的项目中，我常常告诉客户：“我需要5天才能做到这一点，但考虑到我一般花一半时间做不计划的事情，让我们考虑一下总共10天“ - 过了一会儿，你习惯了这样计算^^

Answer 7

Answer 8

感谢您的所有答案和反馈。

自从我提出这个问题以来已经有一段时间了，从那以后我使用scrum和敏捷方法大大提高了我的时间估算技能。我们使用白板和scrums，我们按时交付。

至于整个项目的交付时间，根据项目的规模，交货日期仍然未知。但是，通过将任务分解为故事和子任务，我们可以了解项目的规模。这使我们能够向管理层展示他们的交付期望是否切合实际。

此外，积压的任务使我们能够不断重新确定每个sprint的优先级。这可确保完成最高优先级的问题。最终，积压中的剩余项目无关紧要，产品“足够好”可以发布。

到目前为止，它运作良好。

更多详情：http://www.scrumalliance.org/pages/what_is_scrum，http://www.goodagile.com/scrumprimer/。

很抱歉将我自己的回复标记为答案，但这对我有用。

Answer 9

根据我的经验（同时兼任经理和副经理）我知道大多数经理都没有将员工的估算报告到下一级别。相反，他们依靠自己的直觉感受+对外部约束的了解。

当经理要求估算时，他/她通常不太关心估计值本身，而是关心通过分析并找出子任务，主要差距，依赖关系等等。换句话说，要求估计通常是管理层用来让员工前进的一招。在这种情况下，估计值只是一种依赖注入机制，迫使员工进行分析。

当然，棘手的管理者也倾向于记住估计值，特别是如果它被低估并用它来控制项目的紧急程度。

Answer 10

这是Steve Mcconnell（又名Code Complete先生）一本伟大着作的链接： http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351/ref=ntt_at_ep_dpt_3 - 软件估算揭秘

基本步骤是：

• 将碎片分解为可理解/可行的块（查看工作分解结构）
• 如果有需要更多信息的项目，请注意并确保尽快通知您的经理
• 你所拥有的那件作品应该包括你以前做过的其他物品 - 这应该可以很容易地提供这些物品，你对它应该采取多长时间的“粗略”想法（添加根据你的舒适度 - 比如介于10％到30％之间的一段时间，超过你的直觉反应时间的百分比和那些你只需要疯狂猜测的项目（增加％范围，可以是30％到500％）
• 在电子表格中列出可交付成果列表，为每个项目命名，完成的舒适程度（从高到低），您的时间 - 可以是范围（最少1天到最多5天）和任何备注这可能包括问题和假设。
• 将它呈现给您的经理并讨论

要与之交谈的文档包括需要完成的项目，问题，假设和一系列可能的交付日期，这对于您的编程成熟度水平来说很重要 - 与投出数天/周的人相比（或只是一个讽刺的评论），永远不会接近。如果您的经理不理解 - 找一位新经理。

Answer 11

关于估算的一些想法：

• 估计与承诺不同。使用有关工作可能需要的努力（而不是时间）的可用信息，它们是最好的猜测。
• 估算不是单个数字 - 您应该将估算视为范围（下限/上限）或值和置信因子。
• 估计有误差 - 为了减少这个余量，您通常需要花更多时间进行分析和评估。有一点，产生极其准确的估计的努力将开始接近任务本身的努力。
• 根据模糊定义的工作范围制作可靠的估算极具挑战性。在这种情况下，应该预期会有很高的误差。
• 在估算任务时，最好的指南是过去经历类似任务。
• 如果没有历史信息（因为工作量是独一无二的，或者您没有跟踪此历史记录） - 您可以做的最好的事情就是将任务分解为最有意义的工作级别。
• 尝试向组织中可能具有系统或代码库经验的其他人询问您的估算值。

Answer 12

帮助你做得更好的一种方法是跟踪你的原始估计（如果你不得不在最初的时候在黑暗中拍摄）然后跟踪你实际花了多长时间。你甚至可能想要估计它是多么“难”，以及你认为它最初在1到10的范围内表达的难度。

暂时这样做，你可能会开始看到一种模式，甚至开始理解你的估计是好/坏（相对术语）。

随着时间的推移，使用这些来帮助您重新考虑您的估算。例如，最近几次我估计了一个中等难度的5天任务（比如10个中的5个）我平均休息了5天。

有了这个，我将估计这一天10天，看看会发生什么。 ：）

不断重做这个练习，你将开始更好地处理这个问题。

哦，是的，正如已经提到的估计很难，而且有很多资源，但没有像练习或真正好的导师。 ：）

Answer 13

我能给出的最好的建议是将任务分解成更小的部分然后估计那些。也许为每个子任务附加一个“置信度”百分比来计算乐观和悲观范围。这样，当你的老板说“5-8天？这对我没有任何帮助，你在哪里提出这些数字！？！？”你只是告诉他你的故障，你有理由。一个称职的经理应该把你的屁股放在你所承诺的线上，而不是你所想做的事情。

Answer 14

过去的经验和历史数据通常最适合提供估算值。如果您在使用历史数据预测未来任务之前处理过类似的代码/问题。当然，如果您正在处理新的或完全未知的事情，那么提供准确的估算就更难了。当然，他们是'估计'，这是一个有根据的猜测，什么时候会完成。

Answer 15

我通常说它需要的时间比我想象的要长3-4倍。例如，如果我知道我可以在两天内建立一些东西，我会说一个星期左右。

这样一来，如果你的成绩远低于你的猜测时间，你就会看起来像个英雄！ ：P

Answer 16

如果可以的话，找另一份工作。你的老板似乎不知道项目管理，资源管理和软件开发。

一般来说，您只能提供估算值。根据经验，您的估计会变得更好（在大多数情况下，您估计会比现在做出更多努力）。并且 - 正如任何sw开发人员所知道的那样，总是可以选择一些愚蠢的问题，这将占用90％甚至更多的实际工作量（并且大大增加开发时间）。

Answer 17