I've now been involved in three different projects of about five releases, each using a slight variation of the Extreme Programming (XP) (we are using the Industrial -- IXP -- variant) for approaching 5 years.
So, in a nutshell, does it work?
My opinion is YES and NO.
YES, the TEST DRIVEN DESIGN (TDD) aspects work and have lead to much more maintainable code, not to mention a better code design.
As for the NO part -- agile/XP ONLY works if there is complete buy-in from the entire team, and related supporting (read: management) personnel. Without a strong and ongoing commitment from all involved, XP doesn't work.
Further, XP can't be forced -- the individual must have the vision and the self-determination to follow that vision. Forced XP produces poor results: estimates that aren't accurate, non-optimal productivity, and code that suffers in quality and maintainability.
Each team (customer, QA, development) must continually train, review, evaluate, and improve their practices. If this isn't happening, organically, then there is more than likely a problem, or soon will be.
Subscribe to:
Post Comments (Atom)
5 comments:
Very interesting post. Thank you for sharing your computer knowledge with the world.
Hmmm.... I'll tell my people.
K... I may have to argue a bit with you on this one. (I know... big shock... me arguing with Bret.) I think the biggest issue with Agile XP is the fact that it takes an massive amount of communication to do it correctly. I have yet to work with a whole group of programmers that are all really good communicators. I worked within a team that used the Agile methodology for two years. I was one of the functional design architects and what we ended up with was a product that didn't match any documented specifications, not to mention matching business requirements we spent two years gathering from customers... and a bunch of programmers that weren't all quite sure about why they didn't match up. It was a frustrating environment and what we found is that the agile methodology became the scape goat for all problems with the software.
Yes, communication is essential. But, I don't think that communication is the core problem, merely a manifestation. I think that the underlying issue is that Agile does NOT take into account the general personality characteristics of the team groups. I'll expound further in another posting -- I think this is an important and overlooked topic.
TDD is an excellent concept. Every developer should incorporate it's principles into their development habits.
For the rest of Agile and XP in particular, I take a use the parts that work for you approach. But I believe most of them are very useful when applied properly. And like you stated, buy-in is key to any of them.
Also I've only done product development without a real customer present, no consulting or in-house IT work; so things might be different in those scenarios.
One of the main things is just getting away from designing everything up front. That doesn't work because you just can't see well enough before you get into a project. This idea is actually based in building construction, where it doesn't work either. Building plans always change as construction progresses. The Agile way is to do just enough planning at each stage to get it headed in the right direction. So using Agile based iterations merely moves decisions out until you actually have enough information to make a good call.
So here's a summary of what we use from XP:
Release Planning with just enough design up front
Iterations
Continuous Integration
TDD
Refactoring
Collective Code Ownership
I'm a big believer in pair programming too, but that doesn't work very well on my current team. 3 of the 4 of us team up naturally as needed. Meaning when we come across a sticky design or UI problem and need help creating an elegant solution we just grab someone and start going over it. The 4th member pretty much refuses to team up or ask for help unless it's a forced situation. But there's no question in all my experience with pair programming from college on that it results in better code and is slightly faster on a per item measure.
Post a Comment