I'm studying it personally and professionally. (I'm reviewing the two new XP books for Slashdot and have spec'd a two article series, one of which deals with similar things.) My perspective is a little weird because it's half academic, half free-software-developer.

I'm using Test::Unit (with props to our own clemburg) and doing the test-first, refactor mercilessly, write and complete stories approach with the Perl Rogue project.

It's hard to gauge the whole XP thing with a single-man program, but it's promising so far. Writing unit tests before code is pretty different, but it's the only way I'd get good test coverage.

The one thing I've noticed so far is that the combination of writing stories (to describe self-contained bits of functionality) and coding only as much as you need to pass the current test and complete the current story is improving code clarity and development speed. I don't have to plan for three or four different things at once. When I do come back to existing code, it's easier to make it more flexible (if necessary) because I have a specific and immediate goal in mind.

It's also harder to break things without knowing it, because all of the previous unit tests that must pass before you're finished.

This makes bugfixing easier, too, especially with multiple people on a project. A couple of weeks ago, I fixed a bug in Everything, creating another in the process. Darrick fixed the bug I created, recreating the bug I fixed. If I'd written a test to detect the bug I'd found, Darrick would have noticed it and come up with the correct solution immediately. (As he's a smart guy, he picked right up on it before I brought it up. But this could have been much worse.)

Currently, I'm trying to introduce some XP principles into Jellybean development. Only time will tell how successful we are there. I'm not yet confident enough with Test::Unit to know how to write good tests for some of the hairier bits there.