使用TDD时,如何在规划和估算方面获得足够的细节？

Question

在计划过去2周的迭代时,我采用了一个用户故事:

• 故事:重命名文件

并将其分解为以小时计算的任务:

• 故事:重命名文件
  • 任务:创建重命名命令(2h)
  • 任务:维护所选文件列表(3h)
  • 任务:连接到F2键(1h)
  • 任务:添加上下文菜单选项(1h)

然后我会选择一个任务来处理,并跟踪花在它上面的时间.然后我会用另一个任务重复这个过程.在迭代结束时,我可以查看每个任务所花费的时间,将其与估算进行比较,并使用此信息来改进未来的估算.

在完全由测试驱动的情况下,提前明确定义的唯一工作是启动开发的验收测试,并且对于涵盖大量工作的用户故事,验收测试的范围可能过于宽泛给出一个很好的估计.

所以我可以猜测最终完成的任务(如前所述),但是花在它们上的时间要难以跟踪,因为测试会让你在很小的垂直切片中工作,通常会在每个切片上工作任务同时进行.

是否有任何技术可用于提供更详细的估算并准确跟踪执行TDD的时间？我正在使用TargetProcess,它鼓励将用户故事分成如上所述的任务,因此保持这种格式的内容会很有帮助.

Answer 1

在敏捷中，任务和估算都是不断变化的流动事物。

因此，您可以从以下开始（请记住，这些都是非常松散的示例）：

• 故事：重命名文件
  • 任务：调查问题并分解（0d/5d）

第一个开发人员接手该任务并将其分解：

• 故事：重命名文件
  • 任务：调查问题并分解（4 小时/完成）
  • 任务：第 1 部分（0 天/2 天）
  • 任务：第二部分（0d/3d）

然后，随着他们的进展，这些更新会变得更加准确。新任务在出现时被添加和拆分：

• 故事：重命名文件
  • 任务：调查问题并分解（4 小时/完成）
  • 任务：第 1 部分（4 小时/7 小时）
  • 任务：第二部分（1小时/20小时）
  • 任务：在 x (0h/5h) 上工作时实现的新任务

无论您使用的是 Scrum、Crystal、XP、TDD 还是任何其他敏捷变体，都没有关系 - 它们都依赖于流动的估计。

事实上，你永远不知道某件事会花费多长时间 - 你只需做出最好的猜测并每天进行修改。您永远不会得到一个没有意外的流程，但通过敏捷，您可以管理它们的影响。

例如，假设发生了一些令人讨厌的事情：

• 故事：重命名文件
  • 任务：调查问题并分解（4 小时/完成）
  • 任务：第 1 部分（10 小时/完成）
  • 任务：第二部分（10小时/3小时）
  • 任务：在x上工作时实现的新任务（3小时/1小时）
  • 任务：解决在处理 y 时发现的混乱问题（0h/5d）

这个故事现在花费的时间比预期的要长，但每个人都知道它并且知道为什么，并且你可以处理它。

随着工作的完成，你的任务和他们的估计会不断变化。燃尽图可以很好地指示整个团队还有多少工作要做。我不会为速度而烦恼，但如果你这样做，它会比较不同迭代之间的“完成量”，让你对项目的动力有一些了解。只有当迭代长度、团队规模和故事分类（规模、难度、复杂性等）非常一致时，速度才起作用，所以我会从每次迭代正确的燃尽图开始，然后继续进行。