i know the extreme programmign debate is happening mostly off-list, but a
friend who' sworked for a couple of companies what practice XP, sent
me this summary of it, if anyone's interested ... maybe you all know this
already...
jo
xxxx
>>>>
It's a very good way of working. Apart from all the practical techniques,
the primary princples are:
* The requirements will change. If you try to nail them down before you
start you will just end up bogged down in change control later (and probably
sooner, too)
* Work with the customer on a day-to-day basis to discover the requirements.
Let the customer write the requirements (in the form of User Stories,
written on index cards) and let the programmers estimate them. The customer
then gets to choose which are the most important to be implemented first.
* Deliver in short, frequent iterations. The idea is to deliver small chunks
of value to the customer on a frequent basis so that they can see if what
they said they wanted was really what they wanted and don't end up after
three, six or however many months with the system they specified but which
is no longer relevant.
* "You aren't going to need it" - *never* implement anything that hasn't
been scheduled for implementation. Even if you can see the user story on a
card, if that story hasn't been scheduled yet then there is always a chance
that it won't be and implementing it now would be wasted effort.
* "Refactor mercilessly" - write only as much code as you need to implement
the requirement. When you come back later to extend that requirement,
abstractions will become apparent. At that time, refactor them. There is a
whole book devoted to refactoring patterns and techniques.
* Write unit tests first, then write the code to make them work. I've been
doing this today, in fact. My technique is to sketch out the interfaces I
need, write tests that will pass when those interfaces are properly
implemented and then write code until the tests pass. Using a tool like
JUnit (www.xprogramming.org) makes this very visual - it has a green
progress bar that turns red when a test fails. Write your tests and then
write code until the bar stays green. Then you're done!.
There's lots more, I've left out all the stuff on estimating and tracking -
read the book :-)
It works, but it takes a big change in mindset on the part of the
programmers, managers and customers. The use of constant feedback keeps the
project on track and ensures that you deliver what the customer wants. Most
importantly, the whole thing is based on treating the customer, managers and
programmers as intelligent people who work together.
