- Paperback: 288 pages
- Publisher: Addison-Wesley Professional; 1 edition (October 26, 2000)
- Language: English
- ISBN-10: 0201708426
- ISBN-13: 978-0201708424
- Product Dimensions: 7.2 x 0.7 x 9.1 inches
- Shipping Weight: 12.8 ounces (View shipping rates and policies)
- Average Customer Review: 32 customer reviews
- Amazon Best Sellers Rank: #967,916 in Books (See Top 100 in Books)
Enter your mobile number or email address below and we'll send you a link to download the free Kindle App. Then you can start reading Kindle books on your smartphone, tablet, or computer - no Kindle device required.
To get the free app, enter your mobile phone number.
Extreme Programming Installed 1st Edition
Use the Amazon App to scan ISBNs and compare prices.
"Rebound" by Kwame Alexander
Don't miss best-selling author Kwame Alexander's "Rebound," a new companion novel to his Newbery Award-winner, "The Crossover,"" illustrated with striking graphic novel panels. Pre-order today
Frequently bought together
Customers who bought this item also bought
Customers who viewed this item also viewed
From the Inside Flap
Preface How much would you pay for a software development team that would do what you want? Wait, don't answer yet--what if they could also tell you how much it would cost, so that you could decide what to do and what to defer, on your way to your deadline? You also get quality software, a robust array of tests that support the project through its entire lifecycle, and an up-to-date, clear view of project status. Best of all, you get the ability to change your mind about what you want, at any time.
There aren't any silver bullets in software development, and there probably never will be. However, Extreme Programming is a simple set of common-sense practices that, when used together, really can give you much of what you just read in the paragraph above. In this book, we tell you what the XP practices are, and how to install them in your project.
We are software developers. We have been involved in many successful projects, and even in some that weren't so successful. The successful ones were a lot more fun, for us, and for our customers. The unsuccessful ones have taught us a great deal about software development.
We have had the privilege of working on a great project, with a great teacher, Kent Beck. We helped shape the software process named Extreme Programming, XP for short. Since then, we have been helping everyone who will listen to learn from our experience.
The first book in the Extreme Programming series, Extreme Programming Explained , covers the reasoning behind the XP process. Based on our experience on the original XP project (and others), this book describes what makes XP work, day to day and month to month.
Successful software development is a team effort--not just the development team but the larger team consisting of customers, management, and developers. Extreme Programming is a simple process that brings these people together and helps them to succeed together. XP is aimed primarily at object-oriented projects using teams of a dozen or fewer programmers in one location. We would use XP for both in-house development and development of shrink-wrapped software. The principles of XP apply to any moderately sized project that needs to deliver quality software rapidly and flexibly.
XP is about balancing the needs of customers with the abilities of programmers, and about steering (managing the project to success). If you're a customer, a programmer, or a manager, here's what this book offers you:
Customers--who have software that needs to be developed: you will learn simple, effective ways to communicate what you need, to be sure that you are getting what you need, and to steer the project to success. You will learn that you can change your mind and still get what you need on time.
Programmers--who, on an XP project, define the architecture, design the system, and write the tests and the code that support them: you will learn how to deliver business value quickly, how to deal with changing requirements, and how to build customer confidence and support. You will learn to build for tomorrow by building only what you need today.
Managers--who control the project resources: you will learn how to measure project progress, how to measure quality, and how to answer the all-important question, "When will you be done?" You will learn an important truth of management--to use the programmers' actual performance to predict completion.
Customers, programmers, and managers must all work together to build the system that's needed. Chapter 1, Extreme Programming, will describe the roles, rights, and responsibilities, and provide a road map for the book. Dig right in. We're sure that the XP practices can improve your projects, as they have ours.
From the Back Cover
- Software that performs required tasks and meets expectations
- Accurate estimation of time to completion and cost of development
- The opportunity to decide which features to include and which to defer
- Frequent small releases that incorporate continual customer feedback
- Constant integration and automated testing that insures clean code and robust performance
These are some of the many benefits of Extreme Programming (XP), a software development approach especially geared for smaller teams facing vague or rapidly changing requirements. Despite the "extreme" in its name, XP actually reduces risks--the risk of putting out software that is faulty, out of date at its release, over budget, or not fully capable of performing the tasks for which it was intended. Initially considered radical, XP has proven itself successful and is entering the mainstream of software development. The greatest challenge now facing software development managers and engineers is how to implement this beneficial approach.
Extreme Programming Installed explains the core principles of Extreme Programming and details each step in the XP development cycle. This book conveys the essence of the XP approach--techniques for implementation, obstacles likely to be encountered, and experience-based advice for successful execution.You will learn the best approaches to
- Working with an on-site customer
- Defining requirements with user "stories"
- Estimating the time and cost of each story
- Delivering small, frequent releases
- Performing constant integration and frequent iterations
- Running design sessions to help programmers move forward with confidence
- xUnit automated testing
- Handling defects in the fast-paced, team-oriented XP environment
- How to refine estimates and steer the development effort through frequent changes
The authors present the personal reflections of those who have been through the eXtreme Programming experience. Readers will benefit from first hand accounts of hard-won wisdom on topics such as the art of estimation, managing development infrastructure, solving problems without finger-pointing, the importance of simplicity, and how to introduce modern development tools into an environment where none existed.
Author interviews, book reviews, editors picks, and more. Read it now
Top customer reviews
There was a problem filtering reviews right now. Please try again later.
The book does not exactly teach you how to do XP. Mostly, it gives you a meandering, blurry outline of XP, throws in an inadequate number of facts and tasks, and fills in the rest with a folksy, down home chattiness about how to approach software engineering. This chattiness can be entertaining at times, but more often it ranges from silly to grating. It gets particularly grating when you realize that you are spending your time reading someone's idea of humor/advice instead of real facts on how to do XP. It starts to bug you after awhile that these people tell you to strive for simplicity and "saying what you mean" in your code, but fail to do the same thing in their book.
Some key facts that are either vague or missing in this book are: what is the relationship between the "points" for tasks in iterations versus the "points" for stories in releases? Is a point really a week or not? How many iterations should one fit into a release (they say about 2-3, but this really needs more discussion)? Acceptance tests, acknowledged by the authors to be a crucial part of XP, get almost no attention or description at all. There is no brief outline that shows how an XP project should run, from beginning to end.
The annoying prose really comes to a head when talking about the aforementioned "points" system, which seems to be the heart of XP planning and estimation. Not only are the authors unclear about "points" in the way I mentioned above, but just look at the place where they introduce the concept:
"We'll estimate story difficulty, using a simple point system. Local naming rules for these points apply. Some teams call them perfect engineering weeks . . . Some projects call them Gummi Bears. No, really . . . Ron's favorite name, this week, is just to call them points. You'll see in a bit that we recommend doing initial estimates by thinking in terms of time. Pass over that for now . . . "
Here we get all the shortcomings of the book wrapped up into one: lack of clarity, a cavalier attitude toward important concepts, and annoying humor. How are we supposed to sell the customer or manager on a controversial new methodology, when the key book describing the methodology casually tells you that you can measure the most important metric of the process with "Gummi Bears", if you'd like? Rest assured that despite what the authors say above, the book never really goes on to elucidate the relationship between points and time. Or, maybe it does, but I lost it in the midst of all the meandering, jokes, and folksy phrases.
Finally, there are a couple of chapters that just do not bear reading: Chapter 7, "Small Releases," is full of a lot of obvious common sense; and Chapter 14, "Test First, by Intention" - what should be a crucial illustration of unit testing - is unreadable to anyone who doesn't know Smalltalk, despite the authors' reassurances to the contrary.
XP is a great methodology, but this is not a great XP book. It could easily have been half as long and twice as informative. I guess I need to look elsewhere in the rapidly growing XP book "franchise" for a clear, no-BS illustration of the process.
The only disadvantage is that all the useful examples in these book contain code in SmallTalk, while C++ and Java are popular nowadays. SmallTalk has a distinct, unique style and may frighten C++ or Java developers. That's why I've rated the book four stars.
I would recommend this book to any XP'er.
XP advocates unit testing and code review. Okay, what's so extreme about that? Unit tests are fundamental to the process. Tests are frequently written before the code to be tested. There should be a test for anything that could possibly break. Tests are run frequently and must run at 100% before integrating code. Note that refactoring (see Martin Fowler's "Refactoring") is an XP practice and is sensible only where there is an extensive collection of tests. Code review takes the form of pair programming. That is, two programmers sitting side-by-side, one driving and the other paying close attention to the task at hand. So, it's continuous code review.
Some of the other practices are simple design, coding standard, continuous integration, small releases and forty-hour week. All of the practices are directed toward simple, quality code with the highest business value (as determined by the customer) written against milestone deadlines that become increasingly accurately gauged.
I highly recommend this book. I would expect other experienced programmers to react as I do that XP makes good sense. It may be difficult to sell, but it is worth the effort.