Useful Hints for Software Project Planning?
staaktdenarbeid asks: "Over my software-writing career, I noticed that development efficiency closely follows the 80/20-rule. That is, 80% of the progress is made during 20% of the time. The rest of the time, er ...well you are waiting for the next big idea. No matter how well planned a project is, it turns out that true progress is only made at very few points over the entire project lifetime. I would like to ask other Slashdot developers for their experiences, and if they know (and apply) project planning techniques that create a smoother development path."
I don't believe in dual programming, but you can get somewhat of the same effect by requiring that programmers get together and explain their code to everyone several times a week. Just high-level architecture stuff. Each programmer should spend 5 minutes.
When developing software the most dangerous part should come early on. You don't want to pull a Daikatana and not understand what's difficult until late in the development - that's what causes late releases. Because you want to understand what's difficult first you should prototype the application. Hardcode as much as you can, even if it's half-assed, and program the minimal you need to get something that a programmer can recognise as components that address the main problems.
Prototyping is part of "release early, release often". Shame is part of "release early, release often".
Rather than planning technica details start from the interface. If you've got a client, and they're not computer programmers, they won't be able to know their requirements (and whether they're feasible) until they see it in front of them. Get them to draw the interface on paper and how they think it should work - this will help them get in the right mindset about the application. Provide them with prototypes. It's all about trying to jog their memory.
Price on phases (prototype releases).
--Giving to trolls for the benefit of us all