Planning Extreme Programming

However skeptical the ads make you, it's hard to deny that what used to be considered supercomputing power keeps showing up in consumer-priced boxes, and the threshold of what really is extreme has crept steadily upward. If you're planning a project of more than average size, though, the review that chromatic contributed below of Planning Extreme Programming could be a valuable read, and the ideas in the book itself could save you a lot of money and time. Even if you have no plans to desire to install a beowulf in your broomcloset, it's interesting to consider what sort of thought must go into any large-scale programming project.

Planning Extreme Programming
author	Kent Beck & Martin Fowler
pages	139
publisher	Addison-Wesley
rating	9
reviewer	chromatic
ISBN	0-210-71091-9
summary	Guidelines, anecdotes, and tested techniques to plan and track your Extreme Programming projects.

The Scoop

Last year's Extreme Programming Explained argued that all of the good activities of software engineering (planning, designing, testing, refactoring, estimating, reviewing, and releasing) ought to be done all the time. Dividing the technical and management tasks, forcing each group to work to its strengths, the technique has gathered several proponents. Until now, there's been no general presentation of the HOW of XP, suitable for management and customers.

Planning Extreme Programming covers the practice of XP, the techniques other groups have used while applying its principles. Data and anecdotes from XP practitioners contribute to this collection of lessons.

What's to Like?

The book fits the XP philosophy handily, with short, simple chapters hitting a single point apiece. This is a book suitable for busy managers (weaned on slide presentations) and customers (who don't want to learn any more about programming than necessary). Without the support of both, projects will fail. An afternoon invested reading this thin tome will pay off handsomely, whether or not you use XP.

It's hard to pin down the main emphasis in the face of the gestalt. The strongest lesson relates a simple driving anecdote. Reaching your destination requires a successful combination of small steps and course corrections. You can't just point the car at Boston and accelerate. Back out of the garage first. Ready, fire, aim aim aim aim aim.

Instead, the authors suggest breaking a project into self-contained, testable components (stories). The customer creates the stories. The programmers estimate the time it will take to complete each. The customer selects the stories for the next iteration (period of time between release dates, generally three to six weeks). The programmers write their tests, write their code, ask the customer to postpone a story instead of slipping a release date. Finally, the customer runs the test and selects the stories for the next iteration.

It's a powerful concept, and just might work. The text examines each step of the process, with a consistently simple emphasis on the big picture. Of particular note are the sections on estimates (you can do as much work as you did in the last iteration) and the role of customers. The big benefit of XP is that it minimizes risk over the long term by producing working software as soon as possible, continually revising the overall plan with fresh data.

What's to Consider?

This book really assumes readers already have some understanding of the part they play in Extreme Programming. (One might argue that there's no reason to read this book without having read Beck's first XP book.) The more open-minded in the audience may jump right in, while the cautious and practical will want proof to go with the manifesto. Invest in reading this and Extreme Programming Explained.

Related to the previous point, XP is not free of jargon itself. Readers unfamiliar with the role of 'stories' or the duties of the customer will have some difficulty with the first few chapters. A short glossary of terms and duties would alleviate this.

A criticism of Extreme Programming Explained also applies here -- there's still too little data about which projects and software types fit XP best. This book does present some criteria: projects running on Internet time, outsourced projects, and projects with medium-sized teams (six to twelve developers) are possible candidates. Only experience and more data can provide hard answers.

The Summary

More practical and less controversial than its predecessor, Planning Extreme Programming makes the XP manifesto workable. Better for people already sold on the practice, the book is also appropriate for people considering Extreme Programming, whether programmer, manager, or customer. Improve software quality and your quality of life by embracing change.

Table of Contents

1. Why Plan?
2. Fear
3. Driving Software
4. Balancing Power
5. Overviews
6. Too Much to Do
7. Four Variables
8. Yesterday's Weather
9. Scoping a Project
10. Release Planning
11. Writing Stories
12. Estimation
13. Ordering the Stories
14. Release Planning Events
15. The First Plan
16. Release Planning Variations
17. Iteration Planning
18. Iteration Planning Meeting
19. Tracking an Iteration
20. Stand-up Meetings
21. Visible Graphs
22. Dealing with Bugs
23. Changes to the Team
24. Tools
25. Business Contracts
26. Red Flags
27. Your Own Process

---

You can purchase this book at ThinkGeek.