I like the generic term Agile software development better than the cringe-worthy Extreme Programming (XP) but whatever you call it we’re getting back into it at work.
One of the things I remember from reading about XP a few years ago was the bit about, if a certain practice is good you should do it all the time: ‘turn up all the knobs to 11’, which seems to me to be metaphorically opposed to the ‘driving a car’ approach to planning which emphasizes steering, making adjustments, not pressing the accelerator as far as it will go or turning up the stereo until it distorts and you go deaf from the SHOUTING.
This wext week we kick off a new project which we’re calling the “Integrated Courseware Environment”. The first requirements are to do with easy-to-use front end for our XML based courseware system, if that goes well maybe we will be able to tackle some broader issues in the learning-systems space later.
The team members have worked with bits and pieces of XP before. I have used an adapted version and the others researched it last year.
We don’t have a lot of time to research the process again so I was pleasantly surprised to revisit Extreme Programming: A Gentle Introduction today and find that this little site is a clear reminder of what to do.
And it seems that there is a more meta-agile flavor to the Extreme programming cult now than the old ‘do all these things at full volume approach’:
This new version has more advice in the form of principles and practices than the original and reminds us how our values must guide us in creating software. If we don’t know what we value how will we know what is good?
Gone is the restrictive notion that Extreme Programming is a limited set of practices. Greater emphasis is placed on the individual taking responsibility for improvement.
But is it getting more cult-like? Values? Really? What are our values? Cynical people might well ask “What is your job description?” We’ll order the book and have a read.
Anyway, our rough plan is to follow as many of the ‘rules’ as we can without too much stress or having to hit the books to work out how (don’t worry we can already do unit testing, automated builds, refactoring and related stuff). But we want to keep a list of other things to try that we can throw into the mix as we go.
The first thing? Like the site says, we need to run a couple of iterations to see what our velocity is. I think I see a transition from a process where we start by estimating and prioritizing user stories but we don’t promise how much we will get done in an iteration, to a process where we can estimate well enough to take on the right amount of work, and build trust with the customers and stakeholders. I’ll report progress here. I already have one cynic wanting to see how we go with pair programming in practice, we’ll see.
And we’re thinking about this advice from Rick Jelliffe, adding in the things he mentions here that we have not yet done and monitoring their effectiveness:
An approach I took a few years back, which I think is pretty workable when starting brand new development and team, is this: start off implementing a little of as many different strategies as possible (for Java, this would be Eclipse, JUnit tests, JLint/Findbugs or PMD, an IDE tool, a workable human communication system, a good version control system, periodic scheduled audits for i18n, accessibility, memory profiling, and usability, a skills-enhancement program, an Open Source library research effort, and so on.) Then cut back on the ones that are not providing value compared to their cost, and ramp up the ones that give bang per buck.
$LastChangedDate: 2005-02-15 01:50:29 -0600 (Tue, 15 Feb 2005) $