tdd - 使用 TDD 时，如何在规划和估算中获得足够的细节？

Question

关闭。这个问题不满足Stack Overflow guidelines .它目前不接受答案。












想改善这个问题吗？更新问题，使其成为 on-topic对于堆栈溢出。

3年前关闭。




Improve this question




过去在计划为期 2 周的迭代时，我拍摄了一个用户故事:

故事:重命名文件

并将其分解为以小时为单位估算的任务:

故事:重命名文件

任务:创建重命名命令 (2h)

任务:维护选定文件的列表(3 小时)

任务:连接到 F2 键 (1h)

任务:添加上下文菜单选项 (1h)

然后我会选择一个任务来处理，并跟踪花在工作上的时间。然后我会用另一个任务重复这个过程。在迭代结束时，我可以查看在每项任务上花费的时间，将其与估计进行比较，并使用此信息来改进 future 的估计。

当完全由测试驱动时，唯一提前明确定义的工作是启动开发的验收测试，并且在涵盖大量工作的用户故事中，验收测试的范围可能过于广泛给出一个很好的估计。

所以我可以猜测最终将完成的任务(和以前一样)，但是花费在它们上的时间很难跟踪，因为测试让你在很小的垂直切片中工作，通常对每个工作都有一点同时任务。

在执行 TDD 时，我是否可以采用任何技术来提供更详细的估计并准确跟踪时间？我正在使用 TargetProcess这鼓励将用户故事拆分为如上所述的任务，因此保持这种格式会很有帮助。

Answer 1

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

所以你可以从(请记住，这些都是非常松散的例子):

• Story: Rename a file
  • Task: Investigate Problem and break down (0d/5d)

第一位开发人员接手该任务并在进行时分解:

• Story: Rename a file
  • Task: Investigate Problem and break down (4h/complete)
  • Task: 1st part (0d/2d)
  • Task: 2nd part (0d/3d)

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

• Story: Rename a file
  • Task: Investigate Problem and break down (4h/complete)
  • Task: 1st part (4h/7h)
  • Task: 2nd part (1h/20h)
  • Task: new task realised while working on x (0h/5h)

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

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

例如，假设出现了一些令人讨厌的事情:

• Story: Rename a file
  • Task: Investigate Problem and break down (4h/complete)
  • Task: 1st part (10h/complete)
  • Task: 2nd part (10h/3h)
  • Task: new task realised while working on x (3h/1h)
  • Task: resolve messy issue found while working on y (0h/5d)

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

随着工作的完成，您的任务及其估计会不断变化。燃尽图是一个很好的指标，表明整个团队还有多少工作要做。我不会在意速度，但如果你这样做，它会比较不同迭代之间的“完成量”，让你对项目的动力有一些了解。 Velocity 仅在您拥有非常一致的迭代长度、团队规模和故事分类(规模、难度、复杂性等)时才有效，因此我会从每次迭代都正确完成燃尽图开始，然后继续进行。