Extreme Programming Explored (Paperback)

~ (Author)

Editorial Reviews

Product Description

(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 release. Release planning is centered around user stories. The Customer writes stories, the Programmer estimate the stories, and the Customer plans the overall release. We discuss the release planning process and give examples of stories a Customer might write.

Chapter 9 shows the iteration planning game, which is similar to, but focused on, a time scale of weeks rather than months. The Customer chooses the stories for the iteration, and the Programmer estimates and accepts the corresponding tasks. We describe this process as a board game. The activities that the Customer, Programmer, and Manager will take part in during the day-to-day work of an iteration are described in chapter 10.

XP Resources For more information, see the references at the end of each chapter, and the bibliography at the end of this book. The code examples and other supporting materials are available online at xp123.

0201733978P04182001

See all Editorial Reviews

Product Details

• Paperback: 192 pages
• Publisher: Addison-Wesley Professional (July 28, 2001)
• Language: English
• ISBN-10: 0201733978
• ISBN-13: 978-0201733976
• Product Dimensions: 9.1 x 7.2 x 0.5 inches
• Shipping Weight: 9.6 ounces (View shipping rates and policies)
• Average Customer Review: 3.8 out of 5 stars  See all reviews (4 customer reviews)
• Amazon.com Sales Rank: #1,078,406 in Books (See Bestsellers in Books)

Customer Reviews

Most Helpful Customer Reviews

21 of 25 people found the following review helpful:

4.0 out of 5 stars Good for beginners, not so hot for others, August 24, 2001

By	Charles Ashbacher "([e-mail])" (Marion, Iowa United States([e-mail])) - See all my reviews (TOP 50 REVIEWER)

While I am now convinced that Extreme Programming (XP) is an effective way to design small to medium sized systems, I am not sure that much of it is all that different from the informal methods we have used for decades. The pairing together of programmers into teams of two where one types while the other thinks is similar to the informal chats that have gone on between programmers since the proverbial first programming team. It is different only in the formality of the system rather than in the fundamental structure. In fact, applying the partner rule too rigorously could lead to additional problems, in that it may reduce the amount of professional interaction between the members of the larger programming team.
If you have no previous exposure to XP, then this book is just right for you. However, if you know the principles of the process, then you will have to search for points of major interest. The book consists of a listing of the principles of XP as well as going through some simple examples. Some of the major problems that need to be addressed before XP can take its place as an effective methodology are stated but not really examined. At the end of the book, there is a short section entitled "Where is XP going?", with the subsection, "Limits of XP". In that subsection, there is the question, "Can a large team do XP?", with no attempt at an answer. This is one of two questions that the proponents of XP must answer soon.
All the books I have read, including this one, explain XP by going through examples of modest size. No one could possibly doubt that it will work in that environment. In fact, it is ideally suited for such projects. However, no one seems willing to tackle the problem of scalability. If the answer to the question about large teams doing XP is no, then it must be determined what exactly is a large team.
The second of the major problems with XP deals with the stress of working intensely with another human being for long periods of time. There are some sidebars where practitioners talk about how the synergistic effects of pairing lead to a dramatic increase in productivity. In one of the sidebars, there is the phrase, "working in pairs seems to bring out the best in everyone. " In my experience with programmers, there have been many occasions where the result is the exact opposite of the descriptions here. It doesn't always work, we all know it, so why coat it with sugar. This would have been a much better book if the issues of conflict resolution between pairs of programmers had been dealt with. Choosing and managing the paired programmers is clearly the most significant management dilemma that XP will ever present.
This book is a good description of XP at the basic level. Unfortunately, there are still some major unanswered questions concerning XP, and I await the book that makes a serious attempt to address them.

3 of 4 people found the following review helpful:

4.0 out of 5 stars An interesting read!, February 14, 2002

By	Lee (singapore) - See all my reviews

Willam C Wake is one of the first few who embraces XP at its earlier stage. In this book, he talks about the experience and understanding of XP. It clears much doubt any newcomer would have when embracing XP.

The book has examples on test-first programmming as well as refactering. I like to learn by example. It's a great way to learn. The examples are just right, not too complex nor too simplistic, and it brought out the concepts fairly well.

This book, IMO is a nice extension to the book "Extreme Programming Explained". A great book to grab after you have heard of XP and thinking of embracing it. Let the author's experience help you in getting up to speed with XP fast. :)

5 of 7 people found the following review helpful:

3.0 out of 5 stars A good 2nd XP book, but lacks advanced content, August 19, 2003

By	Michael (Paris, France) - See all my reviews

I'm a big fan of eXtreme Programming. I've read XP Installed (the first XP book I read), XP Explained (the first XP book), and Planning XP. I must say I was a big disappointed in this book. Here's the problem: This book doesn't explain XP in enough detail to be useful as a first XP book. But at the same time it does try to explain XP concepts which are already known to anyone who's read one of the XP intro books (Installed or Explained), making it too basic for someone who's been using XP. That leaves this book some where in the middle, with a little bit of introductory material and a little bit of advanced material. I think it's a good second book on XP (read XP Installed first), but if you've been using XP (especially refactoring and test driven development) then this book isn't going to be very helpful for you.

Also the book is pretty thin and quite expensive for the small amount of content it contains. In my opinion you'd be better off buying Fowler's Refactoring book and downloading the JUnit docs, and reading Jeffries' XP Installed.