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