为什么开发人员喜欢估算

作为Stack Overflow的首席Web开发人员和长期的技术主管，我了解到准确的估算对于公司的健康和生产力至关重要。多年来，我花了很多时间来开发我的理论，以了解为什么估算和分类分解如此重要，并针对如何做到最好而设计自己的方法。 

下面，我尝试提炼出我学到的教训，以便其他人可以尝试并改进我的技术。现在，我应该清楚，以下建议对我有用。我敢肯定，有其他方法可能对其他人更好。随时在评论中分享您最喜欢的方法。

为什么开发人员要求提供估算值？

对开发工作进行估算的动力通常来自组织中的非开发人员。估算有助于计划和协调产品发布，与其他团队同步工作，确保正确分配资源以满足产品需求，当然还可以在聘用您的团队来完成工作时为客户提供准确的账单外部公司。 

有了这个清单，很明显有很多合理的理由要求您进行估算。并且由于多种原因（内gui，良好的意愿，估算请求者的压力），您甚至可能给出最佳估算。但是，正如我们许多人所学到的那样，虽然给某人一个数字很容易，但要给它一个准确的数字却要困难得多。而且由于其他人对提供的数字的依赖性，错误的评估有时会造成比根本没有评估更大的损害。

好的估算可以提供什么

通过了解其先决条件（以及它们要求的组织和计划水平），准确的估算将使您能够在最短的时间内以高质量的水平交付工作。它将帮助您避免错误的开始以及不必要地丢弃代码的痛苦。这将有助于最小化范围更改。它使您能够以最有效的方式来组织和计划工作，并且还将极大地帮助上一节中提到的所有其他利益相关者。 

估算规则

那么您应该如何估算呢？估算技术是每个开发人员必须自己做出的个人决定。下面将针对过去曾为不同人群使用的不同技术提出建议，以得出最终估计。 

也就是说，这里有一些重要的指导原则（与估算技术无关）。 

除非您对所需的功能有很好的了解，否则请不要编写代码

虽然这与进行实际估算没有直接关系，但它是列表的顶部，因为它是编写高质量软件的重要因素，可以实际执行客户所需的工作。准确的估算可以为他人带来好处，准确的估算可以为您带来的主要结果是，您可以确信自己正在从事的工作，已经考虑过架构和实现可能产生的各种问题，并且您在分解工作和进行估算时已将这些考虑在内。

始终根据规格估算

如果不是基于对功能需求的深入了解而做出的估算，很可能会导致估算不准确，因为它无法说明所有必需的功能。即使召开会议讨论需要什么，除非将其写下来并且所有利益相关者都同意其内容，否则应该假定其中一个利益相关者对需求的理解与其他利益不同。

如果规范中有未解决的问题或缺少详细信息，请不要对该部分进行估算或从事该部分的工作

规范编写过程的重要部分是查看规范并根据需要提出问题。请花些时间来介绍会影响功能的情况和实现细节。标出缺少重要细节的部分（这些通常是规范中最复杂的部分）。 

编写规范需要时间，有时某些要求直到项目后期才被理解。很好，可以接受。这样的结果是，无法对规范中不完整的部分进行准确的估算。

如果估算者尚未彻底检查规格，则估算将不准确

如果不查看规格，估计器就没有适当的能力来估计完成客户端所需功能的能力。解决这一问题没有真正的办法，在这种情况下做出估计实际上与需要完成的工作相关的机会很小。

从事这项工作的开发人员应执行估算

除将要进行工作的人以外的其他人做出的估计更难于正确。即使估算是基于估算者理解的完整规范，它仍然存在一些主要缺点： 

• 每个开发人员的工作速度都不同，因此一个开发人员的估算通常不会转移给第二个开发人员。

• 每个开发人员都会分解并以不同的方式计划他们的工作。

• 不同的开发人员拥有不同的领域知识集，这也使得估计用于学习/理解更改后果的时间非常不同（如果您不具备领域知识，请务必在估计中考虑额外的时间） 。

• 如果开发人员不进行估算，那么他们将错过计划项目执行的极其宝贵的步骤，这将有助于避免不必要的工作并按计划交付功能。

在整个项目过程中（包括范围变更）保持规范和最新估计

理想情况下，随着需求和范围的变化，规格和估算值应在整个项目过程中保持最新。对于正确执行质量检查，它将是必不可少的，对于将来需要进一步了解该功能的任何人，它都将是非常方便的参考。

学科

不要欺负自己对未正确定义的部分进行全面估算

一旦您与利益相关者达成了一个阶段，人们就开始参与进来，让开发人员成为估算的作者，这可能会导致出现压力，要求对尚未完全定义的工作进行估算。最好的意图可能会发生这种常见情况。需要制定计划，并且往往需要没有直接方法进行定义过程的人员来制定计划。当这些计划依赖估计时，它可能会使开发人员陷入困境。

在这种情况下，非常重要的一点是要明确：可行的估算必须基于明确定义的工作。向利益相关者明确这一点很重要。并且，在这样做的同时，请确保突出显示您想要给他们一个可靠的估计，而在不了解整个工作范围的情况下，几乎肯定会得出不可靠的估计。在有需要的情况下，您总是可以提供夸大的，最坏的情况下的估算，但是应该避免这种情况，并且在必须时，一定要让利益相关者知道估算本身可以进行更新并变得更加准确。有关项目定义的更多详细信息是已知的。

不要根据外部时间来估算时间。删除功能。

可能发生的另一种令人不安的情况是，当利益相关者试图根据外部依赖性或其他业务需求来指示估算值时，即使与实际估算值不一致。希望使开发人员能够对此估计值做出承诺，将确保在这些时间限制内完成工作（或者如果没有，则开发人员可以对错过最后期限负责）。到现在应该很清楚，任何不基于对定义明确的要求进行实际分解的估计都不应被认为是可靠的，或者实际上根本不能给出。在这种情况下，正确的响应是协商时间表的范围。如：如果您要在此日期之前发布，那么我们需要减少需要完成的工作量。

将小时转换为几天：切合实际

您的估计最终应该设置一些小时来完成定义的任务。为了进行规划，通常会在项目的早期就询问您需要编码多少天。我发现以小时为单位创建精细估算并将总小时数转换为几天数更为准确。在执行此操作时，请确保将诸如其他职责（错误职责，其他项目），管理职责，休假和假期等因素考虑在内。另外，请确保说明开发人员需要执行的例行任务（会议，电子邮件，规格审查，计划）。我发现，假设每天进行超过6.5个小时的生产性项目工作，可能会导致生产率预期与实际结果不匹配。 

将您的细目分类和估算公开，并征求反馈

一旦您完成了分解并完成了估算，最好将其在线发布并与您的项目经理和团队成员共享。即使他们比您对规范的细节不太熟悉，其他人也可能会在您的细目分类中发现漏洞，或者可能对您未曾想到的特定项目的估计值提出疑问。切记：随着您进入项目的越远，修复问题的成本就成倍增加。更改一条估计线很便宜。不能从头开始重写模块。花额外的时间来征求反馈。

公开发布估算值（并就任务完成情况保持最新状态）也使您对进度更负责（以一种很好的方式）。负责任的PM将定期检查您的进度，尤其是在看起来事情停滞时（无论如何，您都应与PM保持公开沟通）。

可以给出估计范围以及置信度

如果无法及时完成整个规格的估计，请为可以使用的零件提供完整的估计，并为不完整的部分提供范围/可信度。使用您的判断：您可能会要求您对一个大型项目进行100％的置信度评估，但是如果规范尚未准备就绪，那么请清楚您的评估涵盖的范围。从长远来看，对于每个人来说，60％的时间充满信心并拥有60％的信心要好于不说或不以任何内容为基础准确地计算出一个数字。然后，随着规格变得更加完整，估计值也应随之而来。

减轻风险并考虑较大项目的迭代

大型项目（任意定义：预计需要两个月以上的时间，尽管可能会有所不同）面临着一系列挑战。他们将拥有更大的估算值（因此有更多机会弄乱估算值），他们将有更多的人依赖于预计的发布日期而不论其依赖程度如何，他们更有可能拥有大型规格，而并非所有功能都预先定义，并且它们更有可能（至少在某些域中）具有发布/迭代的周期。如何在估算中说明这些？

虽然每个项目都需要根据自身需求进行处理，但是具有迭代功能的大型项目的一般方法应该是在宏观和微观层面上都使用上述准则。如果非常大的项目中有一个工作部分在规范中已完全定义，而其余部分则是松散定义的，则请对第一部分进行细分和估算。如果需要整个项目的完整估算，请根据对功能的了解对整个事情进行非常保守的估算，并附上您的假设和对数量的信心，并继续努力完成整个规格并完成所有工作。您的问题得到了回答。 

这也适用于迭代：如果项目计划需要一个连续的发布周期，并且在整个迭代过程中不断完善和重新定义功能，那么从定义上来说，这对于从头开始进行准确的估算将是极具挑战性的没有定义的功能要求。在这种情况下，您对评估的信心就不能像使用完整功能说明那样自信。如果这是现实情况，并且要求您提供前期估计，那么除了对假设不明确的部分进行非常保守的估计之外，没有其他事情要做，请注意您的假设和置信度。不幸，

确保留出时间处理拉取请求，测试和发布问题 

这是很容易忘记的事情，在按时交付功能以及最后阶段交付时，拖拉时间进行拉动请求测试和产品发布（尤其是当这些都不重要时）会在每个人的口中留下难闻的味道。质量检查和发布最终会持续拖延。在PR是流程必不可少的部分的情况下，尤其是当它们成为非常繁忙的审阅者的瓶颈时，将它们添加到估算中的时间可能并不容易。虽然不一定会增加开发人员的时间（尽管可能会增加反馈的数量），但会增加交付时间。负责任的开发人员应根据项目职责的具体情况，在规划和做出可交付成果的承诺时要考虑到这些因素（例如：

技术技巧

最好的估计包括将要执行的工作分解为小任务-越小越好。估计任务，将其分解，然后重复直到它们变得足够小为止。这是非常彻底和准确的估计方法的本质。建立粒度目标。我建议最多两个小时，然后分解任务，直到全面解决。如果您的任务超过阈值，请进一步细分。然后总结一下。 

您可以使用多种工具来组织此工作。我更喜欢使用Trello卡（每个主要任务一张，带有一个小节清单，以及一个用于粒度的复选框），尽管这确实需要人工计算工时。您还可以使用Excel，MS Project，FogBugz（或那里的许多其他项目组织工具之一）。最重要的是，您使用的工具适用于您和您的流程，并且不会增加组织开销。

还有其他估算方法（我在本文中对估算实践进行了更深入的介绍）。特别是在敏捷世界中，从Planning Poker到许多其他游戏。如果这对您有用，并且可以帮助您获得准确的估算，请继续使用。请记住，依赖于将估算责任从将要进行实际工作的开发人员身上摆脱的技术可能会有风险。 

您是否想过如何最好地提供估计，以便开发人员和开发团队可以与组织的其余部分一起工作？让我们知道您在提示中的提示和技巧。