(Update: This article says it all, but better)
One of the best tests of any software; or product infact; is to dogfood it.
A Gantt chart is an organisation tool for planning the progress of a project. You've probably seen a bunch of them.
They look like (in a perfect world)
or more realistically
How exactly do you eat that?
- It's not dogfood.
- It's a wall poster you have to update every day.
- It's out of date within hours of being printed.
- You can only model the highest level items, like "buy a new car" blocks "driving to alice springs".
- I can't describe a chart to you easily over the phone, IRC, or by text only email - it's something I have to send as mail, or something I have to send as one big image.
- If you don't read the chart the same way I do; it's ambiguous.
- High level items will have heaps of dependencies; because they are composed of a billion smaller tasks. If two high level items are sufficently close enough and made of enough parts, they both depend on each other.
- The solution to the previous statement is to then divide your high levels tasks into two high levels, and a common mid level task.
- Doing that; however; leads to intricate detail. Intricate detail is a bitch to maintain and changes fastest of all. The only thing that can model the current state of software perfectly is the source code itself.
- The whole point of a gantt chart is to deal with things at an abstract level. But you can't sufficiently top-down design a gantt chart; as you have to constantly redesign your chart as new dependencies emerge from your intricate detail.
- The only way to deal with things abstractly is to avoid all but the simplest dependencies: "I can't get inside of my house with a key"; so "I need a house" and "I need a key" BEFORE "I need to buy a tv".
- If you can't really model dependencies, how can you set estimated end dates? How can you estimate how long something takes?
- If you can't reliably get a duration, or end date for an item; and you can't model dependencies properly; what's the point in putting it on a gantt chart - it will move the very next day... and the next, and the next.
- A chart should be generated by your bugtracking software if there's anything at all. Bugzilla, for instance has a great way to show dependencies. It should be a URL, not a wall poster.
- Subtasks and dependencies (intricate detail) should be managed with your source code control - trac + ticket numbers in SVN commits, changesets on tickets, and trac milestones are a great way of monitoring individual items for completeness.
- You should have several milestones of where you would like to be. You don't set deadlines for those. As soon as dependencies resolve themselves to a suitable level (say, from 10 to 2); you pick up work on that individual milestone again. These are 'targets of opportunity'.
- During your dogfooding; if a user can't achieve their goal, X, it goes in as a ticket and stays open until they can.
- Set deadlines only when you are about to do a sprint. Two weeks, or a month at the most is the longest duration of a sprint.