问题
So you've just been put on the spot by The Boss. You've got 15 minutes to come up with a back of the envelope estimate for the addition of some new feature. Your boss (fortunately) recognizes that you can't provide an accurate estimate in that time so expecting something that is in the right order of magnitude.
The question is how do you go about giving a estimate in the time frame that is accurate to an order of magnitude?
Note that this is meant to be a quick and dirty estimate, not something that might be expected from questions like this
回答1:
Place finger in mouth, lick, wave in air and make up a number based on past experience. Then double it.
Really, its just experience that counts. You imagine what the task entails you doing, and you know how long it'll take you to do that. Double it for unanticipated items. This is also why you never ask junior programmers for such estimates.
回答2:
The best way is to try a quick breakdown of all of the major sub-components, e.g.
- Update data model script (3 items in 2 tables)
- Change input screen (3 new inputs)
- Check Input (3 new inputs)
- Update Data.
- Display results etc...
- Build unit test
Assign a rough guess on each of these and if you can't think of one put down at least 2 hours, because even the simplest item will probably take at least an hour, but the 2x will allow for uncertainty.
At least you will have thought of all the items you will have to do so it will be in the right order of magnitude as was requested.
回答3:
Think back to similar tasks you've done in the past and how long they took you.
If you've done nothing similar at all before, try to break the task down into subtasks, then each subtask down further, until no subtask is left that sounds like it will take longer than 1-2 days to prototype in the most naive possible way; if you can't divide up a task with an estimate of longer than 3 days, this usually implies that you don't really know what is involved in doing that task; do some quick research. Once everything is broken up enough, total it up, double the result and give that as your estimate.
If you don't know how to approach a problem enough to do the above, and your boss is breathing down your neck so you don't feel you can research there and then, instead try to give your boss an estimate of how long it will take you to do the research required to understand the problem enough to give him a proper estimate.
回答4:
I can't imagine a situation where I truly can't make an estimate at all--more often there's the case where I can imagine multiple scenarios which would result in vastly different timeframes for the project, depending on various things that could reasonably crop up. And I don't want to lie--the worst thing you can do with your boss is to just make stuff up.
So I explain each of the possibilities. Of course, this only works with an understanding boss, but if your boss is so ignorant or foolish that he refuses to listen to the full explanation, you have other problems.
For example, here's how I did it for a recent case where I actually had to do exactly this.
x264, the video encoder I work on, implements a very primitive form of interlaced coding chosen solely for the reason that it was very easy to implement. We wanted to implement the full form of this coding, but I had no idea how many of the assumptions made for the simplified version would fail in such a case.
So I thought through the various levels of things that might have to be changed, and made the estimate a range--well, at best, it might already be nearly working, but that's doubtful. And at worst there's a whole ton of stuff that needs to be changed. So, I told my boss, it was probably better to assume the worst here, since the spec was very complicated and despite not knowing about any of that complexity, I suspected that given the major lack of related code in the program, nearly none of that complexity was actually implemented. In the end I was right--the changes required ended up being quite complicated, and they outsourced the project to a contractor with more expertise in the complexities of H.264's interlaced coding.
回答5:
In addition to the necessary breakdown : an advice I learned from the Pragmatic Programmers is to express estimates over 15 days in weeks, and estimates over 8 weeks in months ; so that the unit reflects the accuracy of the estimation. Be very careful over 30 weeks.
You can also base your estimations on similar tasks you already done.
回答6:
If you really need very quick estimation, you can do work breakdown structure with every task for 1-2 days or smaller and after this estimate every task by providing min and max estimated values.
sum of min and max values specify interval for the whole task. This gives information abouts risks to your boss, which is always very useful.
You will obtain some interval, e.g. 12-15 day or 5-30 days - this is much more useful than 16 day instead of mentioned intervals.
It can be useful for you good book by Steve McConnel Software Estimation: Demystifying the Black Art.
回答7:
Think of a number, double it and then double it again (i.e. four times the first number that pops into your head)
When a boss says "how long to complete" a project, he means the time when it's complete and deployed live to the users. A programmer will (naturally) only think about the time needed to complete the programming (the time to physically type out the solution to the problem) so you typically under estimate.
A rule of thumb would be:
The 'first number' is the number of days you think it will take you to complete the task based on the scope of the task as just described. (But of course, you've not been told everything).
The first multiple is the extra time needed to recode after the first demo / prototype given to the boss and he says "Good, great. But can you add..."
The second multiple is the time needed to recode the recode up to the correct standard for production.
The third multiple is time for testing, documentation & deployment and all the other admin stuff you need to do to actually get the thing out and live.
And the fourth multiple is your contingency for the above.
This should give you a safe estimate. Of course, you should insist that a more thorough planning and estimation exercise.
回答8:
I've recently been reading Agile Estimating and Planning, and can't recommend it enough.
回答9:
If I am forced to provide estimates without enough time to properly investigate the subject at hand I tend to massively overestimate. The fix is almost always more difficult than I think it is going to be. If I think something will take a day then I say two days. If I say something is going to take an hour then I say a day. What I am trying to illustrate with these comments is that for all but the most mundane tasks like spelling mistakes, even a small code change can explode into a full day. For anything I think might take a day or more I double the estimate. I know it can be tough to do this. Management wants small numbers. You want to look smart and capable in front of other developer. See also Scotty Factory.
Even if you have QA team members that will test your code you have to remember that it is your job to test the code as well. Make sure to factor that into any estimate. That is something I have seen a lot of developers leave out of their estimating process.
回答10:
Factor #1 is the unknowns, and you're right, you can't know them all. However, you'll usually know some major questions no one can answer for you at that time.
Factor #2 is the perceived difficulty and availability of tools and resources at hand.
Result = roughly double your estimate
回答11:
Break down the task into parts and assign each part a time
Work in units of not less than 1/2 a day. This will prevent micro-scheduling
The big problem with project estimation is underestimation. If you know the task well and can almost see the code then weight the task by 1. If there is some uncertainty or the task requires an unknown technology then multiply it by a higher factor, depending on the level of uncertainty
Don't worry too much about accuracy of each part. The errors tend to cancel out as the only thing that really matters is the total duration
There is always the good old standby of taking the optimistic time scale and multiplying it by PI. Works more often than it should!
回答12:
I personally refuse this type of thing. But then i work for myself, so i dont answer to a boss. Just a client, but its easier to make them understand its hard to do on the spot.
回答13:
At times like these, I remember the McKenzie Brother's rule on converting to metric: "Double it, and add thirty."
I generally come up with how quickly I originally think it will take to do a thing, then double it because I'm always under-estimating, and then add 30 for testing, depending on the units I'm using.
回答14:
I usually break the task down into a few pieces, but I don't estimate for these kinds of things in blocks of time smaller than a half day. As long as there are at least 5 or 6 pieces to the feature after breakdown I find that the errors balance themselves out for the most part (some tasks take under an hour, etc)
Of course, the minimum time division and number of pieces required for some level of comfort needs to vary depending on the problem domain - at least 5 or 6 half day chunks seems to be about right for the stuff I've been asked about lately, but that needs to be reviewed every few months.
When I'm asked to estimate on behalf of someone else, I resist a bit more and follow a similar practice with a generous padding system ("double and add x" as mentioned above is probably a good approximation)
回答15:
To estimate in the right order of magnitude, you need:
- no introduction of new technology or framework for the wanted feature;
- to separate your estimate in pure development time and availability of developers (and customer and tester..;
- to get feedback on your earlier estimates;
- a size of feature in your safe estimation range (not 2 times as large with 2 times more people)
- a stable development team.
- no project startup overhead.
- to only estimate for work you do yourself.
回答16:
I believe the answer is always "six to eight weeks."
回答17:
"six to eight weeks" works really well, one other thing that works is based on the data model.
Imagine the number of database tables (or similar) needed for the application, multiply that by the number of days you need to code the models, CRUD, UI , etc for each table and add between 30% to 50% of time on top of that.
来源：https://stackoverflow.com/questions/109666/how-do-you-do-very-quick-and-dirty-estimations-for-coding-tasks