blocks|key|1628305|text|如果你根据过去的经验夸大你的估计，试图补偿你固有的乐观情绪，那么你就不是在膨胀。您正在尝试提供一个准确的估计。然而，如果你膨胀了，这样你就永远都会有松软的时间，那就不是那么好了。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1628306|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

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.

blocks|key|1628211|text|哦，是的，我已经学会了总是将我的初始估计乘以2。这就是FogBUGZ's+Evidence-Based+Scheduling工具如此有用的原因。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1628212|entityMap|0|LINK|mutability|MUTABLE|url|http://www.fogcreek.com/FogBUGZ/LearnMore.html?section=PredictShipDates^0|R|Z|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

Oh yes, I've learnt to always multiply my initial estimation by two. That's why <a href="http://www.fogcreek.com/FogBUGZ/LearnMore.html?section=PredictShipDates" rel="noreferrer">FogBUGZ's Evidence-Based Scheduling</a> tool is so really useful.

blocks|key|1414351|text|我将能够在3-6周内回答这个问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1414352|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I'll be able to answer this in 3-6 weeks.

blocks|key|1628370|text|这不叫“膨胀”--它叫“让它们变得更现实”。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1628371|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

It's not called "inflating" — it's called "making them remotely realistic."

blocks|key|1628188|text|接受你认为合适的任何估计。那就加倍吧。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1628189|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Take whatever estimate you think appropriate. Then double it.

blocks|key|1629076|text|六个星期。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1629077|行业标准:每次请求都需要六周时间。有些会更长，有些会更短，一切最终都会平分秋色。|1629078|此外，如果您等待足够长的时间，它不再成为问题。我不能告诉你有多少次我经历了那次消防演习，结果项目/功能被削减了。|1629079|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

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.

blocks|key|1413540|text|我不会说我夸大了它们，而是试图根据过去的经验设定更现实的期望。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1413541|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I wouldn't say I inflate them, so much as I try to set more realistic expectations based on past experience.

blocks|key|1413854|text|你可以用两种方法计算项目持续时间-一种是计算出所有涉及的任务，并计算出每项任务需要多长时间，包括延误、会议、问题等。这个数字看起来总是短得可怜，这就是为什么人们总是说“加倍”之类的话。在一些交付项目的经验之后，你将能够很快地告诉你，只需简单地查看一下规范，它将花费多长时间，并且，总是会是第一种方法得出的数字的两倍……|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1413855|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

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...

blocks|key|1413920|text|为调试和测试之类的事情添加特定的缓冲时间比仅仅夸大总时间更好。此外，通过提前花时间来真正规划工作的各个部分，您将使评估本身变得更容易(可能编码也是如此)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1413921|如果有什么不同的话，那就是记录你所有的估计，并将它们与实际完成时间进行比较，以了解你倾向于低估多少以及在什么情况下。这样你就可以更准确地“充气”。|1413922|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

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".

blocks|key|1628450|text|我不会说我夸大了它们，但我确实喜欢为项目中可能涉及的所有可能的任务使用模板。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1628451|你会发现并不是列表中的所有任务都适用于所有项目，但是有一个列表意味着我不会让任何任务漏掉，因为我忘记了为它们留出一些时间。|1628452|当你发现需要新的任务时，把它们添加到你的列表中。|1628453|这样你就会有一个现实的估计。|1628454|我倾向于对可实现的目标持乐观态度，因此我倾向于偏低的估计。但我知道我自己，所以我倾向于增加额外的15-20%25。|1628455|我还跟踪我的实际情况和我的估计。并确保所涉及的时间不包括其他中断，请参阅how+to+get+back+in+the+flow上对我的SO问题的接受答案。|offset|length|1628456|HTH|1628457|干杯|1628458|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/259932/any-aids-to-help-you-get-back-in-the-flow^0|0|0|0|0|0|10|R|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|10|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|11|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|12|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|13|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|14|8|@]|9|@$L|15|M|16|1|17]]|A|$]]|$1|N|3|O|5|6|7|18|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|19|8|@]|9|@]|A|$]]|$1|R|3|-4|5|6|7|1A|8|@]|9|@]|A|$]]]|S|$T|$5|U|V|W|A|$X|Y]]]]

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 <a href="https://stackoverflow.com/questions/259932/any-aids-to-help-you-get-back-in-the-flow">how to get back in the flow</a>.

HTH

cheers

blocks|key|1628514|text|我不会把项目的额外估算时间称为“膨胀的”，除非你确实在最初的估算之前完成了你的项目。如果你养成了总是在最初的预计时间之前完成项目的习惯，那么项目负责人就会变得聪明起来，并期望它能更早完成。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1628515|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

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.

blocks|key|1628744|text|你的估计是基于什么？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1628745|如果它们只是基于对需要多少代码和编写代码需要多长时间的模糊直觉，那么您最好对它们进行大量填充，以说明您没有想到的子任务、通信和同步开销以及意想不到的问题。当然，这种估计无论如何都是一文不值的。|1628746|OTOH，如果您的估计是基于上一次使用给定技术和开发人员数量完成该范围的任务所花费的时间的具体知识，那么通货膨胀应该不是必要的，因为上面的通货膨胀因素应该已经包含在过去的经验中。当然，可能会有一些新的因素，它们对当前项目的影响是你无法预见的--这些风险证明了一定数量的额外填充是合理的。|1628747|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

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.

blocks|key|1628788|text|这就是为什么敏捷团队使用story+points+(一个任意和相对的度量单位)来估计任务，然后随着项目的进展跟踪团队的速度(每天完成的故事点)的部分原因。有了这些数据，你就可以从理论上准确地计算出你的完成日期。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1628789|entityMap|0|LINK|mutability|MUTABLE|url|http://agilefaq.net/2007/11/13/what-is-a-story-point/^0|C|C|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

This is part of the reason why Agile teams estimate tasks in <a href="http://agilefaq.net/2007/11/13/what-is-a-story-point/" rel="nofollow noreferrer">story points</a> (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.

blocks|key|1414464|text|我假设最坏的情况，加倍，但仍然不够。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1414465|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I take my worst case scenario, double it, and it's still not enough.

blocks|key|1630144|text|承诺不足，言过其实。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1630145|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

blocks|key|1629294|text|我说我什么时候能把它做完。我确保使用新的评估来跟踪更改请求，而不是“是的，我可以这样做”。如果不提的话会花更多的时间。请求更改的人不会认为需要更长的时间。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1629295|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

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.

blocks|key|1629436|text|当然，如果不加25-50%25，你就是个笨蛋。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1629437|问题是，当你旁边的笨蛋不断提出比你低25-50%25的估计值，而首相认为你愚蠢/缓慢/摆动。|1629438|(其他人有没有注意到项目经理似乎从不将估计与实际情况进行比较？)|1629439|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

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?)

blocks|key|1629457|text|我的总体估计是guess+*+2.5+%2B+1+week。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1629458|entityMap^0|7|K|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|K|8|@]|D|@]|E|$]]]|G|$]]

My general estimation is <code>guess * 2.5 + 1 week</code>.

blocks|key|1629947|text|出于以下原因，我总是将我的估计加倍：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1629948|1)墨菲定律的缓冲区。总会有一些你无法解释的地方出问题。|1629949|2)低估。程序员总是认为事情很容易做。“哦，是的，只需要几天的时间。”|1629950|3)讨价还价空间。高层管理人员总是认为可以缩短日程安排。“只要让开发人员更加努力工作就行了！”这允许你给他们他们想要的东西。当然，过度使用这个(不止一次)会让他们认为你总是高估了。|1629951|注意:最好总是将buffer放在项目时间表的末尾，而不是为每个任务。永远不要告诉开发人员缓冲区的存在，否则帕金森定律(工作扩展以填满可用于完成缓冲区的时间)将取而代之。有时我会告诉上层管理，缓冲区是存在的，但显然我不会给他们第三个理由作为理由。当然，这取决于你的老板在多大程度上信任你诚实。|1629952|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

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.

blocks|key|1414119|text|我不会夸大我的估计，我会夸大它们！|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1414120|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I dont inflate my estimates I pad them!

blocks|key|1414231|text|两个星期。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1414232|行业标准:每次请求都需要两周时间。有些会更长，有些会更短，一切最终都会平分秋色。|1414233|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Two weeks. 

Industry standard: every request will take two weeks. Some will be longer, some will be shorter, everything averages out in the end.

blocks|key|1629365|text|与其说我“膨胀”，不如说我会计算出最可能出现的最坏情况。根据项目的复杂性，我可能会更多地考虑到不可预见的情况。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1629366|因为我的项目通常不会达到“最坏的情况”状态，所以我通常在估计时间之前完成，但为了估计的目的，已经足够接近了。如果可以选择是太早完成还是太晚完成，我每次都会选择提早完成。|1629367|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I don't 'inflate' so much as work out my most likely worst-case scenario. Depending on the complexity of the project, I may pad more just to account for unforseen circumstances.

Since my projects don't often reach 'worst-case scenario' status, I'm usually done before the estimated time, but close enough for estimatory purposes. Given the choice between being done too early or too late, I'll go for early every time.

blocks|key|1629667|text|在评估项目的前十分钟内，我通常会花掉最初时间的250%25。前100%25是我知道可以快速完成的事情，下一个100%25是因为意外事件而额外的，最后额外的50%25是“与其他人沟通”。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1629668|对我来说似乎没什么问题。|1629669|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I usually take about 250% of the initial timespan I think of within the first ten minutes of evaluating the project. The first 100% is for the things I know can be done and fast, the next 100% is extra because of unforeseen events, and the last extra 50% is 'communication with other people'.

Seems to work fine for me.

blocks|key|1629713|text|我加了50%25。然而，如果我以前与客户合作过，并且我知道他们喜欢在接近尾声时做出改变，那么这个数字可能会增加一倍甚至更多。我试着预测未知，因为我can...sometimes我成功，有时失败。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1629714|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I add 50%. However, that can move to double or more if I've worked with the client before and I know they like to make changes toward the end. I try to anticipate the unknown as I can...sometimes I succeed, sometimes fail.

blocks|key|1630071|text|是的，我给它们充气。但还不够。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1630072|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Yes, I inflate them. But not by enough.

blocks|key|1630110|text|我从来不认为估计是不准确的，因为程序员不能估计编写代码需要多长时间，而是因为他们只估计编写代码需要多长时间。会议、客户响应时间、测试、客户变更、业务规则修订等等根本不会被估算出来。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1630111|当这些项目在一开始就被考虑在内，并且项目是在任务级别进行估计的时候，而不是“哦，我认为这将需要……7周！”那么估计通常是准确的。|1630112|所以如果我填充，那是因为我碰巧知道这些项目没有被计算在内，或者这些项目没有被适当地计算出来。|1630113|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

I've never thought that estimates were inaccurate because a programmer was not capable of estimating how long it takes to write code, but because they estimate how long it takes to write the code ONLY. Meetings, client response time, testing, client changes, revisions to business rules and the like don't get estimated at all.

When those items are accounted for in the beginning, and the project is estimated at the task level, not "Oh, I think this will take... 7 weeks!" Then estimates are generally accurate.

So if I pad, it's because I happen to know that these items were not accounted for, or that these items were not calculated appropriately.

blocks|key|1628917|text|我喜欢“加倍”的政策。但是，至少要增加30%25。这是我在上一次IBank上的一位高级经理告诉我们的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1628918|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I like the "double it" policy. However, at the very least increase it by 30%. This was once told by us by a Sr. Manager at my last IBank.

blocks|key|1629203|text|如果你不得不加倍或夸大你的估计，以使它们接近现实，那么你最初的估计显然是错误的或不完整的。估计需要包括任务可能遇到的所有因素。在没有正当理由的情况下增加额外的时间只是为了掩盖你的a**，在全量的背后应该有一个原因，而不仅仅是为了安全而添加X。如果你知道将会有重新设计和调整，那么考虑到这些因素，同样的会议，测试，错误修复等。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1629204|正确的估计应该与atcuals匹配或接近，否则估计是不正确的。|1629205|我们的目标是让实际情况尽可能地接近估计，在估计游戏中得到很好的结果就像在评估游戏中一样糟糕。|1629206|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

If you have to double or inflate your estimates in order for them to work out close to reality then your original estimate was clearly wrong or incomplete. Estimates need to include all factors the task may encounter. Adding extra time for no valid reason is just covering your a**, there should be a reason behind the full amount, not just add X to be safe. If you know there will be redesign and tweaks, then factor those in, same for meetings, testing, bug fixes, etc.

A proper estimate should match atcuals or be close, otherwise the estimate was incorrect.

The goal is to have actuals be as close to the estimate as possible, coming in well under is just as bad as going over in the estimating game IMHO.

blocks|key|1414770|text|我会不惜一切代价避免项目的时间估算。相反，我更喜欢预测到第一个里程碑的时间，并制定完成的里程碑，在我进行的过程中定期审查悬而未决的里程碑。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1414771|例外:当代码本质上是完整的，并且只需要为里程碑修改时。当项目是琐碎的或与以前的项目基本相同时。当有完整和准确的规范时(例如在应用程序平台转换的情况下)。|1414772|如果客户或经理坚持要一个明确的目标日期，那么我将坚持一个完整的规范。或者我去找另一个经理或者客户。如果所有这些都不是一个选择，我将从空气中拉出一个日期，并让他们知道它是高度不准确的，很可能会错过，但会随着里程碑的完成而改进。|1414773|时间估算的技巧和方法的类型因项目类型的不同而有所不同，这就是为什么估算仍然是一门模糊的艺术。|1414774|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

I avoid time estimates for a project at all costs. Instead I prefer to predict time to the first milestone and map out milestones towards completion, periodically reviewing pending milestones as I go.

Exceptions: When the code is essentially complete and simply needs to be modified for the milestone. When the project is trivial or largely identical to a prior project. When there is a complete and accurate specification (such as in the case of an application platform conversion).

If a customer or manager is insistent upon a firm target date, then I'll insist on a complete specification set in stone. Or I find another manager or customer. If none of that is an option, I'll pull a date out of the air and let them know it is highly inaccurate and will likely be missed but will refined as milestones are complete.

Types of time estimation tricks and approaches all vary from type of project to type of project which is why estimation remains a fuzzy art.

blocks|key|1414870|text|我采取了相反的方法，这似乎是最常见的态度，我试图让我的估计尽可能准确，然后确保项目经理知道我不会夸大我的估计。然后，由他们来应用任何2的随机因子或他们感到舒服的任何东西。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1414871|当我给出估计的时候，我也喜欢给出一些关于估计是如何通过的指示。一些排序的值，从“我已经把这个数字从我的屁股里扔了出来”到“我花了一周的时间详细列出了所有的任务，对任何复杂的或未知的集成进行了原型设计，估计是事实的陈述”(这不是一个常见的:)|1414872|这主要来自于几个项目，在这些项目中，似乎管理链中的每个人都在估计中添加了自己的小摆设因素，以至于最初的项目计划大约是正常情况下的3倍。这样的事情似乎随之而来的是一轮随机的讨价还价，削减了项目时间，除了办公室政治之外，没有任何其他真正的参考。|1414873|我想这是一个你有多信任你给出估计的人的情况，我真诚地相信你必须能够信任并对你的项目/产品经理100%25诚实，并且能够给他们你诚实地相信是真实的估计。另一方面，它们必须是合理的，当你超出你的估计时，谈论它，并试图改善你的估计，而不是只咬你一个新的。|1414874|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

I take the opposite approach to what seems to be the most common attitude, I try to make my estimates as accurate as I can and then make sure that the project manager knows that I don't pad my estimates. It's then up to them to apply any random factor of 2 or what ever they feel comfortable with. 

When I'm giving estimates I also like to give some sort of indication of how through the estimate is. Some sort value ranging from "I've just plunked that number out of my ass" to "I've spent the last week detailing and listing all of the tasks, prototyping any complex or unknown integration and the estimate is a statement of fact" (not a common one that :) 

This has mainly come from a couple of projects where it seems that everyone in the management chain has added there own little fiddle factor to the estimate such that the initial project plan is about 3 times longer than it should be. What seems to follow such things is round of random horse trading that chops the project time down without any real reference to anything other than office politics. 

I guess it is a case of how much you trust the person your giving the estimate to, I sincerely believe that you have to be able to trust and be 100% honest with your project/product manager and be able to give them estimates that you honestly believe are truthful. The flip side to this is they have to be reasonable and when you over shoot your estimates talk about it and try to improve your estimating and not just chew you a new one.

blocks|key|1415071|text|我从来不会把它翻一番。通常情况下，一个设计/想法/更改会出现在一个帖子上，我通常是从估计一年开始的，而且它记录的帖子越精致，我的估计就越好。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1415072|即使这样，我知道当我完成我的实现时，我只完成了一半。这通常在最初的年份估计之内，所以有足够的时间让post+it作者解决任何设计问题。|1415073|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I never just double it. Usually a design/idea/change is presented on a post it note I usually start with out with an estimate of about year and the more refined the post it notes get I get the better my estimate gets.

Even with this I know that when I finish my implementation I'm only half done. That's usually well within the original year estimate so there's plenty of time for the post it writer to flush out any design problems.

blocks|key|1629865|text|如果你是一家咨询公司，你真的需要深思熟虑一下，不要把你的估计填得太多。你需要赚钱，对吧？如果你不想让你的资源更快地承担下一个任务，你就不能这么做。另外，考虑你要承担的项目类型。你能和客户做T&M吗？如果没有，你被迫提供一个固定的出价，也包括一个固定的持续时间，并与客户分担风险。我无法告诉你，我看到有多少同事在这个讨论的话题上搞砸了。作为一名项目经理，你必须站出来，a)提供一个小的，合理的填充，以确保交付日期可以满足，b)谈判并分担固定投标项目中所涉及的风险，通过在SOW中获得良好的语言来保护你，以及c)你正在努力赢得这项工作，对吗？？像这样做，并确保你的A团队在规划阶段得到了评估，以保持竞争力。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1629866|WPF和Silverlight是相当新的，但我们很快就会得到竞争对手低于我们的报价。|1629867|稍微离题，但帮助客户在与销售人员谈判项目时意识到团队的紧张程度。一个好的项目经理可以帮助赢得新客户的尊重和信任。|1629868|当谈到内部资助的项目时，这真的没有什么区别。由于野兽的性质，以及谴责生命周期和许多此类项目的请求，他们需要更强大的项目管理，而不是一些高风险、短持续时间的外部项目。|1629869|最后，你必须从将要执行这项工作的资源中获得支持。团队领导应该支持这些估计，并能够判断它们是高还是低。你必须能够在每个项目上获得ROI，所以有时你可能需要比预期更多的估计。但实际上，如果工作量很小，你只能在项目中投入一个B或C资源团队，如果出价太高，就把机会留在桌面上。除非它有重要的商业意义，否则如果你真的没有资源完成它，就避免接受这份工作。在目前的经济形势下，这并不总是一种选择。|1629870|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

If you're a Consulting Firm, you really need to be thoughtful about padding your estimates too much. You need to make profit, right? You can't do that if you're shielding your resources from taking on their next assignment sooner. Also, consider what kind of project you're going to undertake. Will you be able to do a T&amp;M with the Customer? If not, and you're forced to provide a fixed bid, also include a fixed duration and share the risk with the client. I can't tell you how many colleagues I see that screwed on thewes kinds of topics on this discussion. As a PM, you've got to step up and a) provide a small, reasonable padding to assure the delivery date can be met, b) negotiate and share the risk invovled in a fixed bid project by getting good language in the SOW to protect you, and c) you're trying to win the work, right??? Act like, and assure your A-team gets its hands on the estimates during the planning stage to remain competitive.

WPF and Silverlight are rather new, but we're quickly getting competitors underbidding us.

Slightly off topic, but help the Customer realize the intensity of your team when negotiaitng the project with Sales. A good PM can help win respect and trust from a new Customer.

There's really little difference when talking about an internally funded project. Because of the nature of the beast and condemning lifecycle and req's from many of these types of projects, they need stronger Project Management than some high risk, short duration external projects.

Lastly, you must get buy-in from the resources that are going to perform the work. A Team Lead should bless the estimates and be able to tell if they're high or low. You've got to be able to make ROI on every project, so there's times when you may need to pad estimates more than desired. But truly if the work is small, and you're left throwing a B or a C resource team at the project, leave the opportunity on the table if the bid is too high. Unless it makes significant biz sense, avoid taking the gig if you truly do not have resources to pull it off. In this economy, that's not always an option.

blocks|key|1415338|text|请记住，大多数开发人员不会考虑太多测试时间，也不会考虑太多错误修复时间，也不会考虑管理开销(电子邮件、咖啡、会议..etc)一些小组每周只安排20个小时和/或增加至少2.5个小时|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1415339|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Bearing in mind that most developers dont factor in much test time, nor much bug fix time, nor the admin overhead (email, coffee, meetings ..etc) some groups only schedule 20 hours a week and/or multiply by at least 2.5

If so why? How much? 

I tend to inflate mine a little because I can be overly optimistic.

Do you inflate your estimated project completion dates?

如果是这样，为什么？多少钱？我倾向于夸大我的观点，因为我可能过于乐观了。

问您是否夸大了您估计的项目完成日期？
EN

回答 33

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问您是否夸大了您估计的项目完成日期？EN

回答 33

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问您是否夸大了您估计的项目完成日期？
EN