Extreme Programming Explored (XP Series) (Paperback)

by William C. Wake (Author)

Editorial Reviews

Book Info
(Pearson Education) Guide for those who wish to learn XP programming and implementation skills. Uses practical examples, including code samples written in Java, to demonstrate the daily workings of an XP team. Begins with the basic programming, then moves into team practices, and finally covers the process of a successful XP project. Softcover. DLC: Computer software--Development.

From the Inside Flap
Extreme Programming (XP) defines a process for developing software: it addresses the problem from early exploration through multiple deliveries. We'll explore XP from the inside to the outside.

First, XP is a programming discipline. We look at a core innovation: how "test-first" changes the programming process itself. We also discuss refactoring--the way XP programmers improve their code. Second, XP is a team discipline, which has evolved a number of practices that help produce a high-performing team. We'll compare XP to alternative practices, and see XP's team practices in action. Finally, XP is a discipline for working with customers. XP has specific processes for planning and daily activity. We'll see how a team might schedule a release or iteration, and what the team does all day.

Why Read This Book? If you've heard anything about Extreme Programming, you probably have had a number of questions about the mechanics or the purposes of various aspects of XP. I've tried to capture the questions I've had, along with answers I've found. Several things about XP were surprises to me, particularly the tight cycle of test-first programming (only a couple minutes long), the use of a metaphor, and the starkness of the division of labor between Customer and Programmer. We'll look at these, and many other topics.

You, the reader, may have several areas of interest that bring you to this book:

Java and object-oriented programming. The first section of the book uses Java programming language examples to focus on test-first programming and refactoring. Programmers may find the discussion of team practices useful as well, particularly the ideas about metaphors and simple design.

Extreme programming, from the perspectives of Programmer, Customer, and Manager. We'll explore several areas in more depth, or from a different perspective, than the rest of the XP literature, especially the team-oriented practices, the metaphor, the planning process, and daily activities.

Software process in general. XP is one of a number of so-called agile, lightweight, adaptive processes that have been introduced in the last few years. By taking an in-depth look at XP's process. We can more clearly delineate where XP fits in with these related processes.

Who Is the Author and Why This Book? I'm "just a programmer," with about 15 years of experience, about half in compiler development and the rest in library, telecom, and financial services.

I attended the first XP Immersion class in December 1999. Although I had read Extreme Programming Explained, and much of the XP material on the Web, I was surprised by how test-first programming really worked (a much quicker cycle than I'd expected).

The question of testing user interfaces came up in the class; Kent Beck said he didn't usually develop user interfaces test-first, but asked, "Could you?" That inspired me to write an essay on the topic.

I write to learn, so as I explored various XP topics, I wrote a series of articles I called "XPlorations," and made them available on the Web. With the encouragement of my peers, I've adapted a number of those essays for this book in order to give a coherent view of the issues surrounding XP.

This Book's Philosophy Be concrete. Use real, or at least realistic, examples. When there's code, it will be Java code.

Answer questions. Because most of the chapters were originally written as essays for myself as I learned or taught others, each chapter starts with a question and a short answer. Many chapters include a Q&A (question and answer) section as well.

Be focused. Make each chapter focus on one topic. Tie it to other chapters whenever possible.

Be precise but informal. I use "I," "we," and "you" a lot. For the most part, "you" is addressed to a programmer, but in some cases, the word addresses managers or Customers.

Bring experiences to bear. I relate this material to real experiences. How This Book Is Organized This book reflects the layered approach, with the parts corresponding to the three layers. Each chapter answers questions pertinent to its part, and reflects questions I've had to answer while learning XP.

Part 1: XP as Programming XP Programmers write code using incremental test-first programming: unit-test a little at a time, then code just enough to make the test work. There is always a test to justify any new code. In chapter 2, we'll develop the core of a library search system using this approach.

A program isn't done just because it happens to work. XP strives to keep the whole system as flexible as possible by keeping it as simple as possible. Refactoring improves the code while ensuring it still passes all its tests. Simpler code can live longer. In chapter 3, we refactor a Java program that generates a Web page. By cleaning up obvious problems, we make the code ready for radical design changes.

Part 2: XP as Team Practices Chapter 4 looks at team-oriented practices and some alternatives to them: code ownership, integration, overtime, workspace, release schedule, and coding standard. Pair programming provides on-the-spot design and code reviews for each line of production code. Many teams struggle to introduce it, but XP regards pairing as a key mechanism for ensuring quality and team learning. Chapter 5 looks at a dialogue where two Programmers pair on a tricky problem.

XP doesn't emphasize "architecture" as a driving mechanism, but XP programs do have an architecture. The metaphor, the design, and the development process support an XP program's architecture (see chapter 6). The metaphor provides a conceptual framework and shared vocabulary for a system. This part ends with chapter 7, which explores how metaphors can drive the conceptualization and realization of a couple different types of systems.

Part 3: XP as Processes XP uses the notion of a planning game for planning the release (weeks to months) and for planning iterations (one to three weeks). The planning game uses two types of players--Customer and Programmer--and defines which player can make which move. In this way, the process maintains a critical division of labor: Customer determines value, Programmer determines cost.

Release planning is described in chapter 8. In the release planning game, the goal is to define the set of features required for the next rel