Planning Extreme Programming (Paperback)

~ (Author), (Author)

Editorial Reviews

Amazon.com Review

The Extreme Programming (XP) paradigm has developers doing things like programming in pairs, writing tests to verify all code, and continuously refactoring designs for improved performance. Written by two of its inventors, Planning Extreme Programming shows you how to implement XP by using a simple, effective process. This remarkably short (yet remarkably useful) title will give any XP manager or programmer a perspective on delivering software that meets the needs of customers better.

Simplicity is the watchword of the XP software process. This book is virtually devoid of traditional software-engineering jargon and design diagrams, and yet does a good job of laying the foundation of how to perform XP--which is all about working with a customer to deliver features incrementally.

The terminology in the book is commonsensical. (In the terms of XP, each iteration adds certain new features, or stories. It's up to the customer to decide what functionality is more important and will be delivered first. By never letting a working build get out of sight, the XP process virtually ensures that software will be close to what the customer wants.)

Early chapters borrow analogies from everyday experience--like planning a trip or driving a car--to set the stage for XP process planning. The book has plenty of advice for dealing with the stakeholders (customers) of a project. Because of confidentiality agreements, however, we don't get many details from the real world, although the discussion is anchored by a hypothetical project for planning the Web site of the future for travel, with some specifics.

There is plenty of advice for planning projects, based on individual and team "velocity" (a measure of productivity) and the like--practical suggestions for running daily, short status meetings (in which all of the participants stand up, to keep them short). Clearly, there's a culture that surrounds many XP teams, and this text does a good job of conveying some of this to the reader.

At fewer than 150 pages, Planning Extreme Programming is notably concise, and that's probably the whole point. Most shops today work on Internet time, which doesn't wait for extensive project analysis and design documents. In XP, you create working software from the very start. This book is an essential guide to anyone who's working in XP shops or who might be interested in what this innovative, iterative software process can offer. --Richard Dragan

Topics covered:

• Introduction to planning
• Risk management in software
• "Driving" as a metaphor for software development
• Roles for software development: business vs. technical people
• Four variables for project planning: cost, quality, time, and scope
• Predicting future programmer productivity, based on past performance
• Project scope and estimation
• The XP process: software releases, iterations, stories, collecting, and writing stories (features)
• Hints for ordering features
• Tips on planning and status meetings
• Using visual graphs to monitor project progress
• Tracking and fixing bugs
• Project red flags

Product Description

Focuses on the time and cost for developing each user story and determining its priority, and planning software releases accordingly. Covers such topics as outsourcing, making changes to the team, dealing with bugs, and working with business contracts. Softcover. DLC: Computer software--Development.

See all Editorial Reviews

Product Details

• Paperback: 160 pages
• Publisher: Addison-Wesley Professional (October 26, 2000)
• Language: English
• ISBN-10: 0201710919
• ISBN-13: 978-0201710915
• Product Dimensions: 9.1 x 7.2 x 0.5 inches
• Shipping Weight: 12 ounces (View shipping rates and policies)
• Average Customer Review: 4.0 out of 5 stars  See all reviews (26 customer reviews)
• Amazon.com Sales Rank: #395,192 in Books (See Bestsellers in Books)

Customer Reviews

Most Helpful Customer Reviews

31 of 32 people found the following review helpful:

5.0 out of 5 stars How to make things work by making them small, December 4, 2000

By	Charles Ashbacher "([e-mail])" (Marion, Iowa United States([e-mail])) - See all my reviews (TOP 50 REVIEWER)

Skepticism about new techniques is a natural state for programmers and those who manage them. Hype amid the desperate search for effective strategies is one of the many factors contributing to the poor rate of success in the business. Extreme programming, where development is broken up into a series of microcycles performed by small teams, is an apparent step backwards in the evolution of the planning of software projects. I was initially very skeptical about it, for the primary reason that not all things can be broken up into executable cycles of approximately two weeks in length.
However, this book, packed with some of the most sensible advice you can find, sold me on the concept, if not the implementation. The approach is an admirable one, let the customer decide. If the project and customers are worth having, then there will be more features than can be implemented in the allotted time. Since slipping the release date is NOT considered an option, it is the responsibility of the customer to choose what is to be delayed or eliminated. A synergy between developers, marketers, and customers where all work together and know where they stand is certainly a desirable goal. The reason for my skepticism is that in my experience, the customers are not as cognizant of their priorities as those ideals used in the book. However, the advice given here will help you approach this ideal state of affairs.
The tactic is to refer to all features and descriptions as stories. I am generally not one who is fond of someone taking semantic license in describing circumstances. However, in this case, it does fit. The description of software is very much like a story in that your ideal is a fiction that may never be achieved. Since you are not sure exactly what you have created, the documentation is somewhat exaggerated and the end result is unknown until it happens.
In a brilliant use of terminology, the authors use ideal time in planning rather than real time, and this is something that all programmers will enthusiastically applaud. Ideal time is that amount of time actually spent in working on the project as opposed to that spent in distractions. When it comes time for projecting completion dates, the developers then use ideal time rather than the false alternative. This is the most sensible strategy that could ever be used and if any one idea in this book is adopted, this should be it.
Another simple and very effective strategy is the yesterday's weather approach to predicting future performance. The analogy is simple. Enormous amounts of money can be spent on hardware and sophisticated computer models in an attempt to predict what the weather will be like tomorrow. However, you can be almost as accurate if you simply say that it will be much like today. Taking the same approach to development, you can say that the rate of development achieved by each programmer on the next project will be very similar to what they did on the last project. You may not be exactly right, but the time saved in avoiding complex analysis will most likely make up any shortfall.
The authors present a situation that has many utopian features. However, while utopian conditions may not be possible, they do give us targets to shoot for and any step closer to it will make things easier. Since the strategies used to bring about the ideal conditions are described, this is one book that should be the focal point of a lengthy meeting. Any agreement to implement any part of the plan will pay enormous dividends.

58 of 64 people found the following review helpful:

4.0 out of 5 stars Essential, If a Tad Narrow, December 25, 2000

By	R. Williams "code slubber" (Los Angeles, CA United States) - See all my reviews (REAL NAME)

The many other reviews here give you a sense of what you'll find in this book. I think there is one important point that is missing from this picture: the fact that the focus of the authors in this and the first book is on software processes where there really is no visioning going on at all. What do I mean by that? Well, in the first book they are describing the writing of a payroll program (their project @ Chrysler). In this book it's a travel application. Thankfully, not all of us are writing software that has been written a thousand times before. While this may sound like a trifle, I believe it is a central point with regard to this book. The whole concept of iterative, incremental development takes on a different hue when you remove visioning from the process. In fact, what the world really needs to figure out how to do is not write the 10,000th payroll program faster than someone else, but how to write new, innovative software on time allowances that are absurdly short. I think the next volume if there is to be one, should be a detailed account of a project where the team had to navigate the process through not only implementation but realization of an evolving, sophisticated vision. Finally, consider the fact that software development that requires no visioning is basically a craft that's akin to dressmaking. While some people are happy to see their creativity as 'developers' manifest solely in finding crafty implementations, let's face the facts: we need to figure out how to get beyond just opposing tribes matching each other's features on models that are overdue for commodification.

20 of 21 people found the following review helpful:

4.0 out of 5 stars How exactly to plan XP?, January 6, 2003

By	Maxim Masiutin (Chisinau, Republic of Moldova) - See all my reviews (REAL NAME)

Amazon Verified Purchase

This book is very valuable if you already started to practice Extreme Programming. It contains a very encouraging foreword by Tom DeMarco. The first nine chapters are introductory, and you may skip them if you read the XP Manifesto "Extreme Programming Explained" by Kent Beck. Chapters from ten to twenty three contain valuable information not found in any other XP-related book.

- How exactly to plan releases? What if frequent releases aren't appropriate and marketing demands to release once a year?

- How exactly to write user stories, and how to handle them? Although the reader may find some sample stories in "Extreme Programming Installed" by Ron Jeffries, Ann Anderson and Chet Hendrickson, the stories in the "Planning Extreme Programming" are used as core elements in the whole planning process, shown as example.

- How exactly to build the iteration plan and the release plan? How to track an iteration?

I would also like to recommend "Extreme Programming Applied: Playing to Win" by Ken Auer, Roy Miller, Ward Cunningham. I think this is the most practical book on XP ever written.

I would also like to recommend the titles about individual XP aspects:
- Design Improvement: "Refactoring: Improving the Design of Existing Code " by Martin Fowler;
- Test-Driven Development: "Test Driven Development: By Example " by Kent Beck;
- Sustainable Pace: "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency" by Tom DeMarco;
- Pair Programming: "Pair Programming Illuminated" by Laurie Williams and Robert Kessler;
- Whole Team: "Agile Software Development" by Alistair Cockburn;
- Planning Game: "Planning Extreme Programming" by Kent Beck, Martin Fowler;
- Small Releases: "Software Project Survival Guide" by Steve C McConnell.