Extreme Programming Explored - Softcover

Wake, William C.

Softcover

ISBN 10: 0201733978 ISBN 13: 9780201733976

Publisher: Addison-Wesley Professional, 2001

Synopsis

You know what XP is, how to get it up and running, and how to plan projects using it. Now its time to expand your use of Extreme Programming and learn the best practices of this popular discipline. In Extreme Programming Explored, you can read about best practices as learned from the concrete experience of successful XP developers. Author and programmer Bill Wake provides answers to practical questions about XP implementation. Using hands-on examples--including code samples written in the Java programming language--this book demonstrates the day-to-day mechanics of working on an XP team and shows well-defined methods for carrying out a successful XP project. The book is divided into three parts: *Part 1, Programming--programming incrementally, test-first, and refactoring. *Part 2, Team Practices--code ownership, integration, overtime, and pair programming; how XP approaches system architecture; and how a system metaphor shapes a common vision, a shared vocabulary, and the architecture. *Part 3, Processes--how to write stories to plan a release; how to plan iterations; and the activities in a typical day for the customer, the programmer, and the manager of an XP project. To demonstr

About this title

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

About the Author:

William C. Wake, http://www.xp123.com , is an independent software consultant, coach, and trainer with more than twenty years of programming experience. Bill previously held positions with Capital One Financial, DMR Trecom, and VTLS, Inc. He is the author of the Refactoring Workbook and Extreme Programming Explored (both from Addison-Wesley).

About this edition

• Publisher: Addison-Wesley Professional
• Publication date: 2001
• ISBN 10: 0201733978
• ISBN 13: 9780201733976
• Binding: Paperback
• Edition number: 1
• Number of pages: 188