Planning Extreme Programming (XP) [Taschenbuch]

To achieve this the authors focus away from complex, report-led planning to a people-oriented process which treats programming like a craft project. Extreme Programming starts by recognising reality: start right and you'll finish right. In fact the authors specifically argue against overtime, increasing manpower on late projects and other such attempts to increase productivity as evidence of failure. They start by breaking projects into stories (or features), insist on customer involvement, iterate relentlessly over a timescale of weeks, set short-term targets based on the evidence of previous iterations and--in a break with traditional practices--absolutely insist on customer involvement at every stage, including signing off each story.

The claimed results of applying the XP approach is a better product with fewer bugs as well as the ability to meet agreed deadlines and budgets. Pretty impressive claims for a book that reads like a set of obvious, common-sense rules. Astonishingly, the only planning tool required is a box of index cards and the right attitude. You are even recommended to avoid spreadsheets. Perhaps, then, the real success of Extreme Programming rests on its implicit acknowledgement that programming is a craft, and not engineering. What can you say? It works. Read it and then implement it. -- Steve Patient

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