Oh yes, the general rule from long hard experience is give the project your best estimate for time, double it, and that's about how long it will actually take!
We have to, because our idiot manager always reduces them without any justification whatever. Of course, as soon as he realizes we do this, we're stuck in an arms race...
I fully expect to be the first person to submit a two-year estimate to change the wording of a dialog.
As a lot said, it's a delicate balance between experience and risk.
Always start by breaking down the project in manageable pieces, in fact, in pieces you can easily imagine yourself starting and finishing in the same day
When you don't know how to do something (like when it's the first time) the risk goes up
When your risk goes up, that's where you start with your best guess, then double it to cover some of the unexpected, but remember, you are doing that on a small piece of the project, not the whole project itself
The risk goes up also when there's a factor you don't control, like the quality of an input or that library that seems it can do everything you want but that you never tested
Of course, when you gain experience on a specific task (like connecting your models to the database), the risk goes down
Sum everything up to get your subtotal...
Then, on the whole project, always add about another 20-30% (that number will change depending on your company) for all the answers/documents/okays you will be waiting for, meetings we are always forgetting, the changes of idea during the project and so on... that's what we call the human/political factor
And again add another 30-40% that accounts for tests and corrections that goes out of the tests you usually do yourself... such as when you'll first show it to your boss or to the customer
Of course, if you look at all this, it ends up that you can simplify it with the magical "double it" formulae but the difference is that you'll be able to know what you can squeeze in a tight deadline, what you can commit to, what are the dangerous tasks, how to build your schedule with the important milestones and so on.
I'm pretty sure that if you note the time spent on each pure "coding" task and compare it to your estimations in relation to its riskiness, you won't be so far off. The thing is, it's not easy to think of all the small pieces ahead and be realistic (versus optimistic) on what you can do without any hurdle.
I say when I can get it done. I make sure that change requests are followed-up with a new estimation and not the "Yes, I can do that." without mentioning it will take more time. The person requesting the change will not assume it will take longer.
Of course, you'd have be to an idiot not to add 25-50%
The problem is when the idiot next to you keeps coming up with estimates which are 25-50% lower than yours and the PM thinks you are stupid/slow/swinging it.
(Has anyone else noticed project managers never seem to compare estimates with actuals?)
I always double my estimates, for the following reasons:
1) Buffer for Murphy's Law. Something's always gonna go wrong somewhere that you can't account for.
2) Underestimation. Programmers always think things are easy to do. "Oh yeah, it'll take just a few days."
3) Bargaining space. Upper Management always thinks that schedules can be shortened. "Just make the developers work harder!" This allows you to give them what they want. Of course, overuse of this (more than once) will train them to assume you're always overestimating.
Note: It's always best to put buffer at the end of the project schedule, and not for each task. And never tell developers that the buffer exists, otherwise Parkinson's Law (Work expands so as to fill the time available for its completion) will take effect instead. Sometimes I do tell Upper Management that the buffer exists, but obviously I don't give them reason #3 as justification. This, of course depends on how much your boss trusts you to be truthful.
<sneaky> Instead of inflating your project's estimate, inflate each task individually. It's harder for your superiors to challenge your estimates this way, because who's going to argue with you over minutes. </sneaky>
But seriously, through using EBS I found that people are usually much better at estimating small tasks than large ones. If you estimate your project at 4 months, it could very well be 7 month before it's done; or it might not. If your estimate of a task is 35 minutes, on the other hand, it's usually about right.
FogBugz's EBS system shows you a graph of your estimation history, and from my experience (looking at other people's graphs as well) people are indeed much better at estimating short tasks. So my suggestion is to switch from doing voodoo multiplication of your projects as totals, and start breaking them down upfront into lots of very small tasks that you're much better at estimating.
A lot depends on how detailed you want to get - but additional 'buffer' time should be based on a risk assessment - at a task level, where you put in various buffer times for: High Risk: 50% to 100% Medium Risk: 25% to 50% Low Risk: 10% to 25% (all dependent on prior project experience).
Risk areas include:
est. of requirement coverage (#1 risk area is missing components at the design and requirement levels)
knowledge of technology being used
knowledge/confidence in your resources
external factors such as other projects impacting yours, resource changes, etc.
So, for a given task (or group of tasks) that cover component A, initial est. is 5 days and it's considered a high risk based on requirements coverage - you could add between 50% to 100%
Industry standard: every request will take six weeks. Some will be longer, some will be shorter, everything averages out in the end.
Also, if you wait long enough, it no longer becomes an issue. I can't tell you how many times I've gone through that firedrill only to have the project/feature cut.
You can calculate project durations in two ways - one is to work out all the tasks involved and figure out how long each will take, factor in delays, meetings, problems etc. This figure always looks woefully short, which is why people always say things like 'double it'. After some experience in delivering projects you'll be able to tell very quickly, just by looking briefly at a spec how long it will take, and, invariably, it will be double the figure arrived at by the first method...
It's a better idea to add specific buffer time for things like debugging and testing than to just inflate the total time. Also, by taking the time up front to really plan out the pieces of the work, you'll make the estimation itself much easier (and probably the coding, too).
If anything, make a point of recording all of your estimates and comparing them to actual completion time, to get a sense of how much you tend to underestimate and under what conditions. This way you can more accurately "inflate".
I wouldn't say I inflate them but I do like to use a template for all possible tasks that could be involved in the project.
You find that not all tasks in your list are applicable to all projects, but having a list means that I don't let any tasks slip through the cracks with me forgetting to allow some time for them.
As you find new tasks are necessary, add them to your list.
This way you'll have a realistic estimate.
I tend to be optimistic in what's achievable and so I tend to estimate on the low side. But I know that about my self so I tend to add on an extra 15-20%.
I also keep track of my actuals versus my estimates. And make sure the time involved does not include other interruptions, see the accepted answer for my SO question on how to get back in the flow.
I wouldn't call additional estimated time on a project "inflated" unless you actually do complete your projects well before your original estimation. If you make a habit of always completing the project well before your original estimated time, then project leaders will get wise and expect it earlier.
If they're based on nothing but a vague intuition of how much code it would require and how long it would take to write that code, then you better pad them a LOT to account for subtasks you didn't think of, communication and synchronization overhead, and unexpected problems. Of course, that kind o estimate is nearly worthless anyway.
OTOH, if your estimates are based on concrete knowledge of how long it took last time to do a task of that scope with the given technology and number of developers, then inflation should not be necessary, since the inflationary factors above should already be included in the past experiences. Of course there will be probably new factors whose influence on the current project you can't foresee - such risks justify a certain amount of additional padding.
This is part of the reason why Agile teams estimate tasks in story points (an arbitrary and relative measurement unit), then as the project progresses track the team's velocity (story points completed per day). With this data you can then theoretically compute your completion date with accuracy.
If you inflate your estimate based on past experiences to try and compensate for your inherent optimism, then you aren't inflating. You are trying to provide an accurate estimate. If however you inflate so that you will always have fluff time, that's not so good.
Any organization that asks its programmers to estimate time for coarse-grained features is fundamentally broken.
Steps to unbreak:
Hire technical program managers. Developers can double as these folks if needed.
Put any feature request, change request, or bug into a database immediately when it comes in. (My org uses Trac, which doesn't completely suck.)
Have your PMs break those requests into steps that each take a week or less.
At a weekly meeting, your PMs decide which tickets they want done that week (possibly with input from marketing, etc.). They assign those tickets to developers.
Developers finish as many of their assigned tickets as possible. And/or, they argue with the PMs about tasks they think are longer than a week in duration. Tickets are adjusted, split, reassigned, etc., as necessary.
Code gets written and checked in every week. QA always has something to do. The highest priority changes get done first. Marketing knows exactly what's coming down the pipe, and when. And ultimately:
Your company falls on the right side of the 20% success rate for software projects.
It's not rocket science. The key is step 3. If marketing wants something that seems complicated, your PMs (with developer input) figure out what the first step is that will take less than a week. If the PMs are not technical, all is lost.
Drawbacks to this approach:
When marketing asks, "how long will it take to get [X]?", they don't get an estimate. But we all know, and so do they, that the estimates they got before were pure fiction. At least now they can see proof, every week, that [X] is being worked on.
We, as developers, have fewer options for what we work on each week. This is indubitably true. Two points, though: first, good teams involve the developers in the decisions about what tickets will be assigned. Second, IMO, this actually makes my life better.
Nothing is as disheartening as realizing at the 1-month mark that the 2-month estimate I gave is hopelessly inadequate, but can't be changed, because it's already in the official marketing literature. Either I piss off the higher-ups by changing my estimate, risking a bad review and/or missing my bonus, or I do a lot of unpaid overtime. I've realized that a lot of overtime is not the mark of a bad developer, or the mark of a "passionate" one - it's the product of a toxic culture.
And yeah, a lot of this stuff is covered under (variously) XP, "agile," SCRUM, etc., but it's not really that complicated. You don't need a book or a consultant to do it. You just need the corporate will.
Always provide estimates as a range (i.e. 1d-2d) rather than a single number. The difference between the numbers tells the project manager something about your confidence, and allows them to plan better.
Use something like FogBugz' Evidence Based-Scheduling, or a personal spreadsheet, to compare your historical estimates to the time you actually took. That'll give you a better idea than always doubling. Not least because doubling might not be enough!
Don't forget you (an engineer) actually estimate in ideal hours (scrum term).
While management work in real hours.
The difference being that ideal hours are time without interuption (with a 30 minute warm up after each interuption). Ideal hours don't include time in meetings, time for lunch or normal chit chat etc.
Take all these into consideration and ideal hours will tend towards real hours.
Example: Estimated time 40 hours (ideal) Management will assume that is 1 week real time.
If you convert that 40 hours to real time:
Assume one meeting per day (duration 1 hour)
one break for lunch per day (1 hour)
plus 20% overhead for chit chat bathroom breaks getting coffie etc.
8 hour day is now 5 hours work time (8 - meeting - lunch - warm up). Times 80% effeciency = 4 hours ideal time per day.
This your 40 hour ideal will take 80 hours real time to finish.
发布评论
评论（30）
我把最坏的情况加倍，但仍然不够。
I take my worst case scenario, double it, and it's still not enough.
承诺不足，交付过多。
Under-promise, over-deliver.
哦，是的，根据长期的艰苦经验得出的一般规则是为项目提供最佳的时间估计，将其加倍，这就是实际需要多长时间！
Oh yes, the general rule from long hard experience is give the project your best estimate for time, double it, and that's about how long it will actually take!
我们必须这样做，因为我们的白痴经理总是毫无理由地减少它们。 当然，一旦他意识到我们这样做，我们就陷入了军备竞赛……
我完全希望成为第一个提交两年估计以改变对话措辞的人。
叹息。
We have to, because our idiot manager always reduces them without any justification whatever. Of course, as soon as he realizes we do this, we're stuck in an arms race...
I fully expect to be the first person to submit a two-year estimate to change the wording of a dialog.
sigh.
正如很多人所说，这是经验和风险之间的微妙平衡。
始终从将项目分解为可管理的部分开始，事实上，您可以轻松地想象自己在同一天开始和完成的部分
当您不知道如何做某事（例如第一次时）时，风险就会上升
当你的风险上升时，你就从最好的猜测开始，然后加倍以涵盖一些意外情况，但请记住，你是在这样做的项目的一小部分，而不是整个项目本身
当存在您无法控制的因素时，风险也会增加，例如输入的质量或似乎可以做您想做的一切但您永远不会做的库测试
当然，当您获得特定任务的经验（例如将模型连接到数据库），风险就会降低
然后，在整个项目上，始终添加大约 20-30%（该数字将根据情况而变化）关于您的公司）所有您将等待的答案/文件/好吧，我们总是忘记的会议，项目期间想法的变化等等......这就是我们所说的人为/政治因素
并再次添加另外 30-40%，用于考虑您通常自己进行的测试之外的测试和更正...例如当您将首先向您的老板或客户展示它，
当然，如果你看看这一切，最终你可以用神奇的“双倍”公式来简化它，但不同之处在于你将能够知道你要做什么可以在紧迫的期限内挤出时间，您可以承诺什么，有哪些危险的任务，如何通过重要的里程碑制定您的时间表等等。
我非常确定，如果您记下每个纯“编码”任务所花费的时间，并将其与您对其风险的估计进行比较，那么您的差距不会太大。 问题是，考虑未来的所有小事并对你可以毫无障碍地做的事情保持现实（而不是乐观）并不容易。
As a lot said, it's a delicate balance between experience and risk.
Always start by breaking down the project in manageable pieces, in fact, in pieces you can easily imagine yourself starting and finishing in the same day
When you don't know how to do something (like when it's the first time) the risk goes up
When your risk goes up, that's where you start with your best guess, then double it to cover some of the unexpected, but remember, you are doing that on a small piece of the project, not the whole project itself
The risk goes up also when there's a factor you don't control, like the quality of an input or that library that seems it can do everything you want but that you never tested
Of course, when you gain experience on a specific task (like connecting your models to the database), the risk goes down
Sum everything up to get your subtotal...
Then, on the whole project, always add about another 20-30% (that number will change depending on your company) for all the answers/documents/okays you will be waiting for, meetings we are always forgetting, the changes of idea during the project and so on... that's what we call the human/political factor
And again add another 30-40% that accounts for tests and corrections that goes out of the tests you usually do yourself... such as when you'll first show it to your boss or to the customer
Of course, if you look at all this, it ends up that you can simplify it with the magical "double it" formulae but the difference is that you'll be able to know what you can squeeze in a tight deadline, what you can commit to, what are the dangerous tasks, how to build your schedule with the important milestones and so on.
I'm pretty sure that if you note the time spent on each pure "coding" task and compare it to your estimations in relation to its riskiness, you won't be so far off. The thing is, it's not easy to think of all the small pieces ahead and be realistic (versus optimistic) on what you can do without any hurdle.
我说什么时候能完成。 我确保变更请求之后会得到新的估计，而不是“是的，我可以做到”。 更不用说这将需要更多时间。 请求更改的人不会认为需要更长的时间。
I say when I can get it done. I make sure that change requests are followed-up with a new estimation and not the "Yes, I can do that." without mentioning it will take more time. The person requesting the change will not assume it will take longer.
当然，如果你不加 25-50%，那你就是个白痴了。
问题是，当你旁边的白痴不断提出比你的低 25-50% 的估计值时，PM 会认为你很愚蠢/很慢/摇摆它。
（有没有其他人注意到项目经理似乎从不将估算与实际进行比较？）
Of course, you'd have be to an idiot not to add 25-50%
The problem is when the idiot next to you keeps coming up with estimates which are 25-50% lower than yours and the PM thinks you are stupid/slow/swinging it.
(Has anyone else noticed project managers never seem to compare estimates with actuals?)
我总是将我的估计加倍，原因如下：
1）墨菲定律的缓冲。 总会在某个你无法解释的地方出现问题。
2）低估。 程序员总是认为事情很容易做。 “哦，是啊，几天就可以了。”
3）议价空间。 高层管理人员总是认为工期可以缩短。 “就让开发商更加努力吧！” 这使您可以为他们提供他们想要的东西。 当然，过度使用这个（不止一次）会让他们认为你总是高估。
注意：最好将缓冲区放在项目计划的末尾，而不是每个任务。 并且永远不要告诉开发人员缓冲区存在，否则帕金森定律（工作会扩展以填满可用的完成时间）将会生效。 有时我确实告诉高层管理人员存在缓冲区，但显然我没有给他们理由#3 作为理由。 当然，这取决于你的老板对你诚实的信任程度。
I always double my estimates, for the following reasons:
1) Buffer for Murphy's Law. Something's always gonna go wrong somewhere that you can't account for.
2) Underestimation. Programmers always think things are easy to do. "Oh yeah, it'll take just a few days."
3) Bargaining space. Upper Management always thinks that schedules can be shortened. "Just make the developers work harder!" This allows you to give them what they want. Of course, overuse of this (more than once) will train them to assume you're always overestimating.
Note: It's always best to put buffer at the end of the project schedule, and not for each task. And never tell developers that the buffer exists, otherwise Parkinson's Law (Work expands so as to fill the time available for its completion) will take effect instead. Sometimes I do tell Upper Management that the buffer exists, but obviously I don't give them reason #3 as justification. This, of course depends on how much your boss trusts you to be truthful.
不要夸大项目的估算，而是单独夸大每项任务。 你的上级很难以这种方式质疑你的估计，因为谁会在几分钟内与你争论。
但说实话，通过使用 EBS，我发现人们通常更擅长估算小任务而不是大任务。 如果您预计项目需要 4 个月完成，那么很可能需要 7 个月才能完成； 或者可能不会。 另一方面，如果您预计一项任务需要 35 分钟，则通常是正确的。
FogBugz 的 EBS 系统会向您显示估计历史记录的图表，根据我的经验（也查看其他人的图表），人们确实更擅长估计短期任务。 因此，我的建议是不要将项目作为总数进行巫术乘法，而是开始将它们预先分解为许多您更擅长估计的非常小的任务。
然后将整个结果乘以 3.14。
<sneaky>
Instead of inflating your project's estimate, inflate each task individually. It's harder for your superiors to challenge your estimates this way, because who's going to argue with you over minutes.
</sneaky>
But seriously, through using EBS I found that people are usually much better at estimating small tasks than large ones. If you estimate your project at 4 months, it could very well be 7 month before it's done; or it might not. If your estimate of a task is 35 minutes, on the other hand, it's usually about right.
FogBugz's EBS system shows you a graph of your estimation history, and from my experience (looking at other people's graphs as well) people are indeed much better at estimating short tasks. So my suggestion is to switch from doing voodoo multiplication of your projects as totals, and start breaking them down upfront into lots of very small tasks that you're much better at estimating.
Then multiply the whole thing by 3.14.
很大程度上取决于您想要获得的详细程度 - 但额外的“缓冲”时间应基于风险评估 - 在任务级别，您可以为以下内容设置不同的缓冲时间：
高风险：50% 至 100%
中等风险：25% 至 50%
低风险：10% 到 25%（全部取决于之前的项目经验）。
风险领域包括：
。 ，对于涵盖组件 A 的给定任务（或任务组），初始预计为 5 天，并且根据需求覆盖范围，它被认为是高风险 - 您可以添加 50% 到 100%
A lot depends on how detailed you want to get - but additional 'buffer' time should be based on a risk assessment - at a task level, where you put in various buffer times for:
High Risk: 50% to 100%
Medium Risk: 25% to 50%
Low Risk: 10% to 25% (all dependent on prior project experience).
Risk areas include:
So, for a given task (or group of tasks) that cover component A, initial est. is 5 days and it's considered a high risk based on requirements coverage - you could add between 50% to 100%
六个星期。
行业标准：每个请求将需要六周的时间。 有些会更长，有些会更短，最后一切都会平均下来。
而且，如果您等待足够长的时间，它就不再成为问题。 我无法告诉你有多少次我经历了这样的演习，结果却被削减了项目/功能。
Six weeks.
Industry standard: every request will take six weeks. Some will be longer, some will be shorter, everything averages out in the end.
Also, if you wait long enough, it no longer becomes an issue. I can't tell you how many times I've gone through that firedrill only to have the project/feature cut.
我不会说我夸大了它们，而是试图根据过去的经验设定更现实的期望。
I wouldn't say I inflate them, so much as I try to set more realistic expectations based on past experience.
您可以通过两种方式计算项目持续时间 - 一种是计算出所有涉及的任务，并计算出每项任务需要多长时间，考虑到延误、会议、问题等。这个数字总是看起来短得可怜，这就是为什么人们总是说一些事情比如“加倍”。 在获得了一些交付项目的经验之后，您只需简单地查看一下规范，就可以很快地判断出需要多长时间，而且，它总是会是第一种方法得出的数字的两倍......
You can calculate project durations in two ways - one is to work out all the tasks involved and figure out how long each will take, factor in delays, meetings, problems etc. This figure always looks woefully short, which is why people always say things like 'double it'. After some experience in delivering projects you'll be able to tell very quickly, just by looking briefly at a spec how long it will take, and, invariably, it will be double the figure arrived at by the first method...
为调试和测试等事情添加特定的缓冲时间比仅仅增加总时间更好。 另外，通过提前花时间真正规划出工作的各个部分，您将使估计本身变得更加容易（也可能使编码变得更加容易）。
如果有的话，请注意记录您的所有估计并将其与实际完成时间进行比较，以了解您倾向于低估的程度以及在什么条件下。 这样就可以更准确地“充气”。
It's a better idea to add specific buffer time for things like debugging and testing than to just inflate the total time. Also, by taking the time up front to really plan out the pieces of the work, you'll make the estimation itself much easier (and probably the coding, too).
If anything, make a point of recording all of your estimates and comparing them to actual completion time, to get a sense of how much you tend to underestimate and under what conditions. This way you can more accurately "inflate".
我不会说我夸大了它们，但我确实喜欢使用一个模板来完成项目中可能涉及的所有可能的任务。
您发现并非列表中的所有任务都适用于所有项目，但是拥有一个列表意味着我不会让任何任务因忘记留出一些时间而被遗漏。
当您发现需要新任务时，请将其添加到您的列表中。
这样您就会有一个切合实际的估计。
我倾向于对可实现的目标持乐观态度，因此我倾向于偏低估计。 但我知道我自己的情况，所以我倾向于额外添加 15-20%。
我还跟踪我的实际情况与我的估计。 并确保所涉及的时间不包括其他中断，请参阅 如何回到流程。
HTH
欢呼
I wouldn't say I inflate them but I do like to use a template for all possible tasks that could be involved in the project.
You find that not all tasks in your list are applicable to all projects, but having a list means that I don't let any tasks slip through the cracks with me forgetting to allow some time for them.
As you find new tasks are necessary, add them to your list.
This way you'll have a realistic estimate.
I tend to be optimistic in what's achievable and so I tend to estimate on the low side. But I know that about my self so I tend to add on an extra 15-20%.
I also keep track of my actuals versus my estimates. And make sure the time involved does not include other interruptions, see the accepted answer for my SO question on how to get back in the flow.
HTH
cheers
我不会将项目的额外预计时间称为“夸大”，除非您确实比最初的预计时间早完成了项目。 如果你养成了总是在原定预计时间之前完成项目的习惯，那么项目领导者就会变得明智并期望更早完成。
I wouldn't call additional estimated time on a project "inflated" unless you actually do complete your projects well before your original estimation. If you make a habit of always completing the project well before your original estimated time, then project leaders will get wise and expect it earlier.
您的估计基于什么？
如果它们只是基于对需要多少代码以及编写该代码需要多长时间的模糊直觉，那么您最好将它们填充很多以考虑您没有想到的子任务，通信和同步开销和意想不到的问题。 当然，无论如何，这种估计几乎毫无价值。
OTOH，如果您的估计是基于上次使用给定技术和开发人员数量完成该范围的任务所花费的时间的具体知识，那么通货膨胀应该是不必要的，因为上述通货膨胀因素应该已经包含在过去的经历。 当然，可能会有一些新的因素对当前项目的影响是你无法预见的——这些风险证明一定程度的额外填充是合理的。
What are your estimates based on?
If they're based on nothing but a vague intuition of how much code it would require and how long it would take to write that code, then you better pad them a LOT to account for subtasks you didn't think of, communication and synchronization overhead, and unexpected problems. Of course, that kind o estimate is nearly worthless anyway.
OTOH, if your estimates are based on concrete knowledge of how long it took last time to do a task of that scope with the given technology and number of developers, then inflation should not be necessary, since the inflationary factors above should already be included in the past experiences. Of course there will be probably new factors whose influence on the current project you can't foresee - such risks justify a certain amount of additional padding.
这就是敏捷团队在 故事中估计任务的部分原因点（任意且相对的测量单位），然后随着项目的进展跟踪团队的速度（每天完成的故事点）。 有了这些数据，理论上您就可以准确地计算出您的完成日期。
This is part of the reason why Agile teams estimate tasks in story points (an arbitrary and relative measurement unit), then as the project progresses track the team's velocity (story points completed per day). With this data you can then theoretically compute your completion date with accuracy.
霍夫施塔特定律：任何计算项目所花费的时间都是您想象的两倍——即使您考虑了霍夫施塔特定律。
Hofstadter's Law: Any computing project will take twice as long as you think it will — even when you take into account Hofstadter's Law.
如果你根据过去的经验夸大你的估计，试图补偿你固有的乐观情绪，那么你就没有夸大。 您正在尝试提供准确的估计。 然而，如果你膨胀了，这样你就总是有闲暇时间，那就不太好了。
If you inflate your estimate based on past experiences to try and compensate for your inherent optimism, then you aren't inflating. You are trying to provide an accurate estimate. If however you inflate so that you will always have fluff time, that's not so good.
哦，是的，我学会了总是将我的初始估计乘以二。 这就是为什么 FogBUGZ 的基于证据的调度工具非常有用。
Oh yes, I've learnt to always multiply my initial estimation by two. That's why FogBUGZ's Evidence-Based Scheduling tool is so really useful.
任何要求程序员估计粗粒度功能的时间的组织从根本上来说都是失败的。
突破步骤：
这不是火箭科学。 关键是第 3 步。如果营销想要一些看似复杂的东西，您的 PM（根据开发人员的意见）会在不到一周的时间内弄清楚第一步是什么。 如果 PM 不具备技术性，那么一切都会失败。
这种方法的缺点：
没有什么比在 1 个月标记时意识到我给出的 2 个月估计完全不够，但无法更改更令人沮丧的了，因为它已经在官方营销文献中了。 要么我冒着差评和/或错过奖金的风险改变我的估算而惹恼了上级，要么我做了很多无薪加班。 我意识到，大量加班并不是一个糟糕的开发人员的标志，也不是一个“热情”开发人员的标志——它是一种有毒文化的产物。
是的，很多东西都包含在（不同的）XP、“敏捷”、SCRUM 等中，但实际上并没有那么复杂。 你不需要一本书或一个顾问来做到这一点。 你只需要公司的意愿。
Any organization that asks its programmers to estimate time for coarse-grained features is fundamentally broken.
Steps to unbreak:
It's not rocket science. The key is step 3. If marketing wants something that seems complicated, your PMs (with developer input) figure out what the first step is that will take less than a week. If the PMs are not technical, all is lost.
Drawbacks to this approach:
Nothing is as disheartening as realizing at the 1-month mark that the 2-month estimate I gave is hopelessly inadequate, but can't be changed, because it's already in the official marketing literature. Either I piss off the higher-ups by changing my estimate, risking a bad review and/or missing my bonus, or I do a lot of unpaid overtime. I've realized that a lot of overtime is not the mark of a bad developer, or the mark of a "passionate" one - it's the product of a toxic culture.
And yeah, a lot of this stuff is covered under (variously) XP, "agile," SCRUM, etc., but it's not really that complicated. You don't need a book or a consultant to do it. You just need the corporate will.
斯科蒂规则：
两倍四倍（感谢 Adam！）示例：
啦！ 当你在 8 天内完成任务时，你就是一个奇迹创造者。
The Scotty Rule:
double thatquadruple that (thanks Adam!)Example:
Ta-daa! You're a miracle worker when you get it done in less than 8 days.
通常是的，但我有两个策略：
Typically yes, but I have two strategies:
我将在 3-6 周内回答这个问题。
I'll be able to answer this in 3-6 weeks.
这不叫“膨胀”，而叫“让它们变得更加真实”。
It's not called "inflating" — it's called "making them remotely realistic."
采取您认为合适的任何估计。 然后加倍。
Take whatever estimate you think appropriate. Then double it.
不要忘记您（工程师）实际上是在理想时间（scrum 术语）内进行估算的。
而管理人员则按实际时间工作。
不同之处在于，理想的时间是不间断的时间（每次中断后有 30 分钟的热身时间）。 理想的时间不包括会议时间、午餐时间或正常闲聊等。
考虑到所有这些，理想时间将趋于实际时间。
例子：
预计时间 40 小时（理想）
管理层将假设这是 1 周的实时时间。
如果将这 40 小时转换为实时时间：
每天 8 小时现在是 5 小时工作时间（8 - 会议 - 午餐 - 热身）。
乘以 80% 效率 = 每天 4 小时理想时间。
你 40 小时的理想实际需要 80 小时才能完成。
Don't forget you (an engineer) actually estimate in ideal hours (scrum term).
While management work in real hours.
The difference being that ideal hours are time without interuption (with a 30 minute warm up after each interuption). Ideal hours don't include time in meetings, time for lunch or normal chit chat etc.
Take all these into consideration and ideal hours will tend towards real hours.
Example:
Estimated time 40 hours (ideal)
Management will assume that is 1 week real time.
If you convert that 40 hours to real time:
8 hour day is now 5 hours work time (8 - meeting - lunch - warm up).
Times 80% effeciency = 4 hours ideal time per day.
This your 40 hour ideal will take 80 hours real time to finish.
柯克：斯科特先生，您是否总是将维修估算乘以四倍？
斯科蒂：当然，先生。 我还能如何保持奇迹创造者的声誉呢？
Kirk : Mr. Scott, have you always multiplied your repair estimates by a factor of four?
Scotty : Certainly, sir. How else can I keep my reputation as a miracle worker?
一个好的经验法则是估计需要多长时间，然后再次添加 1/2 的时间来解决以下问题：
A good rule of thumb is estimate how long it will take and add 1/2 again as much time to cover the following problems: