使用TDD时,如何在规划和估算方面获得足够的细节？
|
在计划过去2周的迭代时,我采用了一个用户故事：
>故事：重命名文件 并将其分解为以小时计算的任务： >故事：重命名文件 >任务：创建重命名命令(2h) 然后我会选择一个任务来处理,并跟踪花在它上面的时间.然后我会用另一个任务重复这个过程.在迭代结束时,我可以查看每个任务所花费的时间,将其与估算进行比较,并使用此信息来改进未来的估算. 在完全由测试驱动的情况下,提前明确定义的唯一工作是启动开发的验收测试,并且对于涵盖大量工作的用户故事,验收测试的范围可能过于宽泛给出一个很好的估计. 所以我可以猜测最终完成的任务(如前所述),但是花在它们上的时间要难以跟踪,因为测试会让你在很小的垂直切片中工作,通常会在每个切片上工作任务同时进行. 是否有任何技术可用于提供更详细的估算并准确跟踪执行TDD的时间？我正在使用TargetProcess,它鼓励将用户故事分成如上所述的任务,因此保持这种格式的内容会很有帮助. 解决方法
在敏捷中,任务和估计都是不断变化的流动事物.
所以你可以从(请记住这些是非常松散的例子)开始：
第一个开发人员接受该任务并将其分解为：
然后随着他们的进展,这些更新变得更加准确新任务在出现时会被添加和拆分：
无论您使用的是Scrum,Crystal,XP,TDD还是其他任何敏捷变体都无关紧要 – 它们都依赖于流量估算. 事实上,你永远不知道要采取多长时间 – 你只需要做出最好的猜测并每天进行修改.你永远不会得到一个没有惊喜的过程,但是你可以通过敏捷来管理它们的影响. 例如,假设出现了令人讨厌的事情：
这个故事现在花费的时间比预期的要长,但每个人都知道它,知道原因,你可以处理它. 随着工作的完成,您的任务和估算会不断变化.燃尽图表是衡量整个团队剩余工作量的一个很好的指标.我不打扰速度,但是如果你这样做,则比较不同迭代之间的“完成量”,让你对项目的动力有所了解.只有当你拥有非常一致的迭代长度,团队规模和故事的分类(大小,难度,复杂性等)时,Velocity才会起作用,所以我首先要在每次迭代时获得燃尽,然后继续进行. （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |