代码之家 › 专栏 › 技术社区 › GraemeF

在使用TDD时,如何在规划和评估中获得足够的细节?[关闭]

targetprocess estimation agile tdd

GraemeF · 技术社区 · 15 年前

在过去计划为期两周的迭代时,我采用了一个用户案例:

然后把它分解成几个小时的任务:

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

当完全由测试驱动工作时,唯一提前明确定义的工作是启动开发的验收测试,并且在涉及大量工作的用户故事中,验收测试的范围可能太广,无法给出很好的估计。

因此,我可以猜测最终将完成的任务(与以前一样),但是花费在这些任务上的时间更难跟踪,因为测试使您在微小的垂直切片中工作,通常在同一时间处理每个任务的一部分。

在执行TDD时,有没有什么技术可以用来提供更详细的估计和精确的跟踪时间?我正在使用 TargetProcess 它鼓励将用户故事分解为上面概述的任务,因此保持这种格式会很有帮助。

2 回复 | 直到 8 年前

Keith 15 年前

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

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

故事:重命名文件

第一个开发人员拿起该任务,并在执行时将其分解:

故事:重命名文件

任务:第一部分(0d/2d)

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

任务:调查问题并分解(4小时/完成)

任务:第二部分(1小时/20小时)

任务:在x上工作时实现的新任务(0h/5h)

不管你是在使用Scrum、Crystal、XP、TDD还是其他敏捷变体,它们都依赖于流畅的估计。

事实上,你永远不知道一件事要花多长时间——你只是做了最好的猜测,然后 每天修改 . 你永远不会得到一个没有惊喜的过程,但是通过敏捷,你可以管理它们的影响。

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

故事:重命名文件

任务:第一部分(10小时/完成)

任务:第二部分(10小时/3小时)

任务:在x上工作时实现的新任务(3h/1h)

任务:解决处理y时发现的混乱问题(0h/5d)

这个故事现在花的时间比预期的要长,但每个人都知道,知道原因,你也能处理。

Michael Dubakov 15 年前

我们在TargetProcess中使用更简单的任务来编写故事:

故事:重命名文件

如果开发任务需要超过16个小时,那么将其拆分为几个较小的任务是一个标志。事实上,我们通常不会创建持续时间少于2-3小时的任务。