I want to calculate or estimate time needed to code a particular project. This may include time spent doing analysis, actually coding etc. I find it difficult to make a good estimate. Can someone help me in making a good estimation or direct me to tools etc.
5
-
What have you investigated so far? What is your knowledge about planning/estimating? What's your project situation? Are you doing something completely new? Do you have experts on board? Do you have a team at all? You have to provide more to get anything useful as a response...– Sven AmannCommented Jan 16, 2014 at 10:15
-
2What do you mean by "I find it difficult to make a good estimate"?– David EspinaCommented Jan 16, 2014 at 11:42
-
@salsolatragus Well we have a team but we work on seperate parts .. I'm only in charge of coding and developing the solution.. In terms of expertise we have a digital manager and I report to him directly. I have no knowledge on planning and estimating. We're a cross functional team and each takes care of an independant task.. I was the only coder until last week. So got another person on board.– J-DCommented Jan 16, 2014 at 22:25
-
A general rule I learned a while ago was to take the best estimate you can arrive at by any reasonable technique, and then double that, and then switch to the next larger unit of time. So if you think it'll take a day, figure two weeks. If you think it'll take two weeks.... four months.– mattdmCommented Jan 17, 2014 at 19:00
-
@J-D so what is it you want to estimate? Only your tasks? The whole team's work? General approaches to estimation and links to some literature have already been provided by others. I support that you should start there. Understand, however, that making good estimation requires experience and technical expertise.– Sven AmannCommented Jan 19, 2014 at 14:48
Add a comment
|
5 Answers
It sounds like you want to produce estimates for programming tasks. There are countless methods out there (none perfect but each offers something).
You should read about estimating from some books. Specifically, read about the Work Breakdown Structure. You do not need any software to do this, you can do it on your own (though the larger the project the more you will want to use some software solution). The short version is to divide up your project into components and keep sub-dividing until you get to components which have sizes that are easy to estimate.
You could also explore the Delphi Wideband method since you have at least one other person you work with (although Delphi should have more since data should be anonymous and with two people yours will not be).
There are lots of books on Project Management and many, like Field and Keller's text (just OK), which include significant parts dedicated to software development but are for overall project management, not just software project management.
Read and practice. It gets easier with time.
Gantter is one of the best ways to start with! Make a precise WBS (Work Brekdown Structure) with Hierarchy of tasks and Sub-tasks. Assign rough internal deadlines along-with actual deadlines. You'll be able to make better estimates as you go along!
Whatever books you read to help estimate, you need to really understanding probability and the effects of random variables. Way too often, and with very senior people, we have a tendency to think we control every variable at play on a project and, with real good planning, there is no reason why our cost and time targets are not met with zero variance. In other words, if you over- or under-ran, your planning was somehow at fault.
You need to understand that an estimate is probabilistic and is a range of probable results. Your planning value or target that you would price and baseline for performance is a single number that falls somewhere in that range. And the likelihood of you hitting that single number with zero variance is near zero. If you are targeting appropriately, your career should be filled with equal underruns and overruns and very very few zero variances if any.
Then you can lie like the rest of us on your resume about how you always underrun or meet targets.
If you want to see how this probabilistic thing works, log your commute time to and from work, door to door. Don't exclude any time, include everything, even stops to get gas, grocery, or even happy hour. Then build a histograph with your results.
answered Jan 17, 2014 at 12:07
Break the task down into smaller components. If you still can't estimate the components, continue breaking it down until the components are something you can estimate.
Try to estimate by using the knowledge you already have.
Consider a small task/project that you already done and compare it with the new one and try to estimate according to it.
Do it again for a difficult finished one.
Then decide where in between really the task will fall between those two estimates.
You can take the higher one if you are feeling pessimistic.
