如何进行估算最终对开发人员有用

让任何开发人员估计他们完成一个项目需要多长时间。您会看到他们眼中的厌恶。并且有充分的理由。数十年来，许多管理人员错误地使用了估算值，然后经理要求团队对估算值负责，就好像这是实际截止日期一样。更令人沮丧的是，在许多情况下，这些经理仅以他们从您那里听到的最低限度采取行动！就像他们有一个min（）函数一样，他们只是一直在试图降低数字。但是工程并不是魔术！难怪#NoEstimates这个标签变得著名。

为了做到这一点，我们（尤其是管理人员）需要遵守一些规则。然后，我们将了解估计如何改善您的软件质量。是的，您没看错。好吧，在我看来，很明显。

不要迷恋估计规则！

规则1：永远不要将估算视为对截止日期的承诺

否则，您可能会立即失去团队的信任，而很难重新获得他们的信任。有趣的是，即使是经理，他们也不知道到底要做什么。因此，他们会如何想象开发人员会确切地知道他们将要完成的工作，因为他们的生产力会受到随机影响，而且大多数时候项目都存在很多未知数？没什么是魔法????！

规则2：永远不要在团队之外或与其他相关部门共享您的估计

我想这甚至比规则1还糟。传达估计值存在风险，它会自动转换为截止日期的承诺，其他部门也会相应地调整其优先级，从而给您的团队带来更大的压力。

规则3：如果您有一个大概的估计，那么现实很可能在上下边界之间，但不在下边界之间

作为经理，您不能仅凭愿望实际影响交货日期。除非您更改项目的范围或质量。但是否则，您将无法。如果给您一个高估和低估的大致数字，则考虑这两种信息会更明智。甚至PMP也引入了术语PERT（程序评估和审查技术）来接近最终结果。

规则4：估算的不确定性与未知数有关。未知数越多，LESS就会使您对估计有信心

而且，未知数越少，您应该对估计值就越有信心。

这是什么意思？每个项目都有一定程度的未知性。当开发人员给您一个大概的估计（例如4到8天）时，他们会为您提供2条有价值的信息：天数和他们对此的信心。另一种查看方式是：6天有2天的不确定性（或33％不确定性）。如果不确定性很重要，则意味着可能有许多未知因素可能影响最终交付。这些未知因素可能会产生很大的影响，或者根本没有影响。我的意思是，当不确定性很高时，估计出现错误的可能性更大（甚至超出定义的边界）。

规则5：首先解决未知问题确实会增加估计值的置信度

未知数有2种类型：未知未知数和已知未知数。对于未知的未知数，您无能为力。而且，根据定义，开发人员无法真正将其考虑在内。他们可能会再花几天时间以防万一，而这些天通常是花在调试上的。但是，对于已知的未知数，花费项目的最初几个小时或几天来解决这些问题，可以极大地减轻对最终工作的怀疑。这样，您可以减少规则4中提到的不确定性。例如，6天+/- 2天可以变成6天+/- 1天。

顺便说一下，您可以了解规格是可能的已知未知数的一部分。规格越精确，不确定性就越小。因此，上班了，下午。

规则6：如果您认为估算值不错（并且您是一位期望很高的经理），则可能要问正确的问题

如果开发人员告诉您一个项目要花4天，而您预期是5天，而且您总是有过于乐观的倾向，那么这可能意味着开发人员对任务的想法并不相同像你一样做。我个人建议您问自己以下一些问题：

规格是否被理解？
技术或体系结构能否扩展到我们想要的用户数量？
它可以持续至少24个月吗？
该解决方案以及即将做出的选择有什么风险？

关键是，您可能不会考虑解决方案的相同级别的需求。再次，没有魔术。

规则7：如果您需要截止日期，请遵守不确定性

有时您需要提前数周/数月定义发布日期，因为您不是唯一需要在特定项目的截止日期之前完成发布的人。这是您需要考虑的现实。在这种情况下，您是否听说过不确定性锥？

该图很不言自明，但可以简单地说：您不能太早要求诺言。承诺与未知因素不能很好地配合。因此，第一件事就是将发布日期设置为尽可能晚。但是，如果您真的必须尽早给出时间表，请先让您的团队进行探索，并尝试解决所有未知因素，然后再开始商定日期。但是请记住，您的团队应该尽可能地定义或影响日期。如果没有，您将有机会影响项目的范围或质量。

规则8：分析瘫痪很容易克服

好吧...所以这本身不是规则。但这对管理人员来说是一个不错的选择。开发人员起初可能并不真正欣赏它，但是我认为它确实引发了对话，如果最后您同意估算值可以为开发人员带来价值，那么开发人员可能会接受此规则。 ????

如果开发人员由于任务太复杂而不想给您一个估算（公平地说，估算不是一件容易的事），那么发起讨论的一种简单方法就是抛出一个很高的数字，例如“ 100天”？开发人员可能会说：“地狱，不！” 然后，您用越来越少的数字向下移动，直到开发人员告诉您“可能是”。然后执行相同的操作，但是数量很少。开发人员会再次告诉您“不可能！” 再一次，直到开发人员告诉您“可能”为止。那里！您首先需要进行估算。但是请不要忘记遵守所有其他规则-估计时间不是承诺的交付时间。

好的，我们已经遵守了规则。请不要在评论中添加更多内容。我将根据您的输入来编辑文章。现在，让我们假设我们的团队尊重有关估算如何以及为什么对开发人员有用的所有规则。

为什么开发人员对估计不满意？

如果您不需要预定的发布日期，您可能想知道为什么甚至需要估算。有效的问题，我的朋友。

在我看来，估算的重点是它们围绕未知因素进行讨论和相互理解。当您讨论估计值时（如果其中有一点不合时宜），它将引起讨论，开发人员可以去白板上草绘对完成的工作的理解。如果他们的理解有些偏离，其他开发人员可能会澄清代码体系结构中的某些观点。您甚至可能会遇到高级开发人员可以从更多初级用户那里学到一些很棒的技巧的情况。

估算产生了讨论，以教育开发人员有关代码及其体系结构。他们最终可以提高代码本身的质量，甚至可以帮助开发人员比其他人更快地完成任务。但是，请注意，要充分利用估算值，应该将它们作为一个团队来完成。您也可以在事后评估中对估算值进行反思；将会有更多的教训要学习。

最后，所获得的收益与团队在估算上花费的时间之间进行了权衡。有很多方法可以做到这一点。例如，估算可以有自己的专门会议，应尽可能集中精力。我们都知道会议……足够说了。

最后一点。如果您对已获得的估算有其他想法，则也可以考虑“游戏化”过程以吸引开发人员。例如，在连续几周或每个项目中对团队的准确性进行评分，并在刷新新记录时获得一些祝贺性礼物。好吧，只是一个主意:)。如果我错过任何规则，或者您不同意我的结论，请告诉我。