What do you think?
Rate this book
Planning Extreme Programming
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 DraganTopics Introduction to planning Risk management in software "Driving" as a metaphor for software development Roles for software business vs. technical people Four variables for project cost, quality, time, and scope Predicting future programmer productivity, based on past performance Project scope and estimation The XP 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
Paperback
First published October 26, 2000
13 people are currently reading
627 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 20 of 20 reviews
March 6, 2014
The original manifesto for XP, this book finally codified a lot of the project management knowledge that came to me from quite a number of different sources. This is a fast book to read through and it does not waste your time with any of its material. I would recommend that every developer read this book for the shared vocabulary it offers.
That being said, some parts of the book left me dissatisfied. I think because I spent so much time in product-design oriented classes, I consider myself, fellow developers, ops people, management, and everyone interacting with the software to be stakeholders in its design.
This manifesto abdicates all responsibility for generating end-user value stories to the nebulous "customer" entity. While I agree that having the customer involved is imperative and that they should be generating the vast majority of the end-user oriented stories, I also believe that developers interests should align with the customer and that over time they should be able to generate stories with end-user value as well. The developers should work to learn the customer needs and work with the customer to generate stories that can be delivered quickly and correctly, rather than relying on a potentially non-technical customer's imagination and intuition in a constantly changing field.
That being said, some parts of the book left me dissatisfied. I think because I spent so much time in product-design oriented classes, I consider myself, fellow developers, ops people, management, and everyone interacting with the software to be stakeholders in its design.
This manifesto abdicates all responsibility for generating end-user value stories to the nebulous "customer" entity. While I agree that having the customer involved is imperative and that they should be generating the vast majority of the end-user oriented stories, I also believe that developers interests should align with the customer and that over time they should be able to generate stories with end-user value as well. The developers should work to learn the customer needs and work with the customer to generate stories that can be delivered quickly and correctly, rather than relying on a potentially non-technical customer's imagination and intuition in a constantly changing field.
January 18, 2019
If you’re doing Scrum, 99% of this book is still relevant. Despite a few bits of clangy prose, it carries buckets of earned wisdom.
May 1, 2024
it's good to re-read the bible every once in awhile
July 27, 2017
Outstanding overview of how to interact with engineers and plan in XP.
October 2, 2018
Well, there were definitely some interesting ideas but if you have read XP or Scrum books, most of it would come as new material.
February 6, 2020
Excelente y conciso resumen de cómo planificar un proyecto en forma ágil
June 15, 2020
Was written so long back, people still haven't learnt much of what was known then.
October 3, 2011
Two authors for whom I have immense respect and a foreword by Tom DeMarco. I finally got around to reading this one. I delayed because the other XP books already covered the planning game as far as I'd care. But hopefully these authors can make it interesting still.
I was pleasantly surprised that something apparently so simple as the planning game could have almost infinite subtleties. The authors have streamlined it somewhat but the original intent stays. Divide the work into manageable chunks and let technical people make the technical calls and the business people (customer) make the business calls. This is not only when to schedule stories, but when to split them and actually when they are done. Well worth the small investment in time.
Incidentally, I met Kent Beck at a local event the day after I finished reading this book, on 2004-11-17, and I got him to sign my copy.
Update: I met Martin Fowler at a local event on 2010-05-12 and I got him to sign my copy too. Two for two.
I was pleasantly surprised that something apparently so simple as the planning game could have almost infinite subtleties. The authors have streamlined it somewhat but the original intent stays. Divide the work into manageable chunks and let technical people make the technical calls and the business people (customer) make the business calls. This is not only when to schedule stories, but when to split them and actually when they are done. Well worth the small investment in time.
Incidentally, I met Kent Beck at a local event the day after I finished reading this book, on 2004-11-17, and I got him to sign my copy.
Update: I met Martin Fowler at a local event on 2010-05-12 and I got him to sign my copy too. Two for two.
August 12, 2015
The book is thought provoking and filled with easy to understand examples. Still I remain somewhat ambivalent towards it. Certainly, the point that the customer is the one who should be making decisions with regards to what should be done and in what order was strongly and reasonably made. The same is true of the idea that the source of estimation should come from the developer and be balanced by the theory of the previous days weather. I wish I could articulate what makes me conflicted with regards to the book, but I can say that it feels like an earnest and well meaning salesmen just tried to sell me and I still have just enough doubts to not go with the sale.
May 26, 2011
Well written, easy to follow book with great examples. Lots of ideas to try and hints and tips of common pain points. Have been adapting our current agile-ish process based on my readings so far, and will continue to do so to ensure we have a process that works for out team/product.
Favourite takeaway is probably:
"As the basis for your planning, assume you'll do as much this week as you did last"
which just makes sense
Favourite takeaway is probably:
"As the basis for your planning, assume you'll do as much this week as you did last"
which just makes sense
May 28, 2012
Great complement to the classic "Extreme Programming Explained", but more targeted to the XP management side of things.
Planning and managing XP projects had been already covered to some degree in Beck's previous work but this book goes into much more detail, and will probably prove useful for the aspiring manager of an XP team. Plus, it's a relatively light and easy read.
Planning and managing XP projects had been already covered to some degree in Beck's previous work but this book goes into much more detail, and will probably prove useful for the aspiring manager of an XP team. Plus, it's a relatively light and easy read.
July 28, 2007
I read this sometime ago. I was very excited about XP and still think it is a wonderful practice. I was able to work on a team for a few months where XP was used and was definitely a productive enjoyable time. It is difficult to get management interested in this.
January 23, 2008
This is a book that focuses on how to do release planning when you have instituted XP. There is little, that isn't in Extreme Programming Explained, but it is a little bit better organized and a little more focused on the Customer (i.e., the Product Manager in XP lingo) rather than the Engineer.
January 25, 2010
Provides some very practical advice if you've read "Extreme Programming Explained" and now have to put all those high-level ideas and new practices into action on a real project - I keep it very close to my desk.
April 2, 2011
First great approach to understand what's behind an agile project development.
April 22, 2011
A great book with a unique take on planning and steering software development projects.
August 23, 2011
Читал в 2004 году. В те годы XP была в диковинку и все боялись внедрять эту методику. Сейчас обычное явление.
April 8, 2015
Quick nice followup on planning techniques for Extreme Programming, in terms of estimates, scope adjustments and so forth.
January 25, 2016
Another way to see development projects, much more people oriented. It seems risky, but worth trying when traditional management tools keep failing on and on
April 29, 2017
This book was written by two very big names of modern software development. This is the recipie for a masterpiece. Somehow, it's very good, but not a masterpiece. It even coul be considered as superficial on many topics. At this point, you may call it a gentle introduction to cohn's "agile estimating and planning".
Displaying 1 - 20 of 20 reviews
Can't find what you're looking for?
Get help and learn more about the design.