time note
10m
10m
1.5h got pulled away to fix a production bug
10m
45m server offline due to upgrade
10m
10m
4h entire staff evacuated due to bomb scare
10m
10m
If you record how long (including interruptions) it takes to complete a given type or size of task, than for future tasks, you just need to identify the type/size of a new task, and apply the historical data to figure out how long such a task typically takes. Since the data you've been recording included various interruptions, etc., then the estimate for the future will factor those in as well.
Example: lets say this is the data for the last 10 times you had to make a textual update to a web page:
time note
10m
10m
1.5h got pulled away to fix a production bug
10m
45m server offline due to upgrade
10m
10m
4h entire staff evacuated due to bomb scare
10m
10m
Clearly, it only takes you 10 minutes to do the actual update. However, the average time it took in real life is about 45 minutes. If you have 5 updates to do tomorrow, estimate them at 45 minutes each.
This approach should also help factor in unforeseen items that are part of the task -- it only takes 10 minutes to do the code, but 15 minutes to deploy it because you have to FTP it over here, then rsync it over there, etc. Again, that will show up in the historical data.
First things first, there is no way that you can estimate the length of every little task in big projects. Categorize your tasks by criticality, and only estimate times for those tasks that are crucial to your project.
The next move would be to allocate free time amidst less critical tasks that are simultaneously going on with the critical tasks. Gantt charts would serve this purpose beautifully.
If you have consistently unforeseen tasks then you can est. the about of time you work on those and add as a buffer to determine end date (not work effort for the project since the unforeseen tasks sound as if they are assoc. with other projects). There have been studies that show an avg. programmer is 60% productive on an assigned project, so buffering 30%-40% might seem high (or it might not) but would be a good starting point.
发布评论
评论（6）
关键是历史数据。
如果您记录完成给定类型或大小的任务需要多长时间（包括中断），那么对于未来的任务，您只需要识别新任务的类型/大小，并应用历史数据来计算需要多长时间这样的任务通常需要。由于您记录的数据包括各种中断等，因此对未来的估计也会将这些因素考虑在内。
示例：假设这是您最近 10 次必须对网页进行文本更新的数据：
显然，您只需要 10 分钟即可完成实际更新。然而，现实生活中的平均时间约为 45 分钟。如果明天有 5 项更新要做，估计每项更新需要 45 分钟。
这种方法还应该有助于考虑任务中不可预见的事项——编写代码只需要 10 分钟，但部署它需要 15 分钟，因为你必须在这里通过 FTP 传输它，然后在那里进行 rsync，等等。同样，这将显示在历史数据中。
The key is historical data.
If you record how long (including interruptions) it takes to complete a given type or size of task, than for future tasks, you just need to identify the type/size of a new task, and apply the historical data to figure out how long such a task typically takes. Since the data you've been recording included various interruptions, etc., then the estimate for the future will factor those in as well.
Example: lets say this is the data for the last 10 times you had to make a textual update to a web page:
Clearly, it only takes you 10 minutes to do the actual update. However, the average time it took in real life is about 45 minutes. If you have 5 updates to do tomorrow, estimate them at 45 minutes each.
This approach should also help factor in unforeseen items that are part of the task -- it only takes 10 minutes to do the code, but 15 minutes to deploy it because you have to FTP it over here, then rsync it over there, etc. Again, that will show up in the historical data.
我倾向于以工作时间为单位进行估算，这样如果我完成了一项任务，我就可以指出我做了什么，以及需要多长时间。
不过我倾向于使用这种方法：
http://www.joelonsoftware.com/articles/fog0000000245.html
这样主管们当我从不可预见的任务中回来后，可以看到还剩下多少工作。
I tend to give estimates in hours of work, so that if I am pulled off of a task, then I can point to what I have done, and how much longer.
I tend to use this method though:
http://www.joelonsoftware.com/articles/fog0000000245.html
That way supervisors can see how much more work is left, once I get back from the unforeseen task.
务实的程序员建议明智地选择度量单位，给自己留出余地。
因此，与其说“120 天”，不如说“4 个月”（或“半年”）。
此外，如果您有未知的情况，请提前向客户说明这一事实并让他们了解情况，不会有什么坏处。
The Pragmatic Programmers advise choosing your units of measure wisely to give yourself leeway.
So, rather than saying "120 days" say "4 months" (or "half a year").
Also, if you have unknowns, stating this fact to your customers upfront, and keeping them in the loop, can't hurt.
除非您意识到某项任务已被忽略，否则不太可能，因为您无法根据定义知道您错过了什么。
Not likely until you realize that a task has been overlooked since you can't know what you're missing by definition.
首先，您无法估计大项目中每项小任务的长度。按重要性对任务进行分类，并仅估算对项目至关重要的任务的时间。
下一步将是在与关键任务同时进行的不太关键的任务中分配空闲时间。 甘特图可以很好地实现这一目的。
First things first, there is no way that you can estimate the length of every little task in big projects. Categorize your tasks by criticality, and only estimate times for those tasks that are crucial to your project.
The next move would be to allocate free time amidst less critical tasks that are simultaneously going on with the critical tasks. Gantt charts would serve this purpose beautifully.
如果您始终有不可预见的任务，那么您可以估计完成这些任务的时间，并将其添加为缓冲区以确定结束日期（不是项目的工作量，因为不可预见的任务听起来好像它们与其他项目相关） 。有研究表明平均。程序员在分配的项目上的工作效率为 60%，因此缓冲 30%-40% 可能看起来很高（也可能不是），但这将是一个很好的起点。
If you have consistently unforeseen tasks then you can est. the about of time you work on those and add as a buffer to determine end date (not work effort for the project since the unforeseen tasks sound as if they are assoc. with other projects). There have been studies that show an avg. programmer is 60% productive on an assigned project, so buffering 30%-40% might seem high (or it might not) but would be a good starting point.