This is a book about Extreme Programming (XP). XP is a lightweight methodology for small-to-medium-sized teams developing software in the face of vague or rapidly changing requirements. This book is intended to help you decide if XP is for you. To some folks, XP seems like just good common sense. So why the iextremei in the name? XP takes commonsense principles and practices to extreme levels. If code reviews are good, weill review code all the time (pair programming). If testing is good, everybody will test all the time (unit testing), even the customers (functional testing). If design is good, weill make it part of everybodyis daily business (refactoring).

If simplicity is good, weill always leave the system with the simplest design that supports its current functionality (the simplest thing that could possibly work). If architecture is important, everybody will work defining and refining the architecture all the time (metaphor). If integration testing is important, then weill integrate and test several times a day (continuous integration). If short iterations are good, weill make the iterations really, really shortoseconds and minutes and hours, not weeks and months and years (the Planning Game). When I first articulated XP, I had the mental image of knobs on a control board. Each knob was a practice that from experience I knew worked well. I would turn all the knobs up to 10 and see what happened. I was a little surprised to find that the whole package of practices was stable, predictable, and flexible.

XP makes two sets of promises. G To programmers, XP promises that they will be able to work on things that really matter, every day. They wonit have to face scary situations alone. They will be able to do everything in their power to make their system successful. They will make decisions that they can make best, and they wonit make decisions they they arenit best qualified to make. G To customers and managers, XP promises that they will get the most possible value out of every programming week. Every few weeks they will be able to see concrete progress on goals they care about. They will be able to change the direction of the project in the middle of development without incurring exorbitant costs.

In short, XP promises to reduce project risk, improve responsiveness to business changes, improve productivity throughout the life of a system, and add fun to building software in teamsoall at the same time. Really. Quit laughing. Now youill have to read the rest of the book to see if Iim crazy. This Book This book talks about the thinking behind XPoits roots, philosophy, stories, myths. It is intended to help you make an informed decision about whether or not to use XP on your project. If you read this book and correctly decidenotto use XP for your project, I will have met my goal just as much as if you correctly decidetouse it. A second goal of this book is to help those of you already using XP to understand it better.

This isnit a book about precisely how to do Extreme Programming. You wonit read lots of checklists here, or see many examples, or lots of programming stories. For that, you will have to go online, talk to some of the coaches mentioned here, wait for the topical, how-to books to follow, or just make up your own version. The next stage of acceptance of XP is now in the hands of a group of people (you may be one) who are dissatisfied with software development as it is currently practiced. You want a better way to develop software, you want better relationships with your customers, you want happier, more stable, more productive programmers. In short, you are looking for big rewards, and you arenit afraid to try new ideas to get them. But if you are going to take a risk, you want to be convinced that you arenit just being stupid. XP tells you to do things differently.

Sometimes X.