I'll start out by saying I've just skimmed through a co-workers book on Extreme Programming, so I really don't know *that* much about it...
Have you looked at the Unified Software Development Process? I think that it occupies a space somewhere between Extreme Programming and something quite a bit more traditional (for lack of a better word). It suggests a more "traditional" style of development: Requirements, Analysis, Design, Implementation, Test. But in a fast cyclical nature. That way you start with a functional core and build outwards. This is nice because you've got the ability to quickly prototype (and notice where things are potentially horribly wrong in your design), but you have enough formality to show a project's goals, status towards those goals, and definite plan to reach the goals. This is nice for large distributed projects, but not as pressing for a "scratch an itch"-type project.
Hum, I don't think I've given the best possible description of this process, but it's certainly worth a look. I believe that three of the "Gang of Four" came up with it, you can find a book on it under the title "The Unified Software Development Process", by Jacobson, Booch, and Rumbaugh. That back cover is horribly buzz-word filled, but it's an interesting read.
Also, I thought I'd interject (back to the original article) that there's no one fixed process that's "best". It seems that every project I've worked on ( as a commercial software "engineer" ) has had a different development process, tailored to fit its requirements. Code-and-fix is a great process for those quick hacks, it's not going to go away. And it's the right process for some projects. The same can be said for any other model and their respective "good" project types, so there's some danger in enforcing just one development process on all software projects.
Extreme programming seems to be a descendant of code-and-fix, with the addition of formality (the test-harness requirements). I'm curious, though, to see how well Extreme programming would do in regards to GUI development. At work we haven't found any good tools that can automate the testing of a GUI-based program... which kind of eliminates Extreme Programming from this set of problems -> the need to have incredibly solid tests indicates that you'd need a lot of trained monkeys clicking on windows in order to properly test the software.
Anecdotally: I worked on a truly horrendous project that was the result of changing requirements:
The problem with functional specs and requirements is that often they are not really known or understood at the time your start development.
A customer couldn't give us exact requirements, so we had to forcibly drag them out of him in a very formal process, to avoid a near-infinite development time frame. Once we had a nice formal design document, everything went together very quickly. Before the design document, chaos reigned. So there's a time and place for everthing. Knowing when to use a particular process is a very valuable skill.
[ Parent ]