- Take an Extra 30% Off Any Book: Use promo code HOLIDAY30 at checkout to get an extra 30% off any book for a limited time. Excludes Kindle eBooks and Audible Audiobooks. Restrictions apply. Learn more
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 email address or mobile phone number.
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
This is a book about planning software projects. We are writing it mostly for project managers--those who have to plan and track the correspondence of the planning with reality. We also are writing it for programmers and customers, who have a vital role to play in planning and developing software. Planning is not about predicting the future. When you make a plan for developing a piece of software, development is not going to go like that. Not ever. Your customers wouldn't even be happy if it did, because by the time the software gets there, the customers don't want what was planned; they want something different.
Like so many, we enjoy Eisenhower's quotation: "In preparing for battle I have always found that plans are useless, but planning is indispensable." That's why this isn't a book about plans; it's about planning. And planning is so valuable and important, so vital, that it deserves to go on a little every day, as long as development lasts.
If you follow the advice in this book, you are going to have a new problem to solve every day--planning--but we won't apologize for that, because without planning, software development inevitably goes off the rails. The scope of this book is deliberately narrow. It covers how to plan and track software development for XP projects. It's based on our experience as consultants and coaches, together with the experience of the growing band of early adopters who are using XP.
As a result this isn't a book about the whole of project management. We don't cover typical project manager jobs such as personnel evaluation, recruiting, and budgeting. We don't address the issues of large projects with hordes of developers, nor do we say anything about planning in the context of other software processes, or of planning other activities. We think there are principles and techniques here that everyone can use, but we have stuck to the parts of the process we know--getting everybody on the team pointed in one direction, discovering when this is no longer true, and restoring harmony.
XP (Extreme Programming) is a system of practices (you can use the m-word if you want to; we'd rather not, thank you) that a community of software developers is evolving to address the problems of quickly delivering quality software, and then evolving it to meet changing business needs.
XP isn't just about planning. It covers all aspects of small team software development--design, testing, implementation, deployment, and maintenance. However, planning is a key piece of the XP puzzle. (For an overview of XP, read Extreme Programming Explained: Embrace Change. While you're at it, buy copies of all of the rest of our books, too.)
XP addresses long projects by breaking them into a sequence of self-contained, one- to three-week mini-projects. During each iteration
Customers pick the features to be added. Programmers add the features so they are completely ready to be deployed. Programmers and customers write and maintain automated tests to demonstrate the presence of these features. Programmers evolve the design of the system to gracefully support all the features in the system.
Without careful planning, the process falls apart.
The team must choose the best possible features to implement. The team must react as positively as possible to the inevitable setbacks. Team members must not overcommit, or they will slow down. The team must not undercommit, or customers won't get value for their money. Team members must figure out clearly where they are and report this accurately, so that everyone can adjust their plans accordingly
The job of the daily planner is to help keep the team on track in all these areas.
We come by our project planning ideas by necessity. As consultants, we are usually introduced to projects when they are mostly dead. The projects typically aren't doing any planning, or they are drowning in too much planning of the wrong sort.
The resulting ideas are the simplest planning ideas we could think of that could possibly work. But above all, remember all the planning techniques in the world, including these, can't save you if you forget that software is built by human beings. In the end keep the human beings focused, happy, and motiviated and they will deliver. Kent Beck, Merlin, Oregon
Martin Fowler, Melrose, Massachusetts martinfowler
I have a cunning plan.
A friend gave me this book to get me introduced to agile and extreme programming. What I really love about the book is how it's lesson apply across many different types of... Read morePublished on September 13, 2013 by -
Using a very objective and simple approach, the book presents the xp way of planning in a very easy and enjoyable way. Read morePublished on May 11, 2007 by Fabio Lessa
Well, I had been tentative about spending time investigating the meaning of "Extreme Programming", based primarily on what I consider to be a name that smacks of jargon, and... Read morePublished on July 10, 2006 by Andy King
Kent Beck and Martin Fowler have to be something of a "dream team" for a computer book. Not only was this book informative and interesting, but I actually enjoyed reading... Read morePublished on September 7, 2003 by Frank Carver
This book lays out the point of planning, the approach taken, and the steps to do.
This book has a lot of content not found in any other XP book that I own. Read more
If you are a clever developer, and if you take yourself and software development very seriously, then this is not the book for you. Read morePublished on December 9, 2002 by Wilfred Springer
Didnt I just read all of this in some of the other books in the series?
Extreme Programming Installed is the best of the lot. Read more
If youve real Extreme Programming explained then this book offers very little additional information. Most of the books in this series are very similar to each other. Read morePublished on September 21, 2001 by James Frohnhofer
This was a complete waste of ....
First of all, ... for 140 pages is a ripoff, compared to the other XP books in the series which have almost double the pages. Read more