Extreme Programming Explained: Embrace Change - Softcover

Über die Autorin bzw. den Autor

Kent Beck consistently challenges software engineering dogma, promoting ideas like patterns, test-driven development, and Extreme Programming. Currently affiliated with Three Rivers Institute and Agitar Software, he is the author of many Addison-Wesley titles.

Von der hinteren Coverseite

Software development projects can be fun, productive, and even daring. Yet they can consistently deliver value to a business and remain under control.

Extreme Programming (XP) was conceived and developed to address the specific needs of software development conducted by small teams in the face of vague and changing requirements. This new lightweight methodology challenges many conventional tenets, including the long-held assumption that the cost of changing a piece of software necessarily rises dramatically over the course of time. XP recognizes that projects have to work to achieve this reduction in cost and exploit the savings once they have been earned.

Fundamentals of XP include:

• Distinguishing between the decisions to be made by business interests and those to be made by project stakeholders.
• Writing unit tests before programming and keeping all of the tests running at all times.
• Integrating and testing the whole system--several times a day.
• Producing all software in pairs, two programmers at one screen.
• Starting projects with a simple design that constantly evolves to add needed flexibility and remove unneeded complexity.
• Putting a minimal system into production quickly and growing it in whatever directions prove most valuable.

Why is XP so controversial? Some sacred cows don't make the cut in XP:

• Don't force team members to specialize and become analysts, architects, programmers, testers, and integrators--every XP programmer participates in all of these critical activities every day.
• Don't conduct complete up-front analysis and design--an XP project starts with a quick analysis of the entire system, and XP programmers continue to make analysis and design decisions throughout development.
• Develop infrastructure and frameworks as you develop your application, not up-front--delivering business value is the heartbeat that drives XP projects.
• Don't write and maintain implementation documentation--communication in XP projects occurs face-to-face, or through efficient tests and carefully written code.

You may love XP, or you may hate it, but Extreme Programming Explained will force you to take a fresh look at how you develop software.

Auszug. © Genehmigter Nachdruck. Alle Rechte vorbehalten.

Extreme Programming Explained: Embrace Change Beck, Kent This is a book about Extreme Programming (XP). XP is a lightweight methodology for small-to-medium-sized teams developing software in the face of vague or rapidly changing requirements. This book is intended to help you decide if XP is for you. This book talks about the thinking behind XP-its roots, philosophy, stories, myths. It is intended to help you make an informed decision about whether or not to use XP on your project. If you read this book and correctly decide not to use XP for your project, I will have met my goal just as much as if you correctly decide to use it. A second goal of this book is to help those of you already using XP to understand it better. This isn't a book about precisely how to do Extreme Programming. You won't read lots of checklists here, or see many examples, or lots of programming stories. For that, you will have to go online, talk to some of the coaches mentioned here, wait for the topical, how-to books to follow, or just make up your own version. 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 conclude by examining the implications of what we have created-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 criteria for evaluating 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. ForewordPrefaceSection 1 The ProblemChapter 1 Risk: The Basic ProblemOur MissionChapter 2 A Development EpisodeChapter 3 Economics of Software DevelopmentOptionsExampleChapter 4 Four VariablesInteractions Between the VariablesFocus on ScopeChapter 5 Cost of ChangeChapter 6 Learning to DriveChapter 7 Four ValuesCommunicationSimplicityFeedbackCourageThe Values in PracticeChapter 8 Basic PrinciplesChapter 9 Back to BasicsCodingTestingListeningDesigningConclusionSection 2 The SolutionChapter 10 Quick OverviewThe Planning GameSmall ReleasesMetaphorSimple DesignTestingRefactoringPair ProgrammingCollective OwnershipContinuous Integration40-Hour WeekOn-Site CustomerCoding StandardsChapter 11 How Could This Work?The Planning GameShort ReleasesMetaphorSimple DesignTestingRefactoringPair ProgrammingCollective OwnershipContinuous Integration40-Hour WeekOn-Site CustomerCoding StandardsConclusionChapter 12 Management StrategyMetricsCoachingTrackingInterventionChapter 13 Facilities StrategyChapter 14 Splitting Business and Technical ResponsibilityBusinessDevelopmentWhat to Do?Choice of TechnologyWhat If It's Hard?Chapter 15 Planning StrategyThe Planning GameIteration PlanningPlanning in a WeekChapter 16 Development StrategyContinuous IntegrationCollective OwnershipPair ProgrammingChapter 17 Design StrategyThe Simplest Thing that Could Possibly WorkHow Does "Designing Through Refactoring" Work?What Is Simplest?How Could This Work?Role of Pictures in DesignSystem ArchitectureChapter 18 Testing StrategyWho Writes Tests?Other TestsSection 3 Implementing XPChapter 19 Adopting XPChapter 20 Retrofitting XPTestingDesignPlanningManagementDevelopmentIn Trouble?Chapter 21 Lifecycle of an Ideal XP ProjectExplorationPlanningIterations to First ReleaseProductionizingMaintenanceDeathChapter 22 Roles for PeopleProgrammerCustomerTesterTrackerCoachConsultantBig BossChapter 23 20-80 RuleChapter 24 What Makes XP HardChapter 25 When to Try XPChapter 26 XP at WorkFixed PriceOutsourcingInsourcingTime and MaterialsCompletion BonusEarly TerminationFrameworksShrinkwrap ProductsChapter 27 ConclusionExpectationAnnotated BibliographyGlossaryIndex Kent Beck owns and operates First Class Software, Inc., where he focuses on his two greatest interests, patterns and Extreme Programming. He has helped pioneer patterns for software development, CRC cards, the HotDraw drawing editor framework, the xUnit unit testing framework, and the rediscovery of test-first programming. He is the author of more than 50 articles on programming and the books The Smalltalk Best Practice Patterns.