Extreme programming explained : embrace change = 解析极限编程 ：拥抱变化 /

foreword

preface

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