Copacetic

Ace King, check it out!

Ten things that will get your software out the door on time

leave a comment »

  1. Have a plan with an end date. Do the plan in reverse working from the point where your customer is using your software to where you are today. Do all the tasks fit in? Then your first estimate end-date is ok, for now.
  2. No Funky fractions. Try and avoid scheduling more than two resources on a task (ideally one task, one person). No 0.25 day tasks, No 1 day tasks with three people allocated.
  3. No go dark tasks. Avoid tasks that span more than 5 days. These are the critical path tasks that screw the whole plan. Watch any task less than 5 days that leaks across a weekend, these are the other boat sinkers.
  4. Convergence. Expect that your plan will be full of holes when your start so focus on convergence. The simplest goal is to have completed half the tasks when half the time has been consumed. If this is not then case then you need to actively replan.
  5. Contingency. Include a margin of error (20-40% depending on skill, experience, project complexity etc.). Your goal over the lifetime of a series of projects is to reduce this margin of error, rather than trying to give yourself an hernia constantly trying to hit unrealistic or badly estimated dates.
  6. Get stable. Your know or should know your XP drill by now. Get an end to end slice of functionality working early and build out from that core, refactoring as you go.
  7. Bring out your dead. Things will go wrong, get used to accepting that. Visibility is all. Don’t try and mask or conceal problems in the hope they will go away. Especially admit when you personally screw up, it happens, just make sure the process is a learning one for all concerned.
  8. Track your bugs. Bug count will keep you honest. Simple counts, no of new bugs each week (each day during testing), number of bugs fixed each week, total  number of bugs, total number of bugs broken down by severity. This can be parlayed into simple ratios that will govern how much quality you work into your product. A good bug curve can pretty much predict when you can ship.
  9. Quality = Beta. You can delivery quality software without a beta period. It just isn’t possible to replicate all the weird scenarios your customers are likely to articulate so plan to beta.
  10. Ship something. Better to ship half the product on time than the whole product 50% later than planned.

But you knew all this, didn’t you 🙂

Written by Joe

February 15, 2006 at 12:25 am

Posted in Uncategorized

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: