您如何估算主要用于解决问题的任务的时间？

虽然有经验的开发人员可以相对容易地估计出在解决了代码所解决的模式和问题时需要花多长时间来实施代码，但是当最终目标得到了很好的理解时，如何才能做出正确的估计呢？实施是95％的理论/问题解决方案，并且实施量很少？

我的工作通常由完成明确目标的任务组成，但是我必须找到实现该目标的方法，直到我理解解决方案为止，它尚不清楚可能存在哪些其他障碍。更具体地说，我经常研究代码生成或自动代码操作工具。解决方案完全解决并完善工具后，它将非常快速地直接完成实际更改的95％。但是，我没有任何方法来估计可能需要解决多少其他问题才能使生成或分析工具处理无法预料的边缘情况。

出于计划目的，我的公司希望更好地了解将花费多长时间，但是由于我不知道在解决解决方案的每个步骤时可能还会遇到多少其他问题。我不确定如何才能给出更好的估计。

在深入探讨之前，我要说的是，“ 软件估算：揭开妖术的神秘面纱”对于那些正在考虑和思考估算的人们来说是一个极好的资源。下面的两个图像均来自该书，如果下面提出的想法也一样，则是核心内容。

您已经注意到，估算是能够准确预测和计划工作的重要组成部分。没有估算会使企业对某件事情需要多长时间视而不见。对于业务需要多长时间完全不正确的想法对企业来说并不罕见-他们认为容易的事情需要六到八周的时间，而被认为困难的是星期五下午的黑客。

首先是给出一个估计。估计本身不是一个数字-这就是一个承诺。“ ABC需要多长时间”->“大约5天”表示大约5天。但是，一个好的估计范围是您有90％的信心将在该范围内。如果您要说“我有90％的信心，这将需要1至5天的时间”，然后说。不要从“我认为这将需要1到10天，所以5天可能是平均水平”开始工作-那不是一个估计，并且50％的时间您都会错的。

好吧，在50％或更多的时间里，程序员对于任务时间都是臭名昭著的低估者。

考虑不确定性的锥体：

^{_{图片来自http://www.construx.com-全文位于http://www.construx.com/Thought_Leadership/Books/The_Cone_of_Uncertainty/}}

意识到该范围内的第一个估计值为16倍。这类似于说“我认为这需要一个下午到两个星期”-但您还不知道。随着设计的进行，范围缩小到4倍。但这并不意味着它会采取一个星期就意味着你反而会被说“看这一点后，会需要三个星期之间” -是的，估计去了，而且估计的范围内去下。

给出的每个估算值都需要90％确保估算值在该范围内。您可能会错-10％的时间将超出该范围。

有许多估算项目规模的方法。将其与过去的项目进行比较，使用代理（我认为这将花费1000行代码，这将花费很长时间来编写），使用功能点（转换为LOC ...），从许多人那里获得估算值，然后反复细化...针对某些项目的某些工作，针对其他项目的一些工作。

我在书中最上面提到的非常重要的一章是＃23，它涉及估算的政治以及与经理和行政人员的关系。

估算的关键是经过一点点的细化之后的迭代过程。

在流程中过早地提供估计值过于精确可能很容易出错。如果您不确定，请给出广泛的估计，然后过一段时间再返回另一个估计，以便对问题进行更多的内省，并可能勾勒出您将如何做，并查看为该代码编写了多少代码最后一个类似的问题以及其他会影响估计的因素。

估算需要一些思考-不要放弃袖带估算。与您稍微想一想相比，这些通常会伴随着巨大的错误。

从如何当你要求的估计来应对呢？

要求估价时要说些什么

您说：“我会尽快回复您。”

如果您减慢流程速度并花一些时间来完成我们在本节中介绍的步骤，则几乎总是可以获得更好的结果。咖啡机提供的估算值（像咖啡一样）会再次困扰您。

从软件评估的第4章：

请注意，在这种情况下，经过一番审核后的估算值与临时估算值相比，在系统上不那么疯狂且不易出错。不要做袖口估计。坐下来考虑一下任务，经过一番思考后再进行估算。

老板：AJ，我们有3只狗，2只兔子，一个弹射器和一个尼姑。我们需要找到一种方法，将全部7只（也就是弹射器）放到20英尺高的墙壁上，并放到另一侧的湖中，而不让狗狗吃兔子，也不要淹死修女。您需要多长时间才能提出解决方案？

看到，估计解决一个问题需要多长时间的问题是，不同的人需要花费不同的时间。如果您有解决类似问题的历史，则可以根据之前花费了多长时间来估算。如果您不这样做，那么您就没有估计，您只是在猜测。

此外，该问题甚至可能没有可接受的解决方案。也许该解决方案将需要进一步的授权，这可能会使整个项目中断。或者，解决方案可能会改变问题的整体感知性质，从而使解决方案变得完全不必要。

这个故事的寓意是，如果您没有足够的信息来做出合理的估算，那么就不要。还没。获取更多信息。研究更多。通常，完全可以这样说：“我会在2天之内给您更多可靠的数字。”

在为我的客户设计解决方案时，直到我完成足够的常规设计后，我才会签署合同，我知道解决方案将是什么样，项目将花费多长时间。这意味着我有完成未付薪水的初始设计工作的风险（如果项目没有通过），但这比面临工作的预算不足的风险要好。 。

我建议你尝试的答案之间的东西中途tylerl和MichaelT有以下几点：

• 将工作分为三个或四个阶段。阶段应为：
  1. 问题分析
  2. 解决方案原型
  3. 现实世界的解决方案
  4. 输出评估（测试）
• 仅根据您的经验或您的管理层根据阶段1 + 2（分析+原型）提供阶段1（分析）的估算值。然后，在问题阶段1和2完成后（或至少足够高级，以便您对估计有信心），为他们提供阶段3 + 4的估计。

背后的基本原理是，您根据经验知道您需要X天的时间来分析给定的代码库（可能取决于其大小），并且需要运行一些基本工具或脚本（可能会失败）。然后，错误数量应为您提供一些有关手头任务实际难度的信息。

也许这并不是管理层想要的，但我认为提出您将实际达到的估计总是更好的。

因为这个问题主要是关于研究工作类型的问题，所以询问软件开发人员是一种勇敢的方法，一个通用的指标是，花费两倍于他们的估计时间的软件开发人员可能是一个好的开发人员。 但是，也就是说，研究（和体系结构设计）任务在编程中非常重要，并且经常被跳过/最小化。它们通常也很难估计。

我要问自己的第一个问题，这是可以解决的问题吗？ 这不是智力或脑力问题，而是实际现实之一。除非你是在谷歌登月，若不是预期结果的世界里，残酷的现实是，我将有望交付本，不管这个结果是。大概的经验是，我们是否已经知道解决方案的90％是什么？

我要问的第二个问题，在思考解决方案时还需要了解什么？ 这确实是一种反复检查的方式，我们是否真的了解得足够多，才能提出一个可以接受的解决方案。它可能会产生一系列事实调查任务，有助于更好地定义解决方案的需求，每个任务通常都很容易定义和估计。

第三个问题是，谁最适合团队中的此类问题？ 谁完成这项任务，谁都会以自己的风格来丰富结果。将这样的问题交给在任务开始时有1000万个问题然后又消失并在第一时间交付（尽管很慢）的程序员，可能比让它迅速完成实现的程序员更好。 ，但是当出现问题时，它只会在流程结束时才被发现。

然后，实际的任务是考虑可能的解决方案，实现和方法，并确定需要报告的固定时间范围。

当他们报告时，您可以选择获取更广泛的可能的解决方案，继续实施解决方案或进行反思，因为解决方案的定义仍然不够清晰

对于尚不清楚答案的研究性问题，更let论需要做的事情，我通常建议先花x倍的时间。

“我什至不知道这是否有可能，但是我可能花两天时间研究它。这可能不会给我们提供解决方案，但是也许我可以排除某些事情，并且我可能会有一个想法接下来的一些具体步骤是什么，它们意味着什么时间投入，然后我们可以决定采取另一步骤是否有意义。”

因此，将不确定性放在另一个方向上-估算值非常准确（我将花两天时间），但到那时该如何实现还很不确定。

时间轴，基本上。