4

在我们的迭代计划中，我们经常发现自己和这个人处于同一个位置——如果你没有经验，如何估计一个编程任务

在您给出合理的估计之前，我绝对同意原型设计。但这同样适用于任何需要一点架构和设计的东西——但我不太愿意在 sprint 的范围内做这一切。

基本思想是，您尽可能多地确定您有信心的任务，并按照正常情况估计这些任务。对于那些你不确定的领域，应该确定两种“类型”的任务：调查和实施。

调查任务是对您不确定的工作的简要描述，例如“调查如何将 Control X 绑定到数据”。为这些提供了估计。

实施任务是传统的粗略猜测，可能基于分配的故事点，您认为实施该功能需要多长时间。

在 sprint 期间，当调查任务完成时，开发人员应该处于对正在发生的事情有更好了解的阶段。然后可以识别“适当的”任务，它取代了实施占位符。此外，在此阶段可能会确定进一步的调查任务，并继续循环。

在上面的示例中，我们从 7 小时开始的调查任务和估计在 14 小时的实施任务开始。一旦完成第一次调查，任务 1、2 和 3 将在一定程度上被识别和估计，其中任务 3是另一项调查任务，稍后将确定任务 4 和 5。如您所见，第一次实施估计在 14 小时内交付了该功能 - 但实际情况是至少需要 4 + 7 + 3 + 4 + 2 = 20。比最初的估计多三分之一。

替代文字 http://www.duncangunn.me.uk/myweb/images/estimate.png

欢迎所有想法 - 我的直觉是这会飞 - 我是对的还是我是错误的兄弟？

干杯!

4

3 回答 3

3

我们所做的。

某些功能涉及新技术。我们无法准确估计它们。时期。

我们编了一个数字。基于几件事。“感觉”有多难？我们可以通过某种“部分”或“刚刚好”的实现来解决问题吗？

  • 如果很难，那就很难。会很贵。

  • 如果有很多部分，有一个好的内核和一些额外的东西分层，我们有可能只把内核放到一个版本中，然后把其他的东西放在一边。极少数事情是“全有或全无”，其中部分发布是不可能的。在这种情况下，我们必须为“所有人”提供足够的时间，而这会变得很昂贵。

我们的标准方法是获得有效的东西，如果我们因为意想不到的复杂性而用完时间，可能会将事情推迟到以后的 sprint。

你所说的“调查”，我们称之为技术尖峰冲刺。对于新事物，我们会编造估计数字以安抚那些认为有必要过度计划事物的经理。然后我们将技术推向高潮。一旦达到峰值，我们就可以根据我们现在所知道的情况来修改估计值。

于 2009-01-09T11:58:04.600 回答
2

实际上，该功能的实现需要 27 小时——你忘记了第一次调查是 7 小时，所以实际上实际实现的时间几乎是估计的两倍。

您可以通过两种方式进行此操作：

  1. 尽你所能做出估计，并可能会在你的 sprint 中遇到井喷和项目速度下降（只有在功能既紧急又关键时才应该这样做）；或者
  2. 为这个 sprint 安排调查并将实施留给另一个 sprint - 在不知道任务需要多长时间的情况下，产品负责人没有足够的信息来决定在哪个 sprint 中安排它甚至是否执行它一点也不。只有经过估计的任务才应该包含在您的 sprint 中。

第一个选择意味着您的 sprint 和项目估算有些武断。第二个选择为您的 sprint 提供了更多的可预测性。

在您的示例中，可能会为 Sprint 1 安排初步调查，但不知道任务需要多长时间，产品负责人无法决定如何安排它。如果你回来时估计要花 200 小时，产品负责人可能会决定根本不做这个功能，或者推迟到产品的第 2 版。估算出来了，产品负责人为 Sprint 2 安排任务 1、任务 2 和任务 3 的调查。估算任务 3 后，可以在 Sprint 3 或以后安排任务 4 和 5。

于 2009-01-08T23:45:43.510 回答
0

估计特征通常是复杂的任务。一段时间后，您的估计会变得更好。但是好的方法可能是您使用故事点来估计特征。故事点是表达问题复杂性的抽象值（意思是在团队中达成一致）。您应该将相同的复杂性（相同数量的故事点）分配给具有相似复杂性的特征。然后稍后仅估计较小的特征集（或查看历史数据）就足够了，您应该能够估计需要多少时间。

具有相似复杂性的功能需要相似的时间来实现。

于 2009-01-08T23:44:30.627 回答