We don't bite newbies here... much | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
There is no silver bullet that will tell you how much time a task will take. Especially if you are new to the technology you are coding with. To do estimating well you need to have a constant feedback loop and accurate records of how long a task actually took. Each estimate you make needs to be feed in to the next estimate you make. Even if you use an algorithm for this you will still need to go through iterations before you will have an accurate estimate.
Here is how I provide estimates on my work.
• If I have not worked with the technology before I try to strip out everything I am familiar with and provide an estimate on that first. You will be off, the chances of getting it right the first time is remote. However if you estimate a larger time than you need, it will be easier to manage the project and/or customer expectations. Studies make it clear that most projects will be under estimated so go longer than you feel you will need. As well if you are enhancing or maintaining code your productivity will be lower than if you are making new code. Typically programmers doing enhancement work are 70% as effective and maintenance programming is 25% as effective as new coding, so you will need to add padding for that. No matter what the number is that you come up with keep your boss or client in the loop with the current estimate. They will be much more open to changes if you are open and honest with them. As well keep really accurate estimates of the time the task actually took. That way next time you will be that much closer ion your estimate. In reply to Re: Estimating Task Complexity VS Loudmouth
by terra incognita
|
|