Adapting XP

I l @ ve RuBoard

No process, including XP, is the silver bullet for every team or every project. XP is a good idea that many development teams have used and had successes with. However, sometimes in our exuberance with our own results we make statements that sound like holy writ. This is not our intention .

This book itself is a departure from normal XP practices and a good example of where XP needs adjustments to make it relevant to Web development. We have made a blanket statement that Web projects are different from software projects and that there is a need to adapt XP practices to suit the needs of a multidisciplinary team.

We encourage everyone using XP for software projects, Web projects, or home gardening projects to try to understand the process, give its practices a chance, and then pick what works. Sometimes this is a gradual process.

When we started using XP we couldn't get past the lack of documentation. We still required the team to produce UML documents such as activity and class diagrams. Only after seeing unit tests in action and the stories generated from a CRC session were we able to let go. ^[3]

^[3] See Chapter 12 for a full discussion of CRC.

In other areas we still have problems accepting XP as dogma. For example, XP places the responsibility for writing stories squarely on the customer. However, in Web projects customers are not the domain experts we need, so stories are written primarily by a strategist or project manager. Customers still set priorities and aid in strategy development, but this is not the traditional XP story writing practice.

In spite of our reservations , Kent Beck has not excommunicated us from XP and Martin Fowler doesn't call us at three in the morning making threats. That said, we feel comfortable telling you to use XP when it works and not to use it when it doesn't. The real promise of a good process is that it can give birth to an even better one.

I l @ ve RuBoard