Software development plan for games

Hi /prog/. I've been trying to make small games for some time now, but even though I make some good progress, it always ends in a clusterfuck. I'm never sure what to do next and code is everywhere and totally out of hand. I'm pretty sure it's because I just start coding randomly without planning anything.
I was thinking that there must be some well tested development strategies for game making or small software development in general. I'm looking for something not too overly complicated, but that will get me a solid roadmap with attainable milestones and easy to calculate progress into my daily routine, but I don't know where to look.
Basically, I want to structure my approach in an orderly fashion, and if it can be oriented towards game development, all the better.
What do you know about the subject? Enlighten me please~
(bonus points if the strategy is scalable from 1 man projects to 2-3 people)

It is good to keep things as modular as you can, as described by >>3-san. I always make sure all of the code in a module is correct before moving on to other modules, especially when there are dependencies. It can be good to have a test file for each module, that runs through all cases you'd like to verify. This takes a bit of time in the short run, but it is a huge savings in the long run, as you otherwise end up hunting down the bugs in your application, which is much more complicated than a simple test function.

For design, I think about what I'm trying to make, and what are the basic subcomponents that will need to be implemented. Once I can determine that something will be needed, and I have a way of directly implementing it, I implement it, and test it, and then move on with the design. I can use the working implementations of the subcomponents to test out possible ideas for the next layer. My first implementation of the next layer is a very cludgy thing thrown together that uses to lower components. Once I get results and know that the scheme will work, I rewrite the implementation in its own module, and test it. Holding off on the actual design until results are found can save times when trying out approaches that end up not working out.