There's a difference between est. work effort - how long something should take to complete - and est. when something will be done (aka duration) - when that something is expected to get completed based on other tasks.
You can never predict the future and any est. is just that - an est. - the likelihood of being able to predict 1 week out in 1/2 hour increments isn't that great, what if the first 6 tasks take 5 min. more to complete, you're 1/2 off (after 3 hours of work).
I would suggest creating a work breakdown structure (WBS) to determine effort and then group the tasks into no less then day groupings and no more then week groupings (depending on the overall duration of the project - you never want to have an increment representing more then 2-3% of overall work effort). This will allow programs to switch between tasks (normal working conditions) without the pressure of having to meet a specific 1/2 hour delivery.
I guess it depends on how accurate you want to be.
I personally use minutes as "days" or "months" can be misleading time periods. For example if you say something will take 1 day - does that mean 24 hours solid work? Or 8 hours? Or the average 3-4 hours of productivity within a working day?
All tasks should be listed, but if they are small you can often group them. But remember that just because it's only changing a label text there is more time involved that just changing the label, you have to find it, open the file, make the change, commit the changes, update any documentation, test it etc - so tasks very rarely only take less than 1 minute.
Also try to put an upper limit on the task time. If your adding tasks that are taking over 3-4 hours, break them down into smaller sub-tasks and list those. This will give you a much more accurate estimate.
I tend to use units of hours should they be appropriate (1h, 4.5h, 6h, etc). Once days creep into the equation then I tend to not use hours and keep days as the only unit being used (3d, 7d, 10d). Overestimating slightly gives room to accommodate those undesired but expected complications you will hit along the way.
I have found myself sorting tasks into these categories:
Half a day
Whole day
Whole week
Several weeks
In my work environment where we do a lot of second-level support, it doesn't make sense to have a more granular system. It is also good to have some slack in the planning, so that you can take an hour to make small improvements to your work environment.
The units (minutes, hours, days, weeks, fortnights) don't matter.
Pick a unit that makes your manager happy.
Just be clear that an estimate of 30 minutes, .5 hour or .0625 days is only a guess, not a fact.
An estimate of 0.0625 days or 30 minutes looks really precise because it has a lot of decimal places. However, any ambiguity about the requirements, the architecture, the language, the libraries, the unit tests, or anything else will make this number incorrect.
The very best you can hope for is that the average of all your estimates is reasonably close to the actual facts as they unfold. This means that half your estimates will be too low and half will be too high. It also means that some fraction of your estimates will be really, really far from your manager's hoped-for accuracy.
Well, it really depends. Personally, I like tasks to be smaller (should be estimated in hours, usually using the something close to Fibonacci series: 0.5, 1, 2, 3, 5, 8, ...).
About small tasks, usually they should be estimated too. Even minor changes require some work like creating tests, seeing if none of the other ones broke, sending to server, etc. You could create a 15 min in the series for stuff like these :)
Planning and estimating time required is never the goal of your project, so those units must serve some purpose.
The good rule to use is this: split the task into smaller chunks, until you know exactly what you should do next (and it is not planning). This "knowing exactly what to do" thing is a little subjective, but tasks longer than 2 days rarely fit into this category.
Scrum uses values of 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40 and 100. The time of the values is in hours, when you plan in finer detail (breaking down feature requests into technical tickets) and days, when you plan the bigger picture (big-picture features).
In general, if you estimate a ticket over 20 hours (or 20 days), your tasks should be split up into smaller pieces.
发布评论
评论（8）
预计工作量（完成某件事需要多长时间）和预计何时完成某事（又名持续时间）- 预计根据其他任务完成某件事的时间是有区别的。
你永远无法预测未来，任何估计都只是 - 一个估计 - 能够以 1/2 小时的增量预测 1 周后的可能性并不大，如果前 6 项任务需要 5 分钟怎么办？ 如果还有更多需要完成，您将获得 1/2 的折扣（工作 3 小时后）。
我建议创建一个工作分解结构（WBS）来确定工作量，然后将任务分组为不少于一天的分组，不多于一周的分组（取决于项目的总体持续时间 - 你永远不希望有代表更多的增量）然后是总体工作量的 2-3%）。 这将允许程序在任务（正常工作条件）之间切换，而无需满足特定 1/2 小时交付的压力。
There's a difference between est. work effort - how long something should take to complete - and est. when something will be done (aka duration) - when that something is expected to get completed based on other tasks.
You can never predict the future and any est. is just that - an est. - the likelihood of being able to predict 1 week out in 1/2 hour increments isn't that great, what if the first 6 tasks take 5 min. more to complete, you're 1/2 off (after 3 hours of work).
I would suggest creating a work breakdown structure (WBS) to determine effort and then group the tasks into no less then day groupings and no more then week groupings (depending on the overall duration of the project - you never want to have an increment representing more then 2-3% of overall work effort). This will allow programs to switch between tasks (normal working conditions) without the pressure of having to meet a specific 1/2 hour delivery.
我想这取决于你想要的准确程度。
我个人使用分钟，因为“天”或“月”可能会误导时间段。 例如，如果您说某件事需要 1 天，这是否意味着需要 24 小时扎实工作？ 还是8小时？ 或者一个工作日内平均 3-4 小时的生产力？
应列出所有任务，但如果它们很小，您通常可以将它们分组。 但请记住，仅仅因为它只是更改标签文本，因此仅更改标签就需要更多时间，您必须找到它，打开文件，进行更改，提交更改，更新任何文档，测试它等 - 所以任务很少只需要不到 1 分钟。
还要尝试对任务时间设置上限。 如果您添加的任务需要花费超过 3-4 小时，请将其分解为更小的子任务并列出它们。 这将为您提供更准确的估计。
I guess it depends on how accurate you want to be.
I personally use minutes as "days" or "months" can be misleading time periods. For example if you say something will take 1 day - does that mean 24 hours solid work? Or 8 hours? Or the average 3-4 hours of productivity within a working day?
All tasks should be listed, but if they are small you can often group them. But remember that just because it's only changing a label text there is more time involved that just changing the label, you have to find it, open the file, make the change, commit the changes, update any documentation, test it etc - so tasks very rarely only take less than 1 minute.
Also try to put an upper limit on the task time. If your adding tasks that are taking over 3-4 hours, break them down into smaller sub-tasks and list those. This will give you a much more accurate estimate.
如果合适的话，我倾向于使用小时单位（1 小时、4.5 小时、6 小时等）。 一旦天数进入等式，我倾向于不使用小时，而将天数作为唯一使用的单位（3d、7d、10d）。 稍微高估可以为您在此过程中遇到的那些不受欢迎但预期的复杂情况提供空间。
I tend to use units of hours should they be appropriate (1h, 4.5h, 6h, etc). Once days creep into the equation then I tend to not use hours and keep days as the only unit being used (3d, 7d, 10d). Overestimating slightly gives room to accommodate those undesired but expected complications you will hit along the way.
我发现自己将任务分为以下几类：
在我的工作环境中，我们提供大量二级支持，因此拥有更细粒度的系统是没有意义的。 在计划中留出一些空间也很好，这样你就可以花一个小时对你的工作环境进行一些小的改进。
I have found myself sorting tasks into these categories:
In my work environment where we do a lot of second-level support, it doesn't make sense to have a more granular system. It is also good to have some slack in the planning, so that you can take an hour to make small improvements to your work environment.
预测未来确实很难。
单位（分钟、小时、天、周、两周）并不重要。
选择一个让你的经理满意的单位。
请注意，30 分钟、0.5 小时或 0.0625 天的估计值只是猜测，并非事实。
0.0625 天或 30 分钟的估计看起来非常精确，因为它有很多小数位。 然而，任何关于需求、架构、语言、库、单元测试或其他任何方面的模糊性都会导致这个数字不正确。
您所能期望的最好情况是，您所有估计的平均值相当接近实际情况。 这意味着您的估计一半会太低，一半会太高。 这也意味着你的估计的某些部分将与你的经理所希望的准确性相差甚远。
It's really hard to predict the future.
The units (minutes, hours, days, weeks, fortnights) don't matter.
Pick a unit that makes your manager happy.
Just be clear that an estimate of 30 minutes, .5 hour or .0625 days is only a guess, not a fact.
An estimate of 0.0625 days or 30 minutes looks really precise because it has a lot of decimal places. However, any ambiguity about the requirements, the architecture, the language, the libraries, the unit tests, or anything else will make this number incorrect.
The very best you can hope for is that the average of all your estimates is reasonably close to the actual facts as they unfold. This means that half your estimates will be too low and half will be too high. It also means that some fraction of your estimates will be really, really far from your manager's hoped-for accuracy.
嗯，这确实取决于。 就我个人而言，我喜欢较小的任务（应以小时为单位进行估计，通常使用接近斐波那契数列的值：0.5、1、2、3、5、8，...）。
对于小任务，通常也应该进行估计。 即使是很小的更改也需要一些工作，例如创建测试、查看其他测试是否没有损坏、发送到服务器等。您可以在本系列中为此类内容创建 15 分钟的时间:)
Well, it really depends. Personally, I like tasks to be smaller (should be estimated in hours, usually using the something close to Fibonacci series: 0.5, 1, 2, 3, 5, 8, ...).
About small tasks, usually they should be estimated too. Even minor changes require some work like creating tests, seeing if none of the other ones broke, sending to server, etc. You could create a 15 min in the series for stuff like these :)
规划和估计所需的时间从来都不是项目的目标，因此这些单元必须服务于某种目的。
使用的好规则是：将任务分成更小的块，直到您确切知道下一步应该做什么（并且这不是计划）。 这种“确切地知道要做什么”的事情有点主观，但超过 2 天的任务很少适合这一类别。
Planning and estimating time required is never the goal of your project, so those units must serve some purpose.
The good rule to use is this: split the task into smaller chunks, until you know exactly what you should do next (and it is not planning). This "knowing exactly what to do" thing is a little subjective, but tasks longer than 2 days rarely fit into this category.
Scrum 使用 0、0.5、1、2、3、5、8、13、20、40 和 100 的值。当您进行更详细的计划时（将功能请求分解为技术票证），这些值的时间以小时为单位。以及几天，当您计划更大的图景（大图特征）时。
一般来说，如果您估计工单的时间超过 20 小时（或 20 天），您的任务应该分成更小的部分。
Scrum uses values of 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40 and 100. The time of the values is in hours, when you plan in finer detail (breaking down feature requests into technical tickets) and days, when you plan the bigger picture (big-picture features).
In general, if you estimate a ticket over 20 hours (or 20 days), your tasks should be split up into smaller pieces.