更多#NoEstimates

对#NoEstimates帖子的讨论和反应相当有趣。 坦率地说，对于一些我没有答案的问题也很好。 无论如何，我都会尝试。

让我们从经典的项目管理开始。 它告诉我们，为了进行计划，我们需要估计成本和持续时间。 估计技术已经存在了一段时间。

@gil_zilberfeld均基于工作流程的基础统计来估计概率。 有什么替代方案4知道成本/进度/技术？

— Glen B. Alleman（@galleman） 2014年6月19日

我们可以“知道”东西的假设存在问题。 我们对未来一无所知。 猜测或估计，即我们目前所说的替代方法。 要改进，我们最多只能尝试进行预测。 我们希望有一个可以信任的预测，可以制定进一步的计划。 如果信心很重要，那么：

@gil_zilberfeld因此，在估算方面要有足够的能力，以感到自信，并据此做出决定。 不应该引起争议。 @加勒曼

—彼得·克雷茨曼（@PeterKretzman） 2014年6月19日

听起来很简单…

估计是一种技能。 它需要过程知识和从经验推论的能力。 与其他技能一样 ，您可以改善估计。 如果我们正在做的工作与您之前所做的类似，则效果很好。 但是，如果历史与未来不同，那么我们将陷入困境。 以我的经验，通常是这样。 变化丰富。

在我参与的项目中，有很多未知数：技术，算法，知识水平，团队能力和可用性，甚至心情。 所有这些都会影响交货日期，从而影响估计的“正确性”。

既然有那么多“未知未知数”，那么进行合理估计的机会是什么？ 我们可以肯定地估计“已知”，尝试对“已知未知”进行改进，但是对估计该部分进行改进是不切实际的。

然而问题仍然存在

@adubism如何确定所需功能所需的成本？ @ 彼得· 克雷茨曼 @gil_zilberfeld

— Glen B. Alleman（@galleman） 2014年6月19日

好吧，明智的人，如果估算可以得出糟糕的结果，那有什么选择呢？

敏捷方法考虑到现实是复杂的，因此会在短迭代中涉及反馈循环。 产品负责人可以决定关闭项目或在每个周期继续进行。

我认为我们应该在组织层面朝这个方向发展。 与其尝试预测所有事情，不如设定短期目标和检查点。 花少量的钱，看看结果，然后再决定。 用您估计的时间做一些工作。

改进估计值是局部优化的一个很好的例子。 毕竟，客户宁愿手上有原型，也不愿树上的计划。

如果他要估算？ 然后，我们将给出一个粗略的估算，该估算不会花费太多。

我知道项目经理不会喜欢这个答案。 我知道年轻的我也不会。

但是，我指的是“敏捷宣言”中的明智之词，该词尤其适用于估算：

我们正在探索通过开发和帮助他人来开发软件的更好方法。

有更好的方法。 我们会找到他们的。

翻译自: https://www.javacodegeeks.com/2014/06/more-noestimates.html