我的意思是说出我们做过的编程项目以及它花了多长时间。老板从来没有抱怨过，但有时我觉得事情花的时间太长了。但这可能是因为我也很不耐烦。让我知道比较经验。

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

瑞安

解决方案

我自己完成了1到6个月之间的项目，而且我总是倾向于将原来的估算值翻倍或者翻两番。

基于胆量的估计是有经验的，但是我们确实需要详细说明所涉及的任务以获得合理的东西。

如果我们有规格或者至少有一些约束，则可以开始创建任务(设计用户页面，设计标签页面，实施用户页面，实施标签页面，编写标签查询等)。

完成此操作后，将其添加并加倍。如果我们需要与他人协调，则将其增加三倍。

详细记录实际时间，这样我们就可以评估项目完成后的准确性，并磨练估算技能。

我从事的项目从2周到1年不等。总的来说，我的估计是很好的，后验的。但是，在项目开始时，我通常会感到沮丧，因为我的估计值太大。

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

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

诀窍是使用基于证据的计划(请参见《 Joel on Software》)。

事实是，如果我们计划多一点的时间，如果没有问题，我们将使用它来改进代码库。如果出现问题，我们仍在估计之内。

最好只是安排自己的时间，记录估计并确定平均休假百分比。鉴于此，只要我们保持一致，就可以根据我们认为完成工作的时间适当地估计实际时间。这不仅仅是确定估计有多么糟糕，而是要考虑不可避免的干扰(包括个人和基于老板/客户的)的规律性。

这是基于Joel Spolsky的"基于证据的计划"(Evidence Based Scheduling)的基础知识，他解释说，另一个重要的主要方面是将任务分解为一口大小(最多16小时)的任务，并将这些任务估算并加在一起以完成最终项目全部的。

比较两个编程项目实际上是不可能的，因为有太多的因素意味着仅来自一个度量标准的度量标准不适用于另一个(例如，所使用的特定技术，开发人员的先前经验，不断变化的要求)。除非我们要淘汰与以前构建的系统几乎完全相同的另一系统，否则估计将不太可能是准确的。

需要注意的是，当我们与同一个团队一起构建现有系统的下一个修订版时；获得的特定经验确实提高了估计下一批工作的能力。

我已经看到过太多尝试估算方法的尝试，但都没有成功。他们可能有伪科学的魅力，但实际上却行不通。

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

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

我在一个较小的团队(5个开发人员，1个领导)中工作，我们很多人一次从事多个项目，有的有大有小。根据项目的优先级，管理的异想天开和其他团队(如果需要)的可用性，一个项目的工作会散布在其他项目之间。

因此，是的，可能尚需3个月的工作时间，但在6个月的时间内可能需要3个月的工作时间。

我相信Joel就此写过一篇文章：我们可以做的是请团队中的每个开发人员详细安排任务(需要完成的所有步骤)，并要求他们估算每个步骤所需的时间。稍后，当项目完成时，将实时时间与估计时间进行比较，我们将获得每个开发人员的偏见。当开始一个新项目时，请他们再次评估时间，然后将其乘以每个开发人员的偏差以使值接近实际期望。

经过几个项目后，我们应该有很好的估计。

霍夫施塔特定律：

"即使考虑到霍夫施塔特定律，它总是比我们期望的更长的时间。"

我相信这是因为：

• 工作会扩展以填补可用的时间。无论我们削减了不必要的功能多么残酷，如果截止日期更加紧迫，我们也会更加残酷。
• 项目期间发生意外问题。

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

几乎可以肯定，我将所有正在进行的非编程工作都排除在外：会议，体系结构设计，咨询其他人，因为他们碰巧碰到了我所了解的事情，管理员。因此，以"坐在那里编码"的角度看似合理的工作速率，并期望这种速率一直持续下去，这对我们自己是不公平的。在我们"应该更快"的事实之后，这就是很多感觉的来源。