* Tom Neyland suggests it should be (min_weighting + max_weighting). Actually I'm not sure whether that is correct, but it's probably more correct than my original divisor of 2.0.
The weighting you give to the min and max values will depend on the complexity of the task, the risks associated with the task, the likelihood of the risks occuring, the skill of the developer, etc. and will vary from organisation to organisation and from project to project. If you keep a record of your previous estimates and the actual time each took you'll be able to refine these estimates over time.
You should also use these values, plus a confidence value, when talking to senior management and customers. While giving the max and delivering early is not the same as giving the min and delivering late, it still shows that you don't have control over your development.
Giving the confidence value and an idea of the risks will also help manage expectations so if there are problems they're not unexpected.
* These min and max estimates will be got by various means - asking the developers, past experience etc. If polling developers then the actual min and max values should be treated as outliers and either discarded or modified in some way. What I mean here are the values you get from phrases like "it'll take 2 weeks if all goes well or a month if we hit some snags". So the values you plug into the formula are not the raw numbers.
Erring on the side of overestimation is better. It has much nicer cost behavior in the long term.
To overcome the stress due to underestimation, people may take shortcuts that are not beneficial in the long term. For example, taking extra technical debt thast has to be paid back eventually, and it comes back with an interest. The costs grow exponentially.
The extra cost from inefficiency due to student's syndrome behaves linearly.
Estimates and targets are different. You (or your managers and customers) set the targets you need to achieve. Estimates tell you how likely you are to meet those targets. Deadline is one sort of target. The deadline you choose depends on what kind of confidence level (risk of not meeting the deadline) you are willing to accept. P50 (0.5 probability of meeting the deadline) is commonplace. Sometimes you may want to schedule with P80 or some other confidence level. Note that the probability curve is a long-tailed one and the more confidence you want, the longer you will need to allocate time for the project.
Overall, I wouldn't spend too much time tracking individual tasks. With P50 targets half of them will be late in any case. What matters most is how the aggregate behaves. When composing individual tasks estimates into an aggregate, neither min or max is sensible. It's extremely unlikely that either all tasks complete with minimum time (most likely something like P10 time) or maximum time (e.g. P90 time): for n P10/P90 tasks the probability is 0.1^n.
PERT has some techniques for coming up with reasonable task duration probability distributions and aggregating them to larger wholes. I won't go into the math here. Here's some pointer for further reading:
For individual tasks or tasks making up the critical path it’s simply not prudent to go for the best case estimates. It’s like saying that the project is absolutely free of any risk and uncertainty. If the actual job turns out to be anything but the best case scenario you’ll end up blowing the schedule. It’s better to end up with some extra time on your hands and fill the time by implementing some nice-to-haves as opposed to having to work nights and weekends.
On the other hand if managers mostly went for the worst case estimates and in software world they can easily be an order of magnitude greater than the best case figures most projects would never make it past the feasibility and planning stage. Not all of the risks going to materialise.
Going for the best case estimate won't help fighting student syndrome. Include interim milestones and deliverables instead, beside being helpful at combating the student syndrome they're pre-requisite for having a trustworthy data on the project progress and uncovering early any potential issues.
If the difference between min and max are big rather than using some black magic formula I think it the best thing to do would be to go back to the developers and ask them to do a finer breakdown and prototyping, which will lead to better estimates where the gap between min and max is not that big.
Note to the question: In my opinion, the estimates should be done by the developers/architects since they have the best technical knowledge to be able to break down into tasks and estimate those tasks.
If you are estimating for a specific developer, and you know your estimates are generally accurate for that developer, then the min value is the logical deadline (initially). In the course of the project you will adjust deadlines according to circumstance.
If you have little experience with a specific developer, one of my fondly regarded previous managers would ask the developer himself to do the estimate and set the initial deadline a third of the distance between that developer's min and max, challenging the developer to beat it.
Something which has been missing in many of these answers (perhaps because it's slightly off-topic) is frequent updates. With younger/newer developers this is even more important - read the code they commit, and/or check in daily to ask them for specific, detailed reports.
This also allows you to set tight deadlines for developers without giving them too much stress, because they will know you're around to help adjust deadlines when needed.
Frequent updates give you the most important tool in setting customer/management expectations - early warning of issues which might delay things, and I prefer having that over any formula.
Is the developer going back into a cave to develop this or is there a good chance of changing requirements over the course of the project? I would think most projects will have a good chance that something won't go smoothly and thus it may be better to try to get the prototype up sooner rather than later.
As for the initial question, I think I'd break this out into a few different outcomes and consider each:
Gross underestimation -> This leads to the problem that there is still a lot of work to do and the manager appears unable to make reasonable estimations.
Minor underestimation -> In this case, either there is an extension, scope gets cut or some bugs are in the release, but this is better than the previous case.
Made the deadline, on time and on budget with quality -> While this may seem optimal as everything worked out, I don't think this is the best result possible.
Minor overestimation -> In this case, there is some breathing room that means either things finish early or some extra work is added. A point here is that this may seem to deliver a slightly better result than the previous case like how some companies will try to beat the earnings estimate by a small amount to do better than expected.
Gross overestimation -> I think this would be the worst case outcome though it is similar to the first in terms of someone being way out of their league in being able to provide a reasonable estimation.
That's just my opinion on each and others may have a different take on it than me.
If you're trying to hold developers to their minimum estimate, that's foolish. No one, in any industry, consistently hits their minimum time estimate for getting something done. Eventually, they'll just learn to pad their minimum estimates significantly, and then they'll never hit the old minimums, because all estimates will be above that.
In Agile/Scrum, you don't set firm deadlines, but set "how many hours left on this task". Every day, you update the amount of time left. You do not track hours spent, but do track estimated hours remaining, and you try and stay honest about it.
If you have lazy developers, this is bad, because they can easily game that system. If you have developers that are worth their salt, this is great. They get better at estimation pretty quickly, and you - as a project manager - learn how reliable their estimates are, and you'll have a much better feel for what estimates to pass up the chain based on the individual developer estimates.
Go slightly towards Agile, fire the bad developers as you discover which are which, reward the good developers for actually giving a damn, and have a more productive, happier team while being able to report more accurate expectations to your superiors.
顺便说一句，你告诉开发商什么是最后期限完全是另一个问题。就我个人而言，我会给他大约 ((2 x max + 1 x min) / 3) 的某个地方，并将其余的作为应急措施。
If in doubt under promise and over deliver: you want to be the person who is delivering more than they were expecting, not less. Based on this always go with the higher of any estimate.
Slightly more complex:
For a given potential delivery, if you plot the delivery times against the chances of them being happening, you're going to get a curve which is a variation of a normal distribution, and you can assume that a developers minimum estimates are going to be somewhere towards the left of the curve and their maximum towards the right.
The area under the curve to the left of the single number you select as your estimate represents the probability of you successfully delivering on or before that estimate. So if you give a number at the very left hand side your chance of hitting is effectively zero, if you give a number at the very right hand side your chance is effectively 100%.
What is less commonly realised is if you give the mean value (assuming your min and max averaged out give something approximating the actual mean) you'll only hit that deadline 50% of the time. Effectively if you use the mean you're going to miss the deadline half the time. I don't know about you but I don't like being seen as the guy whose misses half his deadlines.
So you want a number which is going to give you something you hit, say, 90% of the time. Conveniently 95% represents the mean + two standard deviations but if you can't be arsed to calculate that (and most of us probably don't have the data) my experience says that:
(3 x max + 1 x min) / 4
gives a reasonable result.
Incidentally, what you tell the developer is the deadline is another question entirely. Personally I'd give him somewhere around ((2 x max + 1 x min) / 3) and have the rest as contingency.
What are you using the estimates for? Specifically, why will the developer feel stressed if you normally underestimate?
If you're trying to schedule how long something is likely to take, you go for an intermediate value. Probably on the long side, since people normally underestimate. In any case, you shouldn't be using these estimates as firm objectives for developers, and so they shouldn't be overly stressful.
If you're using these estimates to set up commitments, you need to err on the side of overestimating. Giving developers insufficient time leads to burnout, unmaintainable buggy code that doesn't do quite what the user wants, and low morale and high turnover. Set the commitments to be reachable, and encourage the developers to finish early.
但无论如何不应该使用最大时间：它是最不准确的衡量标准，通常会导致甚至花费更多时间。这是一个简单的原因：当开发人员只是赠送这个 MAX 时，他几乎不进行测量。他只是泄露了他当时信息很少的直觉。但如果他花至少半个小时，他就会了解任务的细节，他甚至可以将其分解为子任务并提高准确性。因此，你可以给开发人员一些偏见，比如“嘿，伙计们，想想你什么时候会在这里提供稳定的代码”，但让他自己测量一下。这对工作有好处，对程序员本人也有好处。
This depends on project.
Some projects may require fast development and there's no alternatives if deadline is already set and there's no good chance to prolong development. Typical issue: marketing campaign resulting in new service. Such deadline can be enough for normal development, but in some organizations it is so close, that developers work in stress and make many errors that are fixed during production stage. That's a kind of project when developers have to work with topmost effectiveness and they'd better get good reward on success.
Some projects are accurately planned and here you can use all analytics you have: history data, some developer's time metrics on subtasks, calculating risks, etc.
But anyway MAX time shouldn't be used: its the most inaccurate measure that usually leads to even more time taken. And here's a simple reason: when developer just gives away this MAX, he almost doesn't measure. He just gives away his intuition that has very little info at the time. But if he'll spend at least half an hour he'll understand specifics of his tasks, he even may split it into subtask and increase his accuracy. So you can give developer some bias like "hey, guys, just think in what time you would provide stable code here" but send him measure himself. It is good for a job, it is good for a programmer himself.
The first mistake most estimators use when setting the deadline is assuming that the dev will be full-time every day on that task which is a disastrous mistake. This can result in not meeting the deadline even when you use the over estimate to figure out the deadline. Being under the hours but past the deadline you told the client is a big problem. People take leave, get sick, have jury duty, have to go to required meetings on some new HR policy, get called over to help on another project when someone is stuck, have to load software on a new computer when their old one breaks, have to research a production problem on code they recently deployed, etc. If you are estimating more than 6 hours a day on the project per person, you are already in trouble on the deadline before the project starts. When I did manpower studies, we used a figure that equated to just slightly more than 6 hours a day of direct work when calculating out how many people were needed for any job. And we did a lot of statistical analysis as the basis for the figure we used.
I think you have to decide which of these to use on a case by case basis. We have some projects that we know the max estimate is still probably a little low (usually when someone in management couldn't face the client with the real estimate), we have others where we are doing something new where we know the estimates are more likely to be off, in these kinds of cases go with the max. But for work you've done before that is well-defined and you know the dev assigned won't be learning new skills, then go closer to the min (but never actually use the min, there are alawys unexpected bumps in the road). ALso the shorter the project, the more likely you will be able to meet the min, it is far easier to get a good estimate for a week-long project than a year-long one.
More importantly is changing the estimate and deadline every time the circumstances change. If the client adds work, the extend the deadline and estimate, don't just do it. If your best dev quits and you have to put someone new on the project, extend the deadline becasue that person has to have time to get up to speed (you may have to eat the hours though, the client may not agree to pay for that time. Critical to this is telling the client right away. They tend to be better about moving a deadline (although not happy) than they are about missing one or making the dealine but the product doesn't work as they expect it to. Too many project managers just like to wish a problem is going away and the won't have to face that conversation with the client. But usually when they do finally have to tell him it is a much worse conversation than the difficult one they tried to avoid.
发布评论
评论（12）
您应该使用最佳猜测，它是最小和最大估计的函数* - 不仅仅是简单的平均值 -
best_guess = (min * min_weighting + max * max_weighting) / divisor*
* Tom Neyland 建议它应该是
(min_weighting + max_weighting）。实际上我不确定这是否正确，但它可能比我原来的除数2.0更正确。您给予最小值和最大值的权重将取决于任务的复杂性、与任务相关的风险、风险发生的可能性、开发人员的技能等，并且会因组织和组织的不同而不同。项目到项目。如果您记录以前的估计以及每次花费的实际时间，您将能够随着时间的推移完善这些估计。
在与高级管理层和客户交谈时，您还应该使用这些值以及信心值。虽然给予最大限度并提早交付与给予最低限度并延迟交付并不相同，但这仍然表明您无法控制自己的发展。
提供信心值和风险概念也将有助于管理预期，因此如果出现问题就不会出现意外。
* 这些最小和最大估计值将通过各种方式获得 - 询问开发人员、过去的经验等。如果轮询开发人员，则实际的最小和最大值应被视为异常值，并以某种方式丢弃或修改。我的意思是你从“如果一切顺利的话需要两周的时间，如果遇到一些障碍需要一个月的时间”这样的短语中得到的值。因此，您插入公式的值不是原始数字。
You should use the best guess which is a function of the min and max estimates* - not just the simple average -
best_guess = (min * min_weighting + max * max_weighting) / divisor*
* Tom Neyland suggests it should be
(min_weighting + max_weighting). Actually I'm not sure whether that is correct, but it's probably more correct than my original divisor of2.0.The weighting you give to the min and max values will depend on the complexity of the task, the risks associated with the task, the likelihood of the risks occuring, the skill of the developer, etc. and will vary from organisation to organisation and from project to project. If you keep a record of your previous estimates and the actual time each took you'll be able to refine these estimates over time.
You should also use these values, plus a confidence value, when talking to senior management and customers. While giving the max and delivering early is not the same as giving the min and delivering late, it still shows that you don't have control over your development.
Giving the confidence value and an idea of the risks will also help manage expectations so if there are problems they're not unexpected.
* These min and max estimates will be got by various means - asking the developers, past experience etc. If polling developers then the actual min and max values should be treated as outliers and either discarded or modified in some way. What I mean here are the values you get from phrases like "it'll take 2 weeks if all goes well or a month if we hit some snags". So the values you plug into the formula are not the raw numbers.
既不要使用最小值也不要使用最大值，而应使用介于两者之间的值。
宁可高估错误，也宁可犯错误。从长远来看，它具有更好的成本行为。
为了克服低估带来的压力，人们可能会采取从长远来看无益的捷径。例如，承担额外的技术债务最终必须偿还，并且会带来利息。成本成倍增长。
由于学生综合症导致的效率低下而产生的额外成本呈线性变化。
估计和目标不同。您（或您的经理和客户）设定需要实现的目标。估算会告诉您实现这些目标的可能性有多大。截止日期是一种目标。您选择的截止日期取决于您愿意接受的置信水平（未满足截止日期的风险）。 P50（按期完成的概率为 0.5）很常见。有时您可能希望使用 P80 或其他置信水平进行安排。请注意，概率曲线是一条长尾曲线，您的信心越大，您需要为项目分配的时间就越长。
总的来说，我不会花太多时间跟踪单个任务。有了 P50 的目标，无论如何，其中一半都会迟到。最重要的是聚合的行为方式。当将单个任务估计组合成一个聚合时，最小值或最大值都是不明智的。所有任务都以最短时间（很可能类似于 P10 时间）或最长时间（例如 P90 时间）完成的可能性极小：对于 n 个 P10/P90 任务，概率为 0.1^n。
PERT 有一些技术可以得出合理的任务持续时间概率分布并将它们聚合成更大的整体。我不会在这里讨论数学。以下是进一步阅读的一些提示：
Steve McConnell：软件估算 - 揭秘黑魔法。它非常可读且实用，但至少我的第一版在数学和其他方面有一些怪癖。
Richard D. Stutzke：评估软件密集型系统 - 项目、产品和流程< /a>.它更具学术性，更难读，但例如更好地解释了数学。
Use neither min nor max but something in between.
Erring on the side of overestimation is better. It has much nicer cost behavior in the long term.
To overcome the stress due to underestimation, people may take shortcuts that are not beneficial in the long term. For example, taking extra technical debt thast has to be paid back eventually, and it comes back with an interest. The costs grow exponentially.
The extra cost from inefficiency due to student's syndrome behaves linearly.
Estimates and targets are different. You (or your managers and customers) set the targets you need to achieve. Estimates tell you how likely you are to meet those targets. Deadline is one sort of target. The deadline you choose depends on what kind of confidence level (risk of not meeting the deadline) you are willing to accept. P50 (0.5 probability of meeting the deadline) is commonplace. Sometimes you may want to schedule with P80 or some other confidence level. Note that the probability curve is a long-tailed one and the more confidence you want, the longer you will need to allocate time for the project.
Overall, I wouldn't spend too much time tracking individual tasks. With P50 targets half of them will be late in any case. What matters most is how the aggregate behaves. When composing individual tasks estimates into an aggregate, neither min or max is sensible. It's extremely unlikely that either all tasks complete with minimum time (most likely something like P10 time) or maximum time (e.g. P90 time): for n P10/P90 tasks the probability is 0.1^n.
PERT has some techniques for coming up with reasonable task duration probability distributions and aggregating them to larger wholes. I won't go into the math here. Here's some pointer for further reading:
Steve McConnell: Software Estimation - Demystifying the Black Art. It's quite readable and pragmatic but at least the 1st edition I have has some quirks in its math and otherwise.
Richard D. Stutzke: Estimating Software-Intensive Systems - Projects, Products and Processes. It's a little more academic, harder read but for example explains the math better.
请询问最佳、可能和最坏情况估计。然后使用 程序评估和审查技术。不过，您可能想先看一下PERT 批评。
对于单个任务或构成关键路径的任务来说，这样做是不明智的以获得最佳情况估计。这就像说该项目绝对没有任何风险和不确定性。如果实际的工作结果不是最好的情况，你最终会打乱进度。最好是手头上有一些额外的时间，并通过实施一些可有可无的事情来打发时间，而不是晚上和周末工作。
另一方面，如果管理者大多采用最坏情况估计，并且在软件世界中，他们很容易比最好情况数字大一个数量级，那么大多数项目将永远无法通过可行性和规划阶段。并非所有风险都会发生。
寻求最佳案例估计无助于对抗学生综合症。相反，包括临时里程碑和可交付成果，除了有助于对抗学生综合症之外，它们也是获得有关项目进展的可靠数据并尽早发现任何潜在问题的先决条件。
Ask for best, likely and worst case scenario estimates instead. Then use Program Evaluation and Review Technique. However you may want to take a look at some PERT critique first.
For individual tasks or tasks making up the critical path it’s simply not prudent to go for the best case estimates. It’s like saying that the project is absolutely free of any risk and uncertainty. If the actual job turns out to be anything but the best case scenario you’ll end up blowing the schedule. It’s better to end up with some extra time on your hands and fill the time by implementing some nice-to-haves as opposed to having to work nights and weekends.
On the other hand if managers mostly went for the worst case estimates and in software world they can easily be an order of magnitude greater than the best case figures most projects would never make it past the feasibility and planning stage. Not all of the risks going to materialise.
Going for the best case estimate won't help fighting student syndrome. Include interim milestones and deliverables instead, beside being helpful at combating the student syndrome they're pre-requisite for having a trustworthy data on the project progress and uncovering early any potential issues.
如果最小值和最大值之间的差异很大，而不是使用一些黑魔法公式，我认为最好的办法是返回开发人员并要求他们进行更精细的分解和原型设计，这将导致更好的估计min 和 max 之间的差距并没有那么大。
注意问题：在我看来，估计应该由开发人员/架构师完成，因为他们拥有最好的技术知识，能够分解任务并估计这些任务。
If the difference between min and max are big rather than using some black magic formula I think it the best thing to do would be to go back to the developers and ask them to do a finer breakdown and prototyping, which will lead to better estimates where the gap between min and max is not that big.
Note to the question: In my opinion, the estimates should be done by the developers/architects since they have the best technical knowledge to be able to break down into tasks and estimate those tasks.
如果您正在为特定开发人员进行估算，并且您知道您的估算对于该开发人员来说通常是准确的，那么最小值就是逻辑截止日期（最初）。在项目过程中，您将根据情况调整截止日期。
如果你对某个特定的开发人员缺乏经验，我所深爱的一位前任经理会要求开发人员亲自进行估算，并将最初的截止日期设置为该开发人员的最小值和最大值之间距离的三分之一，挑战开发人员来超越它。
If you are estimating for a specific developer, and you know your estimates are generally accurate for that developer, then the min value is the logical deadline (initially). In the course of the project you will adjust deadlines according to circumstance.
If you have little experience with a specific developer, one of my fondly regarded previous managers would ask the developer himself to do the estimate and set the initial deadline a third of the distance between that developer's min and max, challenging the developer to beat it.
许多这些答案中缺少的东西（可能是因为它有点偏离主题）是频繁的更新。对于年轻/新的开发人员来说，这一点更为重要 - 阅读他们提交的代码，和/或每天检查以要求他们提供具体、详细的报告。
这还允许您为开发人员设定紧迫的截止日期，而不会给他们太大的压力，因为他们会知道您会在需要时帮助调整截止日期。
频繁的更新为您提供了设定客户/管理层期望的最重要的工具 - 对可能延迟事情的问题进行早期预警，与任何公式相比，我更喜欢这样做。
Something which has been missing in many of these answers (perhaps because it's slightly off-topic) is frequent updates. With younger/newer developers this is even more important - read the code they commit, and/or check in daily to ask them for specific, detailed reports.
This also allows you to set tight deadlines for developers without giving them too much stress, because they will know you're around to help adjust deadlines when needed.
Frequent updates give you the most important tool in setting customer/management expectations - early warning of issues which might delay things, and I prefer having that over any formula.
开发人员是否会回到洞穴中进行开发，或者在项目过程中是否有很好的机会改变需求？我认为大多数项目很有可能进展不顺利，因此最好尽早尝试制作原型而不是稍后制作。
至于最初的问题，我想我会将其分解为几个不同的结果并考虑每个结果：
严重低估 ->这就导致了一个问题：还有很多工作要做，而经理似乎无法做出合理的估计。
轻微低估 ->在这种情况下，要么存在扩展，要么范围被削减，要么发布中存在一些错误，但这比之前的情况要好。
按时、按预算、按质完成最后期限 ->尽管一切顺利，这似乎是最佳结果，但我认为这并不是最好的结果。
轻微高估 ->在这种情况下，存在一些喘息空间，这意味着要么事情提前完成，要么添加一些额外的工作。这里的一点是，这似乎比之前的情况稍微好一些，比如一些公司会试图稍微超出盈利预期，以取得比预期更好的业绩。
严重高估->我认为这将是最坏的情况结果，尽管它与第一个结果类似，因为有人无法提供合理的估计。
这只是我对每个人的看法，其他人可能有与我不同的看法。
Is the developer going back into a cave to develop this or is there a good chance of changing requirements over the course of the project? I would think most projects will have a good chance that something won't go smoothly and thus it may be better to try to get the prototype up sooner rather than later.
As for the initial question, I think I'd break this out into a few different outcomes and consider each:
Gross underestimation -> This leads to the problem that there is still a lot of work to do and the manager appears unable to make reasonable estimations.
Minor underestimation -> In this case, either there is an extension, scope gets cut or some bugs are in the release, but this is better than the previous case.
Made the deadline, on time and on budget with quality -> While this may seem optimal as everything worked out, I don't think this is the best result possible.
Minor overestimation -> In this case, there is some breathing room that means either things finish early or some extra work is added. A point here is that this may seem to deliver a slightly better result than the previous case like how some companies will try to beat the earnings estimate by a small amount to do better than expected.
Gross overestimation -> I think this would be the worst case outcome though it is similar to the first in terms of someone being way out of their league in being able to provide a reasonable estimation.
That's just my opinion on each and others may have a different take on it than me.
如果你试图让开发人员保持最低的估计，那是愚蠢的。在任何行业中，没有人能够始终如一地达到完成某件事的最短时间估计。最终，他们将学会显着地填充他们的最低估计值，然后他们将永远达到旧的最低值，因为所有估计值都将高于该值。
在敏捷/Scrum 中，您不会设定严格的截止日期，而是设定“此任务还剩多少小时”。每天，您都会更新剩余时间。您不会跟踪花费的时间，但会跟踪估计的剩余时间，并且您会尽力诚实地对待它。
如果您有懒惰的开发人员，这很糟糕，因为他们可以轻松地欺骗该系统。如果您有值得信赖的开发人员，那就太好了。他们很快就可以更好地进行估算，而作为项目经理的您将了解到他们的估算有多可靠，并且您将根据各个开发人员的估算对要在整个链条中传递的估算有更好的感觉。
稍微走向敏捷，在发现哪些是坏的开发人员时解雇他们，奖励那些真正在意的优秀开发人员，并拥有一个更有生产力、更快乐的团队，同时能够向您报告更准确的期望上级。
If you're trying to hold developers to their minimum estimate, that's foolish. No one, in any industry, consistently hits their minimum time estimate for getting something done. Eventually, they'll just learn to pad their minimum estimates significantly, and then they'll never hit the old minimums, because all estimates will be above that.
In Agile/Scrum, you don't set firm deadlines, but set "how many hours left on this task". Every day, you update the amount of time left. You do not track hours spent, but do track estimated hours remaining, and you try and stay honest about it.
If you have lazy developers, this is bad, because they can easily game that system. If you have developers that are worth their salt, this is great. They get better at estimation pretty quickly, and you - as a project manager - learn how reliable their estimates are, and you'll have a much better feel for what estimates to pass up the chain based on the individual developer estimates.
Go slightly towards Agile, fire the bad developers as you discover which are which, reward the good developers for actually giving a damn, and have a more productive, happier team while being able to report more accurate expectations to your superiors.
如果对承诺和超额交付存在疑问：你希望成为交付比他们预期更多而不是更少的人。在此基础上，始终选择任何估计中的较高者。
稍微复杂
一点：对于给定的潜在交付，如果您将交付时间与发生的可能性进行比较，您将得到一条曲线，它是 正态分布，您可以假设开发人员的最小估计值将位于曲线左侧的某个位置，而最大值则位于曲线右侧的某个位置。
您选择作为估计值的单个数字左侧的曲线下面积代表您在该估计值或之前成功交付的概率。因此，如果您在最左边给出一个数字，那么您击中的机会实际上为零，如果您在最右边给出一个数字，那么您击中的机会实际上是 100%。
不太常见的是，如果您给出平均值（假设您的最小值和最大值的平均值近似于实际平均值），那么您只有 50% 的时间能够达到截止日期。实际上，如果您使用该平均值，您将有一半的时间会错过截止日期。我不了解你的情况，但我不喜欢被视为错过了一半最后期限的人。
因此，您需要一个能够为您提供 90% 的命中率的数字。方便地 95% 代表平均值 + 两个标准差，但如果你无法计算出来（而且我们大多数人可能没有数据），我的经验表明：
（3 x 最大值 + 1 x 最小值）/ 4
给出合理的结果。
顺便说一句，你告诉开发商什么是最后期限完全是另一个问题。就我个人而言，我会给他大约 ((2 x max + 1 x min) / 3) 的某个地方，并将其余的作为应急措施。
If in doubt under promise and over deliver: you want to be the person who is delivering more than they were expecting, not less. Based on this always go with the higher of any estimate.
Slightly more complex:
For a given potential delivery, if you plot the delivery times against the chances of them being happening, you're going to get a curve which is a variation of a normal distribution, and you can assume that a developers minimum estimates are going to be somewhere towards the left of the curve and their maximum towards the right.
The area under the curve to the left of the single number you select as your estimate represents the probability of you successfully delivering on or before that estimate. So if you give a number at the very left hand side your chance of hitting is effectively zero, if you give a number at the very right hand side your chance is effectively 100%.
What is less commonly realised is if you give the mean value (assuming your min and max averaged out give something approximating the actual mean) you'll only hit that deadline 50% of the time. Effectively if you use the mean you're going to miss the deadline half the time. I don't know about you but I don't like being seen as the guy whose misses half his deadlines.
So you want a number which is going to give you something you hit, say, 90% of the time. Conveniently 95% represents the mean + two standard deviations but if you can't be arsed to calculate that (and most of us probably don't have the data) my experience says that:
(3 x max + 1 x min) / 4
gives a reasonable result.
Incidentally, what you tell the developer is the deadline is another question entirely. Personally I'd give him somewhere around ((2 x max + 1 x min) / 3) and have the rest as contingency.
您使用估算值做什么？具体来说，如果你通常低估，为什么开发人员会感到压力？
如果您试图安排某件事可能需要多长时间，您可以选择中间值。可能是做多，因为人们通常会低估。无论如何，您不应该将这些估计用作开发人员的坚定目标，因此不应给他们带来太大的压力。
如果您使用这些估计来做出承诺，那么您可能会犯高估的错误。给开发人员足够的时间会导致倦怠、无法维护的错误代码、无法满足用户需求、士气低落和人员流动率高。设定可实现的承诺，并鼓励开发人员尽早完成。
What are you using the estimates for? Specifically, why will the developer feel stressed if you normally underestimate?
If you're trying to schedule how long something is likely to take, you go for an intermediate value. Probably on the long side, since people normally underestimate. In any case, you shouldn't be using these estimates as firm objectives for developers, and so they shouldn't be overly stressful.
If you're using these estimates to set up commitments, you need to err on the side of overestimating. Giving developers insufficient time leads to burnout, unmaintainable buggy code that doesn't do quite what the user wants, and low morale and high turnover. Set the commitments to be reachable, and encourage the developers to finish early.
这取决于项目。
有些项目可能需要快速开发，如果截止日期已经确定并且没有很好的机会来延长开发，则没有其他选择。典型问题：营销活动带来新服务。这样的截止日期对于正常开发来说已经足够了，但在某些组织中，它是如此接近，以至于开发人员在压力下工作并犯了许多在生产阶段修复的错误。在这种项目中，开发人员必须以最高效率工作，并且最好在成功后获得丰厚的回报。
有些项目是经过精确规划的，在这里您可以使用您拥有的所有分析：历史数据、某些开发人员在子任务上的时间指标、计算风险等。
但无论如何不应该使用最大时间：它是最不准确的衡量标准，通常会导致甚至花费更多时间。这是一个简单的原因：当开发人员只是赠送这个 MAX 时，他几乎不进行测量。他只是泄露了他当时信息很少的直觉。但如果他花至少半个小时，他就会了解任务的细节，他甚至可以将其分解为子任务并提高准确性。因此，你可以给开发人员一些偏见，比如“嘿，伙计们，想想你什么时候会在这里提供稳定的代码”，但让他自己测量一下。这对工作有好处，对程序员本人也有好处。
This depends on project.
Some projects may require fast development and there's no alternatives if deadline is already set and there's no good chance to prolong development. Typical issue: marketing campaign resulting in new service. Such deadline can be enough for normal development, but in some organizations it is so close, that developers work in stress and make many errors that are fixed during production stage. That's a kind of project when developers have to work with topmost effectiveness and they'd better get good reward on success.
Some projects are accurately planned and here you can use all analytics you have: history data, some developer's time metrics on subtasks, calculating risks, etc.
But anyway MAX time shouldn't be used: its the most inaccurate measure that usually leads to even more time taken. And here's a simple reason: when developer just gives away this MAX, he almost doesn't measure. He just gives away his intuition that has very little info at the time. But if he'll spend at least half an hour he'll understand specifics of his tasks, he even may split it into subtask and increase his accuracy. So you can give developer some bias like "hey, guys, just think in what time you would provide stable code here" but send him measure himself. It is good for a job, it is good for a programmer himself.
大多数估算者在设定截止日期时犯的第一个错误是假设开发人员每天都会全职完成该任务，这是一个灾难性的错误。即使您使用高估来计算截止日期，这也可能导致无法满足截止日期。低于工作时间但超过了告诉客户的最后期限是一个大问题。人们请假、生病、担任陪审员、必须参加一些新的人力资源政策所需的会议、当有人陷入困境时被叫去帮助另一个项目、当旧计算机坏了时必须在新计算机上加载软件、必须研究他们最近部署的代码的生产问题，等等。如果您估计每个人每天在该项目上花费的时间超过 6 小时，那么您在项目开始之前的截止日期上就已经遇到了麻烦。当我进行人力研究时，我们在计算任何工作需要多少人时使用了一个相当于每天直接工作略多于 6 小时的数字。我们做了很多统计分析作为我们使用的数字的基础。
我认为您必须根据具体情况决定使用其中哪一个。我们有一些项目，我们知道最大估算仍然可能有点低（通常当管理人员无法向客户提供真实估算时），我们还有其他项目，我们正在做一些新的事情，我们知道估算更高可能会关闭，在这种情况下请使用最大值。但是对于你之前完成的工作来说，这是明确定义的，并且你知道分配的开发人员不会学习新技能，然后接近最小值（但从未真正使用最小值，路上总会有意想不到的坎坷） 。此外，项目越短，您就越有可能满足最低要求，对为期一周的项目比为期一年的项目更容易获得良好的估算。
更重要的是，每次情况发生变化时，都要改变估计和截止日期。如果客户增加了工作，延长了截止日期并进行了估算，不要只是这样做。如果你最好的开发人员辞职了，而你必须让新人参与该项目，请延长截止日期，因为该人必须有时间跟上进度（不过你可能需要花几个小时，客户可能不同意为此付费）对此的关键是立即告诉客户（尽管不高兴），他们往往会更好地推迟最后期限，而不是错过最后期限或产品无法按他们的预期工作。许多项目经理只是希望问题能够消失，并且不必面对与客户的对话，但通常当他们最终不得不告诉他时，这比他们试图避免的困难对话要糟糕得多。 。
The first mistake most estimators use when setting the deadline is assuming that the dev will be full-time every day on that task which is a disastrous mistake. This can result in not meeting the deadline even when you use the over estimate to figure out the deadline. Being under the hours but past the deadline you told the client is a big problem. People take leave, get sick, have jury duty, have to go to required meetings on some new HR policy, get called over to help on another project when someone is stuck, have to load software on a new computer when their old one breaks, have to research a production problem on code they recently deployed, etc. If you are estimating more than 6 hours a day on the project per person, you are already in trouble on the deadline before the project starts. When I did manpower studies, we used a figure that equated to just slightly more than 6 hours a day of direct work when calculating out how many people were needed for any job. And we did a lot of statistical analysis as the basis for the figure we used.
I think you have to decide which of these to use on a case by case basis. We have some projects that we know the max estimate is still probably a little low (usually when someone in management couldn't face the client with the real estimate), we have others where we are doing something new where we know the estimates are more likely to be off, in these kinds of cases go with the max. But for work you've done before that is well-defined and you know the dev assigned won't be learning new skills, then go closer to the min (but never actually use the min, there are alawys unexpected bumps in the road). ALso the shorter the project, the more likely you will be able to meet the min, it is far easier to get a good estimate for a week-long project than a year-long one.
More importantly is changing the estimate and deadline every time the circumstances change. If the client adds work, the extend the deadline and estimate, don't just do it. If your best dev quits and you have to put someone new on the project, extend the deadline becasue that person has to have time to get up to speed (you may have to eat the hours though, the client may not agree to pay for that time. Critical to this is telling the client right away. They tend to be better about moving a deadline (although not happy) than they are about missing one or making the dealine but the product doesn't work as they expect it to. Too many project managers just like to wish a problem is going away and the won't have to face that conversation with the client. But usually when they do finally have to tell him it is a much worse conversation than the difficult one they tried to avoid.