Extreme Programming Explained: Embrace Change

Extreme Programming Explained: Embrace Change

Extreme Programming Explained: Embrace Change

Extreme Programming Explained: Embrace Change

eBook

$26.99  $35.99 Save 25% Current price is $26.99, Original price is $35.99. You Save 25%.

Available on Compatible NOOK Devices and the free NOOK Apps.
WANT A NOOK?  Explore Now

Related collections and offers


Overview

Accountability. Transparency. Responsibility. These are not words that are often applied to software development.

In this completely revised introduction to Extreme Programming (XP), Kent Beck describes how to improve your software development by integrating these highly desirable concepts into your daily development process.

The first edition of Extreme Programming Explained is a classic. It won awards for its then-radical ideas for improving small-team development, such as having developers write automated tests for their own code and having the whole team plan weekly. Much has changed in five years. This completely rewritten second edition expands the scope of XP to teams of any size by suggesting a program of continuous improvement based on:

  • Five core values consistent with excellence in software development
  • Eleven principles for putting those values into action
  • Thirteen primary and eleven corollary practices to help you push development past its current business and technical limitations

Whether you have a small team that is already closely aligned with your customers or a large team in a gigantic or multinational organization, you will find in these pages a wealth of ideas to challenge, inspire, and encourage you and your team members to substantially improve your software development.

You will discover how to:

  • Involve the whole team–XP style
  • Increase technical collaboration through pair programming and continuous integration
  • Reduce defects through developer testing
  • Align business and technical decisions through weekly and quarterly planning
  • Improve teamwork by setting up an informative, shared workspace

You will also find many other concrete ideas for improvement, all based on a philosophy that emphasizes simultaneously increasing the humanity and effectiveness of software development.

Every team can improve. Every team can begin improving today. Improvement is possible–beyond what we can currently imagine. Extreme Programming Explained, Second Edition, offers ideas to fuel your improvement for years to come.




Product Details

ISBN-13: 9780134051994
Publisher: Pearson Education
Publication date: 11/17/2004
Series: XP Series
Sold by: Barnes & Noble
Format: eBook
Pages: 224
Sales rank: 973,818
File size: 2 MB

About the Author

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.

Cynthia Andres holds a B.S. in psychology with advanced work in organizational behavior, decision analysis, and women’s studies. She has worked with Kent on the social aspects of Extreme Programming since its inception. She is also affiliated with Three Rivers Institute.



0

Read an Excerpt

The goal of Extreme Programming (XP) is outstanding software development. Software can be developed at lower cost, with fewer defects, with higher productivity, and with much higher return on investment. The same teams that are struggling today can achieve these results by careful attention to and refinement of how they work, by pushing ordinary development practices to the extreme.

There are better ways and worse ways to develop software. Good teams are more alike than they are different. No matter how good or bad your team you can always improve. I intend this book as a resource for you as you try to improve.

This book is my personal take on what it is that good software development teams have in common. I’ve taken things I’ve done that have worked well and things I’ve seen done that worked well and distilled them to what I think is their purest, most “extreme” form. What I’m most struck with in this process is the limitations of my own imagination in this effort. Practices that seemed impossibly extreme five years ago, when the first edition of this book was published, are now common. Five years from now the practices in this book will probably seem conservative.

If I only talked about what good teams do I would be missing the point. There are legitimate differences between outstanding teams’ actions based on the context in which they work. Looking below the surface, where their activities become ripples in the river hinting at shapes below, there is an intellectual and intuitive substrate to software development excellence that I have also tried to distill and document.

Critics of the first edition have complained that it tries to force them to program in a certain way. Aside from the absurdity of me being able to control anyone else’s behavior, I’m embarrassed to say that was my intention. Relinquishing the illusion of control of other people’s behavior and acknowledging each individual’s responsibility for his or her own choices, in this edition I have tried to rephrase my message in a positive, inclusive way. I present proven practices you can add to your bag of tricks.

  • No matter the circumstance you can always improve.
  • You can always start improving with yourself.
  • You can always start improving today.

Table of Contents

  • I. EXPLORING XP.
  • 2. Learning to Drive.
  • 3. Values, Principles, and Practices.
  • 4. Values.
  • 5. Principles.
  • 6. Practices.
  • 7. Primary Practices.
  • 8. Getting Started.
  • 9. Corollary Practices.
  • 10. The Whole XP Team.
  • 11. The Theory of Constraints.
  • 12. Planning: Managing Scope.
  • 13. Testing: Early, Often, and Automated.
  • 14. Designing: The Value of Time.
  • 15. Scaling XP.
  • 16. Interview.
  • 17. Creation Story.
  • 18. Taylorism and Software.
  • 19. Toyota Production System.
  • 20. Applying XP.
  • 21. Purity
  • 22. Offshore Development.
  • 23. The Timeless Way of Programming.
  • 24. Community and XP.
  • 25. Conclusion.
  • Annotated Bibliography.
  • Index.

Preface

PREFACE:

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.

To some folks, XP seems like just good common sense. So why the iextremei in the name? XP takes commonsense principles and practices to extreme levels.

  • If code reviews are good, weill review code all the time (pair programming).
  • If testing is good, everybody will test all the time (unit testing), even the customers (functional testing).
  • If design is good, weill make it part of everybodyis daily business (refactoring).
  • If simplicity is good, weill always leave the system with the simplest design that supports its current functionality (the simplest thing that could possibly work).
  • If architecture is important, everybody will work defining and refining the architecture all the time (metaphor).
  • If integration testing is important, then weill integrate and test several times a day (continuous integration).
  • If short iterations are good, weill make the iterations really, really shortoseconds and minutes and hours, not weeks and months and years (the Planning Game).

When I first articulated XP, I had the mental image of knobs on a control board. Each knob was a practice that from experience I knew worked well. I would turn all the knobs up to 10 and see what happened. I was a little surprised to find that the whole package of practices was stable, predictable, and flexible.

XP makes two sets of promises.

  • G To programmers,XPpromises that they will be able to work on things that really matter, every day. They wonit have to face scary situations alone. They will be able to do everything in their power to make their system successful. They will make decisions that they can make best, and they wonit make decisions they they arenit best qualified to make.
  • G To customers and managers, XP promises that they will get the most possible value out of every programming week. Every few weeks they will be able to see concrete progress on goals they care about. They will be able to change the direction of the project in the middle of development without incurring exorbitant costs.

In short, XP promises to reduce project risk, improve responsiveness to business changes, improve productivity throughout the life of a system, and add fun to building software in teamsoall at the same time. Really. Quit laughing. Now youill have to read the rest of the book to see if Iim crazy.

This Book

This book talks about the thinking behind XPoits 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 isnit a book about precisely how to do Extreme Programming. You wonit 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 next stage of acceptance of XP is now in the hands of a group of people (you may be one) who are dissatisfied with software development as it is currently practiced. You want a better way to develop software, you want better relationships with your customers, you want happier, more stable, more productive programmers. In short, you are looking for big rewards, and you arenit afraid to try new ideas to get them. But if you are going to take a risk, you want to be convinced that you arenit just being stupid.

XP tells you to do things differently. Sometimes XPis 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 right 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 donit get to choose whether or not you will write testsoif you donit, you arenit extreme: end of discussion.

XP is designed to work with projects that can be built by teams of two to ten programmers, that arenit 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 conservativeoall 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, iHow would you program if you had enough time?i Now, you canit have extra time, because this is business after all, and we are certainly playing to win. But if you 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 imentality of sufficiencyi 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 conclude by examing the implications of what we have createdohow it can be adopted, when it shouldnit be adopted, and what opportunities it creates for business.

The book is divided into three sections.

  • The ProblemoThe chapters from iRisk: The Basic Problemi to iBack to Basicsi 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 SolutionoThe chapters from iQuick Overviewi to iTesting Strategyi 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 XPoThe chapters from iAdopting XPi to ixP at Worki describe a variety of topics around implementing XPohow 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 spent 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 hadnit 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 Daedalos Consulting for supporting the writing of this book. Champion reviewer honors go to Paul Chisolm for his copious, thoughtful, and often downright annoying comments. This book wouldnit 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 canit 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 K^nig, Dirk Krampe, Patrick Lisser, Elisabeth Maier, Thomas Mancini, Alexio Moreno, Rolf Pfenninger, and Matthias Ressel.



From the B&N Reads Blog

Customer Reviews