>故事：重命名文件
并将其分解为以小时计算的任务：
>故事：重命名文件
>任务：创建重命名命令(2h)
>任务：维护所选文件列表(3h)
>任务：连接到F2键(1h)
>任务：添加上下文菜单选项(1h)
然后我会选择一个任务来处理,并跟踪花在它上面的时间.然后我会用另一个任务重复这个过程.在迭代结束时,我可以查看每个任务所花费的时间,将其与估算进行比较,并使用此信息来改进未来的估算.
在完全由测试驱动的情况下,提前明确定义的唯一工作是启动开发的验收测试,并且对于涵盖大量工作的用户故事,验收测试的范围可能过于宽泛给出一个很好的估计.
所以我可以猜测最终完成的任务(如前所述),但是花在它们上的时间要难以跟踪,因为测试会让你在很小的垂直切片中工作,通常会在每个切片上工作任务同时进行.
是否有任何技术可用于提供更详细的估算并准确跟踪执行TDD的时间？我正在使用TargetProcess,它鼓励将用户故事分成如上所述的任务,因此保持这种格式的内容会很有帮助.
在敏捷中,任务和估计都是不断变化的流动事物.所以你可以从(请记住这些是非常松散的例子)开始：
- 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才会起作用,所以我首先要在每次迭代时获得燃尽,然后继续进行.