Extreme Programming Pocket Guide

Chapter 7. Business Practices

Building a successful software project requires far more than just coding. A beautiful, elegant, and comprehensively tested project is useless unless it meets the customer’s actual needs. Furthermore, the customer has finite time limits. You have finite resources. Exceeding either or both increases the chance of failure. Quality is also up to the customer, but developers should make the technical risks of reducing quality clear. The customer must decide if having a good-enough feature by a certain date is more important than having perfect software later.

XP is designed to minimize risk. Including the customer in the team improves communication between customers and developers. It’s easier to ask the customer what she wants directly instead of making guesses. Observing the project regularly allows the customer to guide the project based on immediate feedback. Dividing the project’s responsibilities along business and technical lines allows customers and developers to make the decisions they’re best qualified to make.

Business Practice 1: Add a Customer to the Team

Goal: to address business concerns accurately and directly.

Add a customer to the team. XP calls this the Whole Team. The customer provides a business perspective as an actual user of the software. Regular, reliable, and rapid communication between technical and business people improves confidence, reduces guesswork and misunderstandings, and produces the desired results more quickly.

The customer ...