Scheduling
Michael Tsai 2011/4/29
Reference
http://www.joelonsoftware.com/items/2007/10/2 6.html
Why do you need a schedule?
Bad example (no schedule):
Amtrak’s Acela: express train from Boston to Washington, DC
PR campaign starts before it finishes: 看得到吃不到
Lotus 1‐2‐3 v.s. Microsoft Excel
Netscape 5.0: 2 years late, 80% 20%
Why? ‘Cause the programmers do not want to make a schedule.
No use. Not realistic
Real pain in the ***
Break’er down
Time unit: hours, not days (nothing more than 16 hrs)
It forces you to figure out the details (start to design)
(no details, then no way to figure out the time)
Track elapsed time
Estimate is always wrong (almost):
Unpredictable bugs
Interruptions
(Hard drive failure)
(火災警報)
(老師突然請導生宴)
Know how much time you
ACTUALLY spent on each task
Get the velocity (斜率)
Track elapsed time
The velocity can be:
1.0 1.0 1.0 1.0 ….
0.1, 0.5, 1.7, 0.2, 1.2, 0.9, 13.0, ….
0.6, 0.5, 0.6, 0.6, 0.5, 0.6, 0.7, 0.6, ….
Simulate the Future
Monte Carlo method: create 100 possible scenarios for the future.
Each of these possible futures has 1% probability, so you can make a chart of the probability that you will ship by any given date.
1.0 1.0 1.0 1.0 ….
0.1, 0.5, 1.7, 0.2, 1.2, 0.9, 13.0, ….
0.6, 0.5, 0.6, 0.6, 0.5, 0.6, 0.7, 0.6, ….
Holidays, vacations, etc.
Estimate: 4 8 2 8 16
Random Velocity:
(from history)
0.6 0.5 0.6 0.6 0.5 Total:
E/V: 6.7 16 3.3 13.3 32 71.3
Obsessive‐compulsive disorder not required
How do we accounts for all sorts of interruptions?
As long as we keep the clock running when we are interrupted, we are fine.
Original estimates: {2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, … }
Actual time with interruptions:{2, 2, 2, 2, 4, 2, 2, 2, 2, 4, 2, … }
Velocities: {1, 1, 1, 1, 0.5, 1, 1, 1, 1, 0.5, 1, … }
Monte Carlo simulations take the probability of interruptions into account!
2 types of programmers
When developers get interrupted, they can either
make a big stink about putting the interruption on their timesheet and in their estimates, so management can see just how much time is being wasted on fishing conversation, or
make a big stink about refusing to put it on their
timesheet, just letting the feature they were working on slip, because they refuse to pad their estimates which were perfectly correct with stupid conversation about fishing expeditions to which they weren’t even invited.
EBS gives the same results.
Manage your projects
actively
Buffer in the schedule
New feature ideas
Responding to the competition
Integration (getting everyone’s code to work together when it’s merged)
Debugging time
Usability testing (and incorporating the results of those tests into the product).
Beta tests
Will it converge and lower?
A few more points:
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.
“use it as a chance to remove unnecessary features“
