Extreme Programming Explained: Embrace Change / Edition 1

Extreme Programming Explained: Embrace Change / Edition 1

4.0 4
by Kent Beck
     
 

ISBN-10: 0201616416

ISBN-13: 9780201616415

Pub. Date: 10/08/1999

Publisher: Pearson Education

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

Overview

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.



Product Details

ISBN-13:
9780201616415
Publisher:
Pearson Education
Publication date:
10/08/1999
Series:
XP Series
Edition description:
Older Edition
Pages:
224
Product dimensions:
7.40(w) x 9.12(h) x 0.45(d)

Table of Contents

Foreword by Erich Gamma.
Preface.

I. THE PROBLEM.

1. Risk: The Basic Problem.
Our Mission.

2. A Development Episode.
3. Economics of Software Development.
Options.
Example.

4. Four Variables.
Interactions Between the Variables.
Focus on Scope.

5. Cost of Change.
6. Learning to Drive.
7. Four Values.
Communication.
Simplicity.
Feedback.
Courage.
The Values in Practice.

8. Basic Principles.
9. Back to Basics.
Coding.
Testing.
Listening.
Designing.
Conclusion.

II. THE SOLUTION.


10. Quick Overview.
The Planning Game.
Small Releases.
Metaphor.
Simple Design.
Tesing.
Refactoring.
Pair Programming.
Collective Ownership.
Continuous Integration.
40-Hour Week.
On-Site Customer.
Coding Standards.

11. How Could This Work?
The Planning Game.
Short Releases.
Metaphor.
Simple Design.
Testing.
Refactoring.
Pair Programming.
Collective Integration.
Continuous Integration.
40-Hour Week.
On-Site Customer.

Coding Standards. Conclusion.
12. Management Strategy.
Metrics.
Coaching.
Tracking.
Intervention.
13. Facilities Strategy.
14. Splitting Business and Technical Responsibility.
Business.
Development.
What to Do?
Choice of Technology.
What If It Is Hard?
15. Planning Strategy.
The Planning Game.
Planning in a Week.
16. Development Strategy.
Continuous Integration.
Collective Ownership.
Pair Programming.
17. Design Strategy.
The Simplest Thing that Could Possibly Work.
How Does Designing Through Refactoring Work?
What Is Simplest?
How Could This Work?
Role of Pictures in Design.
System Architecture.
18. Testing Strategy.
Who Writes Tests?
Other Tests.
19. Adopting XP.
20. Retrofitting.
Testing.
Design.
Planning.
Management.
Development.
In Trouble?
21. Lifecycle of an Ideal XP Project.
Exploration.
Planning.
Iterations to First Release.
Productionizing.
Maintenance.
Death.
22. Roles for People.
Programmer.
Customer.
Tester.
Tracker.
Coach.
Consultant.
Big Boss.
23. 20-80 Rule.
24. What Makes XP Hard.
25. When to Try XP.
26. XP at Work.
Fixed Price.
Outsourcing.
Insourcing.
Time and Materials.
Completion Bonus.
Early Termination.
Frameworks.
Shrinkwrap Products.
27. Conclusion.
Expectation.
Annotated Bibliography.
Glossary.
Index.


Customer Reviews

Average Review:

Write a Review

and post it to your social network

     

Most Helpful Customer Reviews

See all customer reviews >

Extreme Programming Explained: Embrace Change 4 out of 5 based on 0 ratings. 4 reviews.
Guest More than 1 year ago
If you are expecting something new, don't pick up this book! It's fundamentally a re-hash of the same old stuff from a SLIGHTLY different perspective. Even the title is a misnomer. There is nothing extreme about the methodology described in this book. In fact, if you've got any programming experience at all you'll find the book a little boring. I found two compelling drawbacks work mentioning. First, the author spends a great deal of time telling the reader that coding should be the central focus of the entire development process but spends most of the book talking about things such as team structure, software economics, project management, work ergonomics, etc.. Second, the author spends a lot of time talking in generalities leaving the reader stranded for details that never surface. Personally, I felt the book is not for the serious programming professional searching for in-depth coverage.
Guest More than 1 year ago
This book is undoubtedly a classic. One of the neatly ordered book I have read in a while. It presents to a novice planner on becoming more productive. However, if you are a novice who has just stepped into the world of programming...then maybe this is not the right time for you to read this book. Maybe after 2 years, once you are comfortable in makind informed sensible decisions, this book becomes a MUST READ. Any manager, senior developer or anybody who leads a bunch of programmers...yes...a MUST READ. As much as this book advises on what to do and what not to do for XP....towards the end, it gets a bit too cautious. The author tends to playing it safe by telling that XP is not for everyone. Though, I admit to the fact that he is not trying to say anywhere that XP is THE WAY...but he does not reinforce that XP is a nice way very often. The book contains many words of wisdom...and as you read through it gives you the opportunity to review yourself as a programmer. The book describes programmer attitudes and smart people working in a team following XP. While the author tells what a good programmer practicing XP should do, he also points out to the plain facts...as to what programmers in the initial stages of XP do... Though not directly related to code, the author describes a few practices while developing code, that can be followed even when one is not coding 'XP-STYLE' This book is certainly a classic....but as a word of caution...do not read the whole book if you have just begun to program. The wait is really worth the philosophy the book preaches.
Guest More than 1 year ago
My goal upon buying this book was to gather a good 'solid' overview of what XP is and some back round regarding this methadology. This goal was accomplished. However, this 166pg book could be a narrow 30. My suggestion is to skim the book in a book store for about 30 minutes.
Guest More than 1 year ago
Great book. I have done each of the 12 practices in the past, but not all at the same time. Some (like pair programming) are especially controversial. Some people say 'nothing new here', but that's often because they didn't realize that this book says you should ALWAYS pair program, and ALWAYS write an automated test for a piece of functionality BEFORE you write it, and that you should do NO design before you start coding. Yes, it's radical. Yes, it's scary. And yes, it actually can work.