在过去的几个月中，出现了许多博客文章，内容涉及评估，评估是不必要的，评估是浪费的……也许我们应该停止完全评估，而只从事编写软件的业务。如果我们的估计总是错误的，并且在大多数情况下是错误的，为什么我们甚至应该首先尝试进行估计？
上海福彩官方网站主义者避开绝对估计，而倾向于相对估计，而绝对值则应以故事点之类的更抽象的单位来估计。故事点以斐波那契等非线性序列进行度量，以进一步从绝对时间的任何概念中抽象出它们的价值。结果，上海福彩官方网站估计仅在具有已知测得速度的稳定团队的情况下才有意义。
许多团队在进行上海福彩官方网站估算时并没有比在传统估算中更好，并且我认为这就是导致许多人拒绝完全估算这一概念的原因。如果上海福彩官方网站估算的工作效果不如传统估算好，那为什么还要烦恼估算呢？就个人而言，我非常喜欢估算并向与我合作的所有团队教授。估算是可行的……但前提是您了解自己这样做的原因。
您会发现…估算根本不是在估算。估计是关于需求的共同理解和对解决方案的共同理解。当团队有估计问题时，几乎永远不会有估计问题，这是一个共同的理解问题。如果您可以深入了解共同的理解问题，那么您将解决估计问题。
多种组织功能障碍可能导致共同的理解问题。一些最常见的问题是在产品方面……业务参与不足，对业务问题的理解不足以及需求分解不足往往会导致sprint计划会议时间太长且不够详细。
当在sprint计划中发生太多错误类型的发现时……团队会感到疲倦和沮丧，最终会在无法充分了解他们将要构建什么或将如何构建它的情况下致力于sprint可交付成果。他们已经进行了估算和讨论，但从未深入细节。这总是导致在sprint期间进行过多的发现，进行过多的意外工作以及过多的错过可交付成果。
另一个共同的理解问题来自技术债务……糟糕的体系结构，质量问题，甚至只是不熟悉代码库的团队，所有这些都会导致做出承诺而又不明确实际需要完成的工作。当您普遍对要求缺乏理解，再加上对代码普遍缺乏理解时，难怪人们会对估算感到沮丧。
放弃估计基本上就是放弃让业务对他们将要获得的东西或何时获得它的任何想法……即使是在较高水平上。我的观点是，我们不能放弃估计，我们需要在估计方面变得更好，但这意味着我们需要在建立共同的理解方面变得更好。我认为建立共同的理解是我们估计的主要原因。
与其说数量，不如说是重要的，而是共同的理解。如果我们在没有建立共同理解的情况下进行评估，那么我们会错过价值所在，而评估总是很差的。如果我们的估算过程提高了共同理解的水平，则我们的估算不一定正确，但是它们应该是一致的……而一致性就是我们所需要的，尤其是为了建立稳定的速度。
因此，如果我们想要更好的估计，或者至少想要更一致的估计，我们的目标不是更好地估计，而是更多的共识。现在的问题变成了……我们如何建立更多的共识？
