解析极限编程：拥抱变化（影印版）

.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

.　　 XP tells you to do things differently. Sometimes XP's advice is absolutely contrary to accepted wisdom. Right now I expect those choosing to use XP to require compelling reasons for doing things differently, but if the reasons are there, to go fight ahead. I wrote this book to give you those reasons.
　　What Is XP?
　　 What is XP? XP is a lightweight, efficient, low-risk, flexible, predictable, scientific, and fun way to develop software. It is distinguished from other methodologies by
　　 Its early, concrete, and continuing feedback from short cycles.
　　 Its incremental planning approach, which quickly comes up with an overall plan that is expected to evolve through the life of the project.
　　 Its ability to flexibly schedule the implementation of functionality, responding to changing business needs.
　　 Its reliance on automated tests written by programmers and customers to monitor the progress of development, to allow the system to evolve, and to catch defects early.
　　 Its reliance on oral communication, tests, and source code to communicate system structure and intent.
　　 Its reliance on an evolutionary design process that lasts as long as the system lasts.
　　 Its reliance on the close collaboration of programmers with ordinary skills.
　　 Its reliance on practices that work with both the short-term instincts of programmers and the long-term interests of the project.
　　 XP is a discipline of software development. It is a discipline because there are certain things that you have to do to be doing XP. You don't get to choose whether or not you will write tests--if you don't, you aren't extreme: end of discussion.
　　 XP is designed to work with projects that can be built by teams of two to ten programmers, that aren't sharply constrained by the existing computing environment, and where a reasonable job of executing tests can be done in a fraction of a day.
　　 XP frightens or angers some people who encounter it for the first time. However, none of the ideas in XP are new. Most are as old as programming. There is a sense in which XP is conservative--all its techniques have been proven over decades (for the implementation strategy) or centuries (for the management strategy).
　　 The innovation of XP is
　　 Putting all these practices under one umbrella.
　　 Making sure they are practiced as thoroughly as possible.
　　 Making sure the practices support each other to the greatest possible degree.
　　Enough
　　 In The Forest People and The Mountain People, anthropologist Colin Turnbull paints contrasting pictures of two societies. In the mountains, resources were scarce and people were always on the brink of starvation. The culture they evolved was horrific. Mothers abandoned babies
　　to roving packs of feral children as soon as they had any chance of survival. Violence, brutality, and betrayal were the order of the day.
　　 In contrast, the forest had plenty of resources. A person had only to spend half an hour a day providing for their basic needs. The forest culture was the mirror image of the mountain culture. Adults shared in raising children, who were nurtured and loved until they were quite
　　ready to care for themselves. If one person accidentally killed another (deliberate crime was unknown), they were exiled, but they only had to go a little ways into the forest, and only for a few months, and even then the other tribespeople brought them gifts of food.
　　 XP is an experiment in answer to the question, "How would you program if you had enough time?" Now, you can't have extra time, because this is business after all, and we are certainly playing to win. But ifyou had enough time, you would write tests; you would restructure the system when you learned something; you would talk a lot with fellow programmers and with the customer.
　　 Such a "mentality of sufficiency" is humane, unlike the relentless drudgery of impossible, imposed deadlines that drives so much talent out of the business of programming. The mentality of sufficiency is also good business. It creates its own efficiencies, just as the mentality of
　　scarcity creates its own waste.
　　Outline
　　 The book is written as if you and I were creating a new software development discipline together. We start by examining our basic assumptions about software development. We then create the discipline itself. We concludc by examing the implications of what we have crcated--how it can be adopted, when it shouldn't be adopted, and what opportunities it creates for business.
　　 The book is divided into three sections.
　　 The Problem--The chapters from "Risk: The Basic Problem" to "Back to Basics" set up the problem Extreme Programming is trying to solve and present critcria for cvaluating the solution. This section will give you an idea of the overall worldview of Extreme Programming.
　　 The Solution--The chapters from "Quick Overview" to "Testing Strategy" turn the abstract ideas in the first section into the practices of a concrete methodology. This section will not tell you exactly how you can execute the practices, but rather talks about their general shape. The discussion of each practice relates it to the problems and principles introduced in the first section.
　　 Implementing XP--The chapters from "Adopting XP" to "XP at Work" describe a variety of topics around implementing XP--how to adopt it, what is expected from the various people in an
　　 extreme project, how XP looks to the business folks.
　　Acknowledgments
　　 I write in the first person here, not because these are my ideas, but rather because this is my perspective on these ideas. Most of the practices in XP are as old as programming.
　　 Ward Cunningham is my immediate source for much of what you will read here. In many ways I have spcnt the last fifteen years just trying to explain to other people what he does naturally. Thanks to Ron Jeffries for trying it, then making it much better. Thanks to Martin Fowler for explaining it in a nonthreatening way. Thanks to Erich Gamma for long talks while watching the swans in the Limmat, and for not letting me get away with sloppy thinking. And none of this would
　　have happened if I hadn't watched my dad, Doug Beck, ply his programming craft all those years.
　　 Thanks to the C3 team at Chrysler for following me up the hill, then storming past me on the way to the top. And special thanks to our managers Sue Unger and Ron Savage for the courage to give us the chance to try.
　　 Thanks to Dacdalos Consulting for supporting the writing of this book.
　　 Champion reviewer honors go' to Paul Chisholm for his copious, thoughtful, and often downright annoying comments. This book wouldn't be half of what it is without his feedback.
　　 I have really enjoyed my interactions with all my reviewers. Well, at least I have gained tremendous help from them. I can't thank them enough for wading through my 1.0 prose, some of them in a foreign language. Thanks to (listed in the random order in which I read their
　　reviews) Greg Hutchinson, Massimo Arnoldi, Dave Cleal, Sames Schuster, Don Wells, Joshua Kerievsky, Thorsten Dittmar, Moritz Becker, Daniel Gubler, Christoph Henrici, Thomas Zang, Dierk
　　Koenig, Miroslav Novak, Rodney Ryan, Frank Westphal, Paul Trunz, Steve Hayes, Kevin Bradtke, Jeanine De Guzman, Tom Kubit, Falk Bruegmann, Hasko Heinecke, Peter Merel, Rob Mee, Pete McBreen,
　　Thomas Ernst, Guido Haechler, Dieter Holz, Martin Knecht, Dierk K6nig, Dirk Krampe, Patrick Lisser, Elisabeth Maier, Thomas Mancini, Alexio Moreno, Rolf Pfenninger, and Matthias Ressel.