How did you estimate the time you will spent befor

问题:

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 11 months ago.

It feels really bad when you told your client or the manager that this can be finished by 10 days but you spent 20 days to get a point even not deployed to live yet.

Any experience can share with me about how did you estimated the time spent on a proposed projects?

Thanks

回答1:

Experience will help you get better as estimating, nothing else.

The most important thing to remember is to keep people informed though.

If the task was estimated at 10 days and you're at day 5 and clearly not going to manage it in 10, you should let people know at that point, not when it reaches day 11.

There are three options when things go over time, you take the hit and do the work anyway, you cut stuff from the system or you ask for more money for completion. The sooner that can be decided the better.

回答2:

As much as possible try to break things down into small pieces at the beginning. I've read before that people cannot accurately estimate the duration of anything that is longer than a couple of days, so the only thing you can do to work around that is to try to identify all of the pieces and estimate each one separately.

回答3:

Giving time estimates is something you can only get better at with experience.

Take your last experience and use it to modify your next time estimate.

Also see http://en.wikipedia.org/wiki/Estimation_in_software_engineering for more information.

I've found that one of the worst things you can do is glance at the requirements for the first time, and then make a guess during that initial meeting. Always say that you will need to get back to them, and then go analyze the requirements and give an educated response.

回答4:

You cannot estimate without knowing what you are going to do; you need to break the task up into chunks that you can reasonably estimate -- down to the HOUR (nothing less than 1 hour, round up)

e.g. "Make me a login page"

HTML login form - 1 hour Database table for users - 2 hours etc. etc.

Then, pull up a calendar and try and fill in the hours -- okay on Monday I can work about 5 hours, so that takes care of one task. Can you reasonably multitask? Probably, but don't say you can do 3 x 4 hour tasks in one day, even if you do have 12 hours to "spare" (that's too much).

Look at weekends; will you work them? Probably not, so include that. Gotta get your oil changed? Wedding coming up? Make sure to factor that in. Include some fudge time in case you can't work some days (kids get sick, power goes out)

回答5:

I actually make very detailed site map then estimate the hours (minutes) for each piece.

I show the site map to the client and tell them it will take double what I actually expect.

And then we detail out what each page will do so there is no debate as to whether or not the site is "finished".

Under-promise, over-deliver. I'm usually WAY ahead of what I tell the client and they're always happy I was done "early".

回答6:

One thing to always factor in is testing time. If something is going to take 10 days to develop, it would be ideal to allow for at least 7-8 days testing. Getting a good grasp of the requirements up front helps in estimating time. When/if requirements change you will have to let the client know that it will add additional time to the delivery date.

All in all, like Zack said, the more experience you get the more accurate you will be with your time estimates. Giving an unrealistic time estimate just to get a job can only be a bad thing. Of course, I'm not suggesting that's what you did. I'm merely stating it as a point of good practice.

回答7:

How much time have you really spent working on this? What distractions ahve there been? Every time you're concentrating and someone breaks that concentration (a normal state of affairs where I work) you can lose 30 minutes getting back to that state of concentration. Four or five of those a day and (with dealing for the reasons for the interruptions as well) you've lost half a day. Every day.

We all do this. Long after we should have learned better, we still do it. We think "that can't possibly take longer than a couple of weeks" and we speak out immediately instead of being smart and thinking. I'm talking to myself a lot, here!

How might it be if we said something like this: "I think in an ideal world I could get this done in maybe 10 days, but you and I know that things come up and need to be dealt with and that will have an affect. How about we prioritise the features and I'll work on them in order and report back as each is finished, with an updated estimate of time remaining?"

回答8:

One of my favorite programming teachers used to repeat this sentence every time he got the change: "Take the time you think you will take you to do it and multiply it by 3. Even then it will be a close call".

At first, lacking a better way of doing things, I actually did this. I still do! Mainly in those projects that you can feel the presence of a though client:)

It works for me. It is not scientific but it does work.

回答9:

I break down the project into the smallest distinct tasks I can. I then go over the list three times.

The first time I go over the list I look for things that I have a lot of experience with. These are things where based on my previous experience, I can make an very precise estimate of the time it takes.

Then I go over the list looking for things that I am unsure about, and I am worried they will take a long time. I spend some time researching each one of these, and break them down into even smaller tasks. That allows me to get a better idea of what exactly is involved, and it will make it easier to approach it later.

The last time I go over the list, I assume that each task will take one programmer one day of work to complete. Sometimes someone can do a whole bunch in one day. That's great. But sometimes a single task has all sorts of hidden nastiness that nobody ever expected, and it will take someone a week to figure it out. It evens out in the end.

This won't give you a very precise estimate. You can't really have a precise estimate. You can never reliably predict exactly what day you will finish something. However, this will give you a very good conservative and accurate estimate. Accuracy and precision are two different things.

回答10:

Identify all the tasks you possibly can. As others above have noted, the smaller the tasks you are estimating, the more accurate you will be. Add up the total time, then multiply by the crazy factor. The crazier your client is, the more time it's going to take. You've been consulting for a while, so I'm sure you know the type.

回答11:

Milestoning a project i've found can be very helpful. By this i mean that you identify key parts in your project which helps to split it down into timeframes for deliverables.

That way at each milestone, you can take stock of how your progressing and see if your falling behind, on time etc with your project.

ps. or you could do the classic approach of taking the time you 'think' it will take you, and then double it!!! ;)

回答12:

Also remember the old adage...

"The first 90% takes 90% of the time. The last 10% takes 90% of the time."

I don't think you can ever go wrong with taking how long you think a programming project is going to take and tripling it. Unless you've built EXACTLY the same thing before and it was within the last year, so much unexpected stuff will happen. You can't replace experience, but you can use this rule of thumb to stay out of trouble along the way.

And upvote the first responder... being honest and proactive along the way is huge. Better to avoid promising anything than to have to say you're not going to hit a mark.