敏捷 - 任务拆分 - 是否需要估算？

Question

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

我绝对赞成在能够给出合理估计之前进行原型制作。但是对于需要一些架构和设计的任何事情都适用——但我不太舒服在短时间内完成所有这些工作。

基本思想是尽可能多地确定您有信心的任务，并像平常一样对其进行估计。对于那些您不确定的领域，应该确定两种“类型”任务：调查和实施。

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

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

在冲刺过程中，当调查任务完成后，开发人员应该处于一个更好的阶段，他们对正在进行的事情有了更好的了解。此时可以确定“适当”的任务，它们取代了实施占位符。另外，在这个阶段可能会确定进一步的调查任务，循环继续。

在上述示例中，我们从一个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

欢迎所有想法 - 我的直觉告诉我这会成功 - 我对还是错？

干杯！

- Duncan

Answer 1

我们的工作内容。

一些功能涉及新技术，我们无法准确估计它们。这是事实。

我们会制定一个数字，基于一些因素。有多难？我们能否通过某种“部分”或“刚好够用”的实现来完成？

• 如果很难，那就很难，成本会很高。

• 如果有很多部分，其中有一点好处和一些额外的东西，我们可以考虑只将核心部分发布，并将其他东西留到以后。极少数情况下，“全部或无”的情况无法进行部分发布。在这种情况下，我们必须为“全部”提供足够的时间，这会很昂贵。

我们的标准做法是让东西运行起来，如果由于意外复杂性而耗尽时间，可能会推迟一些事情到以后再处理。

您所称的“调查”，我们称之为技术突破冲刺。对于新的东西，我们会制定一个估算数字，以取悦那些觉得过度规划是必要的管理人员。然后我们会冲刺技术。一旦完成了技术突破，我们可以根据我们现在所知道的来修订估算。

- S.Lott

---

谢谢，知道我们至少在正确的轨道上是很好的。我喜欢在面对很多不确定性的问题时，尝试突破解决方案，然后才感到给出估计是很合适的。有趣的是，有时候你只需要坚定地表达自己的看法！ - Duncan

Answer 2

实际上，这个功能的实现花费了27个小时 - 你忘记了最初的7个小时的调查，所以实际上，实际的实现时间几乎是估计时间的两倍。

在这方面，有两种方法：

1.尽力做出估计，并有可能在短期内经历项目速度下降（只有在该功能既紧急又关键时才应这样做）；或者

2.将此次调查安排在本次冲刺中，将实现留给另一个冲刺 - 没有了解任务需要多长时间，产品负责人没有足够的信息来决定在哪个冲刺中安排它甚至是否要执行。只有已经估计过的任务才应包括在您的冲刺中。

第一种选择意味着您的冲刺和项目估计有些随意。第二种选择为您的冲刺提供了更可预测性。

对于您的示例，最初的调查可以安排在Sprint 1中，但是如果没有了解任务需要多长时间，产品负责人无法决定如何安排它。如果您回来估计需要200个小时，产品负责人可能会决定根本不执行该功能，或者将其延迟到产品的第二个版本中。估计完成后，产品负责人安排任务1、任务2和任务3的调查在Sprint 2中进行。在估计任务3之后，可以在Sprint 3或以后安排任务4和任务5。

- Chris Latta

---

有一些有趣的想法，谢谢。 - Duncan

Answer 3

通常估算功能是一项复杂的任务。随着时间的推移，你的估算会变得更准确。但一个好的方法是使用故事点来估算功能。故事点是一个抽象的值（团队共同认可的意义），用于表达问题的复杂性。 对于复杂度相似的功能，你应该给予相同的复杂度（相同数量的故事点）。然后，在以后的估算中，只需估算较小的一组功能（或查看历史数据），就能够估算出所需的时间量。

复杂度相似的功能需要相似的实现时间和努力。

- jan