敏捷 - 任务分解 - 估计与否？ [关闭]

Question

在我们的迭代计划期间，我们经常发现自己和这个人处于同一位置 - How to estimate a programming task if you have no experience in it

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

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

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

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

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

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

alt text http://www.duncangunn.me.uk/myweb/images/estimate.png

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

干杯！

Answer 1

我们做什么。

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

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

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

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

我们的标准方法是获取可行的东西，如果由于意外的复杂性而用完时间，可能会将事情推迟到以后的 sprint。

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

Answer 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。

Answer 3

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

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