Our developers recently returned from a conference on Extreme Programming. A few of them seem to really be fired up on this development approach and want to implement it ASAP. They'd like to get my (I'm the QA Director) agreement on the approach and start following it for our next project.
I'm a bit concerned because only the Engineering developers went to the conference. Shouldn't everyone in the company have an opportunity to learn the process, before we rush into implementing it? Also, with EP I'd like to know specifically how the requirements for a product/project are communicated. What is the Product Manager's role in the EP process?
So far, it sounds as if only Engineering and QA are involved. I keep hearing that the features are extracted from the planned tests. Seems a bit backwards to me, but I'm always open to new development processes. I'd just like to minimize the risk up front.
Re: Extreme Programming
XP is being seen as the next "silver bullet" in software development. Like all the others, it has it's good points, but has to be approached sensibly to work.
You're right to be a bit concerned. Not because XP is bad, but because anything you thrust into without proper planning is going to give you trouble. To make XP work the way it is designed to work -- and get the full benefit -- everyone has to be involved, from your "customer" down.
There are some things the programmers can do on their own that you can encourage. Paired programming and automated unit tests need only the programmers support -- and these activities can help you a lot with your QA responsibilities.
As for what your role is, I'd suggest reading the three XP books to figure that out. They are Extreme Programming Explained, XP Installed, and XP Managed. The XP web site (www.xprogramming.com) is a good place to start.
I too am a QA Director in a company looking to move to XP. I'm encouraging it.
Re: Extreme Programming
this is a repost from a discussion from a few weeks ago, but here goes:
one of the dangers of attempting to QA in an 'extreme programming' environment is that a lot of time is spent 'maintaining' the automated tests. the final deliverable is a constantly moving target - new features, code refactoring, and database changes contribute to a very rapidly morphing application. the theory of the continous build process (c.f. http://www.martinfowler.com/articles...tegration.html, which can be accomplished using, among others, http://cruisecontrol.sourceforge.net) leads to a QA quandary in that my team gets the choice of 25 or 30 builds a day - which one to grab? we've adopted a decidedly arbitrary 'one in the morning, one in the afternoon' policy, which doesn't allow a full regression suite to be performed daily, but gives very good feedback on a significant portion of the functionality of the application. we then stick with one build for more rigorous testing once every two weeks (generally to prep a release for our user community).
my project has been using XP for the past 18 months, so if anyone would like to contact me about anything regarding XP, please do...
[This message has been edited by dumbo (edited 04-26-2001).]