ÉnKép - takacsot

Software developers don’t really like to make schedules. Usually, they try to get away without one.

...

Why won’t developers make schedules? Two reasons. One: it’s a pain in the butt. Two: nobody believes the schedule is realistic. Why go to all the trouble of working on a schedule if it’s not going to be right?

...

Here’s how you do it.

1. Break ‘er down: When I see a schedule measured in days, or even weeks, I know it’s not going to work. You have to break your schedule into very small tasks that can be measured in hours. Nothing longer than 16 hours. When you haven’t thought about what you’re going to do, you can’t know how long it will take.
2. Track elapsed time: It’s hard to get individual estimates exactly right.
3. Simulate the future: Hmm. Az egész szekciót ide kellen eidézni :) E az egyik lényeges rész. Randomra adunk a becsléshez szorzót. A szorzók a fejlesztő korábbi estimate/actual fejlesztési idejéből jönnek.
4. Manage your projects actively: Sasold a kritikus utat és vágj a featurokből, ha kell, vagy csúsztass határidőt.

További tippek:

1. Only the programmer doing the work can create the estimate.
2. Fix bugs as you find them, and charge the time back to the original task. 
3. Don’t let managers badger developers into shorter estimates.
4. A schedule is a box of wood blocks. Azaz timeboxing.
   

... 

Using Evidence-Based Scheduling is pretty easy: it will take you a day or two at the beginning of every iteration to produce detailed estimates, and it’ll take a few seconds every day to record when you start working on a new task on a timesheet. The benefits, though, are huge: realistic schedules.

 

http://www.joelonsoftware.com/items/2007/10/26.html