The "big" estimate, i.e. how long the whole project will take is the most difficult element to predict. In that estimate I think you can only hope to supply the "order" of how long it will take i.e. weeks, 2-3 months, 6-8 months, a year etc... But never "It will take exactly 65 working days". Thus when the project starts out you should structure your sub-tasks according to the level of importance, and make sure you put in the essentials before going on to the the nice to haves.
This is because of the number of unknowns there are. Granted you may have done a similar project in the past, but all projects, even though they might be similar in some areas, still have differences. One thing you can do to try and improve your estimates is to always keep a log of what the estimate was, how long the task actually took, and then what were the issues that were not considered when the estimate happened. Estimating iteration to iteration (a 2 week iteration is a good length) is a lot more accurate and the methodology presented in Robert Martin's Agile Software Development is a good one, I think, where the next few tasks are all given points according to how big they are, in terms of how long they might take (not time units, just units) and each team member is allocated tasks according to how many time points they got through in the last iteration (last 2 weeks). That way the estimations are constantly changing based on historical performance. It also means that different developer speeds are accounted for. In my experience developer speeds can differ by factors of 10! The other issue that clouds estimation accuracy, is that if you're writing re-usable modular code, then at the beginning of the project tasks will take longer because of the amount of framework code you're writing. I noticed this in one of the large projects I was involved in. As the project develops, you'll find that you're writing less and less new code and therefore doing things - you've solved some of the common problems already. I feel that in every project there are problems which are common to the sub tasks that could potentially only be solved once and re-used. This acceleration is _very_ difficult to predict because you don't know how what the common problems are and therefore how much re-usable code will be produced. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CTJUG Forum" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/CTJUG-Forum -~----------~----~----~----~------~----~------~--~---
