在过去计划 2 周的迭代时，我采用了一个用户故事：
并将其分解为以小时为单位估算的任务：
然后我会选择一个任务来完成，并跟踪花费在它上面的时间。然后我会用另一个任务重复这个过程。在迭代结束时，我可以查看每个任务所花费的时间，将其与估计进行比较，并使用此信息来改进未来的估计。
当工作完全由测试驱动时，唯一提前明确定义的工作是启动开发的验收测试，并且在涵盖大量工作的用户故事中，验收测试的范围可能过于广泛，无法给出一个好的估计。
所以我可以猜测最终会完成的任务（和以前一样），但是花在这些任务上的时间更难跟踪，因为测试让你在很小的垂直切片中工作，通常在每个部分都工作同时任务。
在执行 TDD 时，我是否可以采用任何技术来提供更详细的估计并准确跟踪时间？我正在使用TargetProcess，它鼓励将用户故事拆分为如上所述的任务，因此保持这种格式会很有帮助。
在敏捷中，任务和估计都是不断变化的流动事物。
所以你可以从（记住这些是非常松散的例子）开始：
- 故事：重命名文件
- 任务：调查问题并分解 (0d/5d)
第一个开发人员接手该任务并在他们进行时将其分解：
- 故事：重命名文件
- 任务：调查问题并分解（4 小时/完成）
- 任务：第一部分（0d/2d）
- 任务：第二部分（0d/3d）
然后随着他们的进步，这些更新变得更加准确。新任务在出现时被添加和拆分：
- 故事：重命名文件
- 任务：调查问题并分解（4 小时/完成）
- 任务：第一部分（4h/7h）
- 任务：第二部分（1h/20h）
- 任务：在 x (0h/5h) 上工作时实现的新任务
无论您使用的是 Scrum、Crystal、XP、TDD 还是任何其他敏捷变体都无关紧要——它们都依赖于流动估计。
事实是，你永远不知道某件事要花多长时间——你只是做出最好的猜测并每天修改它。你永远不会得到一个没有惊喜的过程，但是通过敏捷你可以管理它们的影响。
例如，假设出现了一些令人讨厌的事情：
- 故事：重命名文件
- 任务：调查问题并分解（4 小时/完成）
- 任务：第一部分（10小时/完成）
- 任务：第二部分（10h/3h）
- 任务：在 x (3h/1h) 上工作时实现的新任务
- 任务：解决在处理 y (0h/5d) 时发现的混乱问题
这个故事现在花费的时间比预期的要长，但每个人都知道它并且知道为什么并且你可以处理它。
随着工作的完成，您的任务和他们的估计会不断变化。燃尽图可以很好地指示整个团队还有多少工作要做。我不会担心速度，但如果你这样做，它会比较不同迭代之间的“完成量”，让你对项目的动力有所了解。Velocity 仅在您具有非常一致的迭代长度、团队规模和故事分类（大小、难度、复杂性等）时才有效，因此我会从每次迭代的燃尽图开始，然后继续进行。
我们在 TargetProcess 对故事使用更简单的任务：
故事：重命名文件
如果开发任务需要超过 16 小时，则表明将其拆分为几个较小的任务。事实上，我们通常不会创建持续时间少于 2-3 小时的任务。