我估计不足。当有人问我要花多长时间时，我什至不敢猜测，因为我将完全失去能力。通常我太乐观了，应该将我的猜测乘以一个较大的X因子...
如何学习做出更好的估算？我的大学没有教它，即使我们为所有的劳动都有最后期限，但我从未想过实际花费多长时间。我应该。为了大家的缘故（尤其是我的）。
Answers:
我仍然不太擅长，但是我发现跟踪您对任务的估计时间和实际花费的时间可能会很有帮助。这样，您就可以对通常的距离有个明确的认识。具有时间跟踪功能的问题管理软件（在我的案例中为Jira）或电子表格可以对此提供很大帮助。
我认为最重要的是体验。
时间管理的墨菲定律：要弄清楚长的东西怎么会走，弄清楚它是如何长应采取并双击它。
然后，移至下一个较高的时间单位。因此，我们为一个为期一天的项目分配了两个星期。
您可以通过集体学习来学习。
我使用Planning Poker。它是一种基于共识的估计技术。
必须跟踪您的估计并将其与您有效完成的工作进行比较。您将获得Velocity。
每次您估算某物时，请乘以您最近的速度以得到准确的估算。
史蒂夫·麦康奈尔（MS Press）撰写的《软件评估》是一本不错的书。
软件评估的主要内容总结如下
没有历史信息，您的估计就毫无用处。
这是我认为迭代项目比大型分阶段瀑布项目获得更多成功的原因之一。他们不打算一次只用一点黑匣子伏都教就只知道他们认为应该是什么的信息，而不是一次只计划一年的计划。每次迭代时，他们都会重新估算/重新计划，并使用最后几次迭代作为估算的基础。
需要牢记的其他几点：
我很惊讶，没有人提到罗伯特·马丁（Robert Martin）的《干净的编码器》（The Clean Coder）中描述的PERT风格的估算技术。在该方法中，您估计三种情况需要花费多长时间：乐观（O），名义（N）和悲观（P）。然后，预期持续时间= (O+4N+P)/6，您的标准偏差为(P-O)/6。
这似乎工作得很好，当管理层真正关心某件事可能花费多长时间时，我已经使用了几次。
正如其他人所评论的，我还通过检查历史数据（“做类似的事情花了多长时间？”）进行了估算。
但是我最喜欢的方法是根本不进行时间估计，而仅进行点估计并获得迭代的速度。如果团队在确定规模和完成工作（用户故事）方面相当一致，那么您甚至不问每件事要花多长时间，就节省了很多时间。
很难估计小时数，并且需要大量工作才能将其分解为足够小的块以进行有效测量。即使那样，它们也很少是正确的，因为变量太多了，我们忘记考虑疾病，休假甚至分心的事情了。
如果我必须进行小时估算，那么我只会尝试在迭代中处理较小的任务。除非我知道可以减少，否则我会以半天的估算值（4、8、12小时）来衡量所有内容。但是我很少估计少于1小时的时间。
首先也是最重要的是，您必须定义一个流程并坚持执行。在流程的每个阶段结束时都包括修订计划。您也可以有序地修改该过程。
其次，进行某种设计。设计是规划的第一步，您要建造没有图纸的房屋。
第三，追踪时间（努力）。您至少应该区分：
与用户进行验收测试（包括修复缺陷）
如果您对每种测试类型的缺陷修复工作进行了测量，那将是很好的选择，但是它增加了复杂性，因此您可以稍后进行。
第四，确定要估算的关键基础项目。例如：
第五，关联基础项目和工作量。例如：
第六，跟踪每个项目的绩效和偏离估计的情况。因此，您可以微调您的相关因子。
第七，重复改进。在第一个项目结束时，您将获得很多见识，到第三个项目，您将可以轻松进行计划和估算。
看看http://en.wikipedia.org/wiki/Personal_Software_Process，它确实有效。
我发现最简单的方法是将上述最小任务划分为每个任务，然后将该估算加倍。然后，我将它们加在一起并加百分之五十。在理想条件下，这给了我大约的项目时间。如果这项工作实际上将与其他工作并行进行，则将需要更长的时间。如果您将不得不等待其他人，则期望他们花费的时间是您认为的两倍。等待内容或反馈或其他信息的时间通常比看起来更长。
在我工作的地方，我们会为过程的每个步骤制定最佳案例/预期案例/最坏案例的估计，这对于指导工作以及评估评估结果的方式很有用。
除了您需要能够抵抗程序员低估任务的诱惑之外，该技术并不是那么重要，但是重要的是对何时可以交付内容保持保守。如果您花了七个星期来构建某些东西，而您答应了八个星期，那么您可以早一点入手，看起来不错，或者进行一些额外的测试并确保可靠性。如果您承诺六个星期，即使您绝对不是您的错，您也可能看起来很糟。如有疑问，请保守地猜测。
除了只写一本书之外，我还提供一些有关如何使用“分解”估算方法的建议：
将您的任务分解为较小的组件任务。尽可能估计每个任务。
添加一个计划和设计任务（包括您现在正在做的事情。）进行估算。
如果您还没有，请添加一个任务，以“将任务组合在一起”。起初，此任务似乎没有用。但是，当您使用这种“分解”估算方法时，总会耗费大量时间来完成“落在任务之间”和“将任务拉在一起”的工作。这可能很难估计。尽你所能。
添加任务以进行测试和记录。您的作业可能不需要大量的测试和文档编制，但是您至少应该花一点时间考虑一下。
将任务估算值相加以获得总体估算值。
继续，然后将总估算值乘以2††。这将使您有时间进行填充：
最后但并非最不重要的一点是，不要害怕为自己勾勒出可能完全错误的估计。有时，不管有多么严重的不准确之处，只要勾勒出所有内容，就可以帮助您开始对所涉及的事物有更好的了解。
††随着您获得越来越多的经验，可以调整此“忽悠因素”以适合您的个人风格和工作环境。
对于开场白，请阅读Barry Boehm的“软件工程经济学”和Tom DeMarco的“控制软件项目”。阅读并消化了这两篇文章后，请阅读Barry Boehm撰写的“使用COCOMO 2进行软件成本估算”。
接下来我要说的是，这将帮助您参加很多概率统计课程，甚至是基础烹饪课。
没有任何估计是完美的。有可能早点来，有一些迟点来。Boehm最初的详细COCOMO模型给出的预测结果证明与实际结果相差30％之内，而不是60％的时间。这比他撰写和出版这本书时的常见情况要好得多。
当您做出最佳猜测时（仅此而已），您就包括了这些概率。如果将估算值加入，则会增加迟到的可能性。如果您增加估计数，则将增加您提早到达或按时完成的可能性。您将其抽出或放出多少控制着概率的变化，并且必须一定取决于提早或迟到的处罚。（在这里插入恐怖故事-多年来有很多恐怖故事！）
DeMarco在某种程度上解决了这个问题。他还指出，存在一个“不可能的区域”：无论尝试哪种英勇英雄，有些时间表都太紧而无法制定。