In agile both tasks and estimates are fluid things that change all the time.
So you might start with (bear in mind that these are very loose examples):
Story: Rename a file
Task: Investigate Problem and break down (0d/5d)
First developer/s pick up that task and break it down as they go:
Story: Rename a file
Task: Investigate Problem and break down (4h/complete)
Task: 1st part (0d/2d)
Task: 2nd part (0d/3d)
Then as they progress these updates get more accurate. New tasks get added and split out as they emerge:
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)
It doesn't matter whether you are using Scrum, Crystal, XP, TDD or any other agile variant - they all rely on fluid estimations.
The fact is that you never know how long something is going to take - you just take your best guess and revise it every day. You'll never get a process where there are no surprises, but with agile you manage their impact.
For instance suppose something nasty comes up:
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)
The story is now taking longer than expected, but everyone knows about it and knows why and you can handle it.
Your tasks and their estimates are constantly changing as the work gets done. A burndown chart is a good indicator of how much is left to do across the team. I wouldn't bother with velocity, but if you do it compares the 'amount done' between different iterations, giving you some idea of a project's momentum. Velocity only works when you have very consistent iteration lengths, team size and classification (size, difficulty, complexity etc) of stories, so I'd start with getting the burndown right each iteration and then move on to it.
We at TargetProcess use simpler tasks for stories:
Story: Rename a file
Task: Specification (2h)
Task: Development (14h)
Task: Testing (6)
Task: User Documentation update (2h)
If Development task takes more than 16 hrs, it is a sign to split it to several smaller tasks. In fact we don't usually create tasks with less than 2-3 h duration.
发布评论
评论（2）
在敏捷中，任务和估算都是不断变化的流动事物。
因此，您可以从以下开始（请记住，这些都是非常松散的示例）：
第一个开发人员接手该任务并分解它：
然后，随着进展，这些更新变得更加准确。 新任务在出现时被添加和拆分：
）无论您使用的是 Scrum、Crystal、XP、TDD 还是任何其他敏捷变体 - 它们都依赖于流畅的估计。
事实上，您永远不知道某件事会花费多长时间 - 您只需做出最好的猜测并每天修改。 您永远不会得到一个没有意外的流程，但通过敏捷，您可以管理它们的影响。
例如，假设发生了一些令人讨厌的事情：
这个故事现在花费的时间比预期的要长，但每个人都知道它并且知道为什么，并且你可以处理它。
随着工作的完成，你的任务和他们的估计会不断变化。 燃尽图可以很好地指示整个团队还有多少工作要做。 我不会为速度而烦恼，但如果你这样做，它会比较不同迭代之间的“完成量”，让你对项目的动力有一些了解。 只有当迭代长度、团队规模和故事分类（规模、难度、复杂性等）非常一致时，速度才起作用，所以我会从每次迭代正确的燃尽图开始，然后继续进行。
In agile both tasks and estimates are fluid things that change all the time.
So you might start with (bear in mind that these are very loose examples):
First developer/s pick up that task and break it down as they go:
Then as they progress these updates get more accurate. New tasks get added and split out as they emerge:
It doesn't matter whether you are using Scrum, Crystal, XP, TDD or any other agile variant - they all rely on fluid estimations.
The fact is that you never know how long something is going to take - you just take your best guess and revise it every day. You'll never get a process where there are no surprises, but with agile you manage their impact.
For instance suppose something nasty comes up:
The story is now taking longer than expected, but everyone knows about it and knows why and you can handle it.
Your tasks and their estimates are constantly changing as the work gets done. A burndown chart is a good indicator of how much is left to do across the team. I wouldn't bother with velocity, but if you do it compares the 'amount done' between different iterations, giving you some idea of a project's momentum. Velocity only works when you have very consistent iteration lengths, team size and classification (size, difficulty, complexity etc) of stories, so I'd start with getting the burndown right each iteration and then move on to it.
我们在 TargetProcess 对故事使用更简单的任务：
故事：重命名文件
如果开发任务需要超过 16 小时，则是将其拆分为几个较小任务的标志。 事实上，我们通常不会创建持续时间少于 2-3 小时的任务。
We at TargetProcess use simpler tasks for stories:
Story: Rename a file
If Development task takes more than 16 hrs, it is a sign to split it to several smaller tasks. In fact we don't usually create tasks with less than 2-3 h duration.