Extreme Programming Pocket Guide

Chapter 1. Who Cares About Process, Anyway?

Talking about customer rights and business changes may not matter much to you. Methodology—discussing methods of developing software—may seem dull and impractical. Does it really matter?

A project’s development method sets its values and guidelines. If your project values lots of written documentation, you’ll produce it. If your project values reliability, you’ll spend time on testing and proving code correctness.

Of course, what people actually do also affects your project’s culture. No matter how well-intentioned your values, if your methods aren’t practiced, they’re useless. A method that recommends voluminous design documents is just creating busywork if no one ever reads the documents, let alone updates them.

The development method you actually practice determines the kind of team you have and the kind of software you produce. You may tell prospective developers that everyone works a forty-hour week, but you can’t really guarantee that unless you know how to avoid the death march before a release. You might tell the customer that all code is reviewed, but unless developers actually check each other’s code, what good is saying the code has been reviewed?

The only way to save a troubled project or a troubled team is to figure out what’s broken and then fix it. Every development method is designed to solve some problem. Changing your project or your team is possible, with time. Following a good development method is a great place to start.

This book discusses XP’s values, how it goes about achieving those goals, and how to adopt those goals on your own project. First, you have to understand how XP views software development.