Section 1 The Problem
Chapter 1 Risk: The Basic Problem
Software development fails to deliver, and fails to deliver value. This
failure has huge economic and human impact. We need to find a new
way to develop software.
Chapter 2 A Development Episode
Day-to-day programming proceeds from a task clearly connected to a
feature the customer wants, to tests, to implementation, to design, and
through to integration. A little of each of the activities of software
development are packed into each episode.
Chapter 3 Economics of Software Development
We need to make our software development economically more valuable
by spending money more slowly, earning revenue more quickly, and
increasing the probable productive lifespan of our project. But most of
all we need to increase the options for business decisions.
Chapter 4 Four Variables
We will control four variables in our projects---cost, time, quality, and
scope. Of these, scope provides us the most valuable form of control.
Chapter 5 Cost of Change
Under certain circumstances, the exponential rise in the cost of changing
software over time can be fiattened. If we can fiatten the curve, old
assumptions about the best way to develop software no longer hold.
Chapter 6 Learning to Drive
We need to control the development of software by making many small
adjustments, not by making a few large adjustments, kind of like driving
a car. This means that we will need the feedback to know when we are a
little off, we will need many opportunities to make corrections, and we will
have to be able to make those corrections at a reasonable cost.
Chapter 7 Four Values
We will be successful when we have a style that celebrates a consistent set of
values that serve both human and commercial needs: communication,
simplicity, feedback, and courage.
Chapter 8 Basic Principles
From the four values we derive a dozen or so basic principles to guide our
new style. We will check proposed development practices to see how they
measure up to these principles.
Chapter 9 Back to Basics
We want to do everything we must do to have stable, predictable software
development. But we don't have time for anything extra. The four basic
activities of development are coding, testing, listening, and designing.
Section 2 The Solution
Chapter 10 Quick Overview
We will rely on the synergies between simple practices, practices that often
were abandoned decades ago as impractical or naive.
Chapter 11 How Could This Work ?
The practices support each other. The weakness of one is covered by the
strengths of others.
Chapter 12 Management Strategy
We will manage the overall project using business basics--phased delivery,
quick and concrete feedback, clear articulation of the business needs of the
system, and specialists for special tasks.
Chapter 13 Facilities Strategy
We will create an open workspace for our team, with small private spaces
around the periphery and a common programming area in the middle.
Chapter 14 Splitting Business and Technical Responsibility
One key to our strategy is to keep technical people focused on technical
problems and business people focused on business problems. The project
must be driven by business decisions, but the business decisions must be
informed by technical decisions about cost and risk.
Chapter 15 Planning Strategy
We will plan by quickly making an overall plan, then refining it further
and further on shorter and shorter time horizons--years, months weeks,
days. We will make the plan quickly and cheaply, so there will be little
inertia when we must change it.
Chapter 16 Development Strategy
Unlike the management strategy, the development strategy is a radical
departure from conventional wisdom--we will carefully craB a solution
for today's problem today, and trust that we will be able to solve tomor-
row's problem tomorrow.
Chapter 17 Design Strategy
We will continually refine the design of the system, starting from a very
simple beginning. We will remove any fiexibility that doesn't prove useful.
Chapter 18 Testing Strategy
We will write tests before we code, minute by minute. We will preserve these
tests forever, and run them all together frequently. We will also derive tests
from the customer's perspective.
Section 3 Implementing XP
Chapter 19 Adopting XP
Adopt XP one practice at a time, always addressing the rnost pressing
problem for your team. Once that's no longer your most pressing problem,
go on to the next problem.
Chapter 20 Retrofitting XP
Projects that want to change their existing culture are far more common
than projects that can create a new culture from scratch. Adopt XP on
running projects a little at a time, starting with testing or planning.
Chapter 21 Lifecycle of an Ideal XP Project
The ideal XP project goes through a short initial development phase,
followed by years of simultaneous production support and refinement,
and finally graceful retirement when the project no longer makes sense.
Chapter 22 Roles for People
Certain roles have to be filled for an extreme team to work-programmer,
customer, coach, tracker.
Chapter 23 20-80 Rule
The full value of XP will not come until all the practices are in place.
Many of the practices can be adopted piecemeal, but their effects will be
multiplied when they are in place together.
Chapter 24 What Makes XP Hard
Even though the individual practices can be executed by blue-collar
programmers, putting all the pieces together and keeping them together is
hard. It is primarily emotions---especially fear--that make XP hard.
Chapter 25 When You Shouldn't Try XP
The exact limits of XP aren't clear yet. But there are some absolute show-
stoppers that prevent XP from working--big teams, distrustful customers,
technology that doesn't support graceful change.
Chapter 26 XP at Work
XP can accommodate the common forms of contract, albeit with slight
modifications. Fixed price/fixed scope contracts, in particular, become
fixed price/fixed date/roughly fixed scope contracts when run with the
Planning Game.
Chapter 27 Conclusion
Annotated Bibliography
Glossary
Index
鄂公網(wǎng)安備 42010302001612號(hào) 