Michael Tsai 2017/5/23
Reference
http://www.joelonsoftware.com/items/2007/
10/26.html
Why do you need a schedule?
Bad example (no schedule):
Amtrak’s Acela: express train from Boston to Washi ngton, 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 ***
Amtrak’s Acela
Lotus 1-2-3
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 th e time)
Track elapsed time
Estimate is always wrong (almost):
Unpredictable bugs
Interruptions
(Hard drive/machine 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 scen arios for the future.
Each of these possible futures has 1% probab ility, so you can make a chart of the probab ility 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
er not required
How do we accounts for all sorts of interruptions?
As long as we keep the clock running when we are i nterrupted, 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 in terruptions into account!
2 types of programmers
When developers get interrupted, they can either
make a big stink about putting the interruption on the ir timesheet and in their estimates, so management can see just how much time is being wasted on fishing conv ersation, or
make a big stink about refusing to put it on their tim esheet, 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 invite d.
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 c reate the estimate.
2. Fix bugs as you find them, and charge th e time back to the original task.
3. Don’t let managers badger developers in to shorter estimates.
4. A schedule is a box of wood blocks.
“use it as a chance to remove unnecessary fe atures“
