Register your product to gain access to bonus material or receive a coupon.
Extreme Programming Explored
- By William C. Wake
- Published Jul 18, 2001 by Addison-Wesley Professional. Part of the XP Series series.
Book
- Sorry, this book is no longer in print.
Description
- Copyright 2002
- Dimensions: 7-3/8" x 9-1/4"
- Edition: 1st
- Book
- ISBN-10: 0-201-73397-8
- ISBN-13: 978-0-201-73397-6
Extreme Programming (XP) is a phenomenon. It promises developers unprecedented efficiency and quality -- and it's delivering on that promise. In this book, Bill Wake doesn't just explain XP to developers who are new to it: he shows how to personally apply the XP best practices that have been identified by leading-edge practitioners. This new book emerged from a series of Bill Wake's essays intended to help XP newbies understand and personally apply XP. Wake covers each key tenet of XP development, including the central role of developers, programming in pairs, direct communication with customers, and continual testing. The book's pragmatic, hands-on approach is reinforced with supporting Java code, concrete examples, and extensive war stories. Along the way, Wake addresses major objections to adopting XP, and introduces new XP "best practices" that allow organizations to introduce XP far more rapidly and successfully. For every developer, software engineer, architect, project manager, or software customer already using XP or considering the introduction of XP methods.
Sample Content
Online Sample Chapter
Extreme Programming for the Customer, Programmer, Manager: What's a Typical Day
Downloadable Sample Chapter
Click below for Sample Chapter related to this title:
wakech2.pdf
Table of Contents
Forward.
Preface.
Acknowledgments.
Introduction.
I. PROGRAMMING.
1. How Do You Write a Program?Program Incrementally and Test First.
2. What is Refactoring?“Refactoring: Improving the Design of Existing Code.”—Martin Fowler.
II. TEAM PRACTICES.
3. What Are XP's Team Practices?“We'll Explore These Practices and Their Alternatives.”
4. What is it Like to Program in Pairs?Pair Programming is Exhausting but Productive.
5. Where's the Architecture?Architecture Shows Up in Spikes, the Metaphor, the First Iteration, and Elsewhere.
6. What is the System Metaphor?“The System Metaphor is a Story that Everyone—Customers, Programmers, and Managers—Can Tell About How the System Works,”—Kent Beck.
III. PROCESS.
7. How Do You Plan a Release? What are Stories Like?Write, Estimate, and Prioritize Stories.
8. How Do You Plan an Iteration?Iteration Planning Can be Thought of as a Board Game.
9. Customer, Programmer, Manager: What is a Typical Day?Customer: questions, tests, and steering.
Programmer: testing, coding, and refactoring.
Manager: Project Manager, Tracker, and Coach.
10. Conclusion.Bibliography.
Index.
Preface
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'll look at a core innovation: how "test-first" changes the programming process itself. We'll also discuss refactoring--the way XP programmers improve their code.
Second, XP is a team discipline that has developed 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 XP, you probably have had 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 more deeply 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 several 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.
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 some of those essays for this book in order to give a coherent view of the issues surrounding XP.
What Is the Philosophy of This Book?Be concrete. Use real (or at least realistic) examples. When code appears, it is Java code.
Answer questions. Because most of the chapters originally were written as essays for myself as I learned or taught others, each chapter begins 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 where 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 sections, the word may be addressed to managers or customers.
Bring experiences to bear. I relate this material to real experiences.
0201733978P07122001
Index
A
Acceptance tests, xx, 119, 145
graph, 137
running of, by customers, 126
tracking of, by trackers, 135, 137
written by customers, 124, 125- 126, 130
"Anti-patterns," 27
Architecture, 75-83
defined, 75
documenting, 81
Extreme Programming, xxiv
first iteration, 76, 78-79, 83
4+1 View Model, 75
metaphor, 76, 77, 83, 86
refactoring, 76, 80-81, 83
small releases, 76, 80, 83
spike, 76-77, 83
team practices, 76, 81, 83
Array of lines model, 90
Arrays
refactoring, to convert to Vector, 14, 17
Assembly line metaphor
customer service example, 88
B
Beck, Kent, xiv, xxiii, 4, 7, 27, 55, 78, 81, 85, 143
Beizer, Boris, 125
Berra, Yogi, 144
Black box, 48
Brain
paired programming and nature of, 70
Broadcast metaphor, 92
Bug-fixing
refactoring separated from, 32
Bugs, 82
Builds, daily, 52-53
Bullpen office type, 57
Bus number, 50
C
Capital One, 64, 70
Card metaphor, 90
Case sensitivity, 13
Celebrations
and XP managers, 134
Chrysler 3C project, 139
Coaches
role of, in managing XP, 132, 138-140, 141
See also Customers; Trackers
Cockburn, Alistair, 82, 138
Code
breaking, 53
duplicate, 29, 140
testable, 3
unit test, 129. See also Refactoring
"Code freeze," 52
Code ownership, xxiii, 47, 48-52, 60
collective, 50-52
by layer ("tribalism"), 50
monogamous, 48-49
orphan, 48
"serial monogamy" or "rental property," 49-50
"tag," "musical chairs," or "trial by fire," 48
Code reviews, xxiv
and paired programming, 70
Code smells, 27, 30, 31, 42, 43, 130
Coding standards, xxiii, 47, 59-60, 81, 129, 145
"Coding wars," 56
Collective code ownership, 50-52, 145
Combination metaphor, 91
Configuration
and first iteration, 79
Connection metaphor, 92
Contingent estimates, 121
Continuous integration, 53
Controls and gauges metaphor, 92
Coyne, Richard, 87
Cross-training, 82, 120
Crowd programming, 64
Cubicles, 56
Customers, xiii, xx
acceptance tests written by, 130
and Extreme Programming, xx, xxi-xxii
future role of in XP, 145
and paired programming, 65
and planning game, xxiv
questions and answers by/for, 127-128
and release planning, 99
and Release Planning Game, 100
role of, during iteration, 123-128
scope chosen by, 103
stories selected for iteration by, 117, 122
stories split by, 102
stories written by, 101
tasks of, during release planning, 135-136
and XP managers, 133
See also Coaches; Programmers; Trackers
Customer service example, 87-89
D
E
F
G
H
I
Daily builds, 52-53
Data
denormalization, 48
model, 82
"Data bag" class 7
Data structures metaphor, 92, 93
DeMarco, Tom, 56
Deployment (technical) architec
Deployment view, 75
Design, xxiii, 5-7
metaphors in, 87
and paired programming, 70, 72
in test-first programming, 129
of tests, 125
Desktop metaphor, 87, 92
Disengaged programming, 64-65
"Do It" interface, 58, 79, 80
Domain objects, 6
"Do the Simplest Thing That Could Possibly Work" princi
DRY ("Don't Repeat Yourself") principle, 30
Duplicate code, 29, 140
Dynamic objects metaphor, 92
E-commerce
shopping carts for, 87
Editors example, 90-91
"Eight-hour burn," 54
EMACS, 90
Empty queries, 13
Examples
customer service, 87-89
editors, 90-91
more metaphors, 91-93
release planning: exploration, 104-113
release planning: sorting and selecting, 113-114
Extract Method, 28, 31, 34, 35, 43
Extreme Programming, 26
and architecture, 75-76
and coding standard, 59, 60
collective code ownership used by, 51-52
description of, xiii, xix-xxii
and 40-hour work week, 54-55, 131
future of, 144-145
getting started with, 145
layered approach with, x
limitations with, 83, 144
open workspaces specified by, 56
as processes, xxiv
as programming, xxiii
programming activities, 128
resources, xxv
rigidity and, 143
small releases favored by, 58
as team practices, xxiii-xxiv
test/code cycle in, 8
underlying values in, 144
See also Team practices
Finseth, Craig, 90
Firewalls, 78, 79
First iteration, 76, 78-79, 80, 83
"4+1 View Model of Architecture, The" (Kruchten), 75
40-hour work week, 54, 55, 60, 131
See also Workspaces
Fowler, Martin, 23, 27, 28, 32, 81, 130
Functionality
and first iteration, 79
Funders
and XP managers, 132-133, 134
Gamma, Erich, 4
Generativity
and metaphor, 86
Geographically separate groups, 55-56
Getter tests, 7
Graphical user interfaces, 20, 58
desktop metaphors for, 87
test-first programming for, 16
GUIs. See Graphical user interfaces
Hardware, 133
Heart
paired programming and nature of, 70-71
"Hello, world" program, 78-79
High-bandwidth communication
effectiveness of, 143
Hill, Michael, 59, 78
Hosting meetings
and XP managers, 134
Hunt, Andy, 30
"Ideal weeks"
and story points, 102
Identity metaphor, 92, 93
Implementation view, 75
Incremental programming, 3
Information objects metaphor, 92
Integration, xxiii, 47, 60, 130, 133, 144
continuous, 53
daily builds, 52-53
just before delivery, 52
Interfaces
one-button, 79, 80
See also Graphical user interfaces