Planning Extreme Programming / Edition 1

Paperback (Print)
Used and New from Other Sellers
Used and New from Other Sellers
from $1.99
Usually ships in 1-2 business days
(Save 94%)
Other sellers (Paperback)
  • All (35) from $1.99   
  • New (8) from $5.54   
  • Used (27) from $1.99   

Overview

"XP is the most important movement in our field today. I predict that it will be as essential to the present generation as the S.E.I. and its Capability Maturity Model were to the last."

--From the foreword by Tom DeMarco

The hallmarks of Extreme Programming--constant integration and automated testing, frequent small releases that incorporate continual customer feedback, and a teamwork approach--make it an exceptionally flexible and effective approach to software development. Once considered radical, Extreme Programming (XP) is rapidly becoming recognized as an approach particularly well-suited to small teams facing vague or rapidly changing requirements--that is, the majority of projects in today's fast-paced software development world.

Within this context of flexibility and rapid-fire changes, planning is critical; without it, software projects can quickly fall apart. Written by acknowledged XP authorities Kent Beck and Martin Fowler, Planning Extreme Programming presents the approaches, methods, and advice you need to plan and track a successful Extreme Programming project. The key XP philosophy: Planning is not a one-time event, but a constant process of reevaluation and course-correction throughout the lifecycle of the project.

You will learn how planning is essential to controlling workload, reducing programmer stress, increasing productivity, and keeping projects on track. Planning Extreme Programming also focuses on the importance of estimating the cost and time for each user story (requirement), determining its priority, and planning software releases accordingly.

Specific topics include:

  • Planning and the four key variables: cost, quality, time, and scope
  • Deciding how many features to incorporate into a release
  • Estimating scope, time, and effort for user stories
  • Prioritizing user stories
  • Balancing the business value and technical risk of user stories
  • Rebuilding the release plan based on customer and programmer input
  • Choosing the iteration length
  • Tracking an iteration
  • What to do when you're not going to make the date
  • Dealing with bugs
  • Making changes to the team
  • Outsourcing
  • Working with business contracts

In addition, this book alerts you to the red flags that signal serious problems: customers who won't make decisions, growing defect reports, failing daily builds, and more. An entire chapter is devoted to war stories from the trenches that illustrate the real-world problems many programmers encounter and the solutions they've devised.

0201710919B04062001

Read More Show Less

Editorial Reviews

Booknews
Written for project managers, programmers, and customers, this volume discusses the principles and techniques of software project planning using the "extreme programming" (XP) system. Emphasis is placed on the idea that planning is not a one-time event but a constant process of course correction throughout the life cycle of a project. Annotation c. Book News, Inc., Portland, OR (booknews.com)
Read More Show Less

Product Details

  • ISBN-13: 9780201710915
  • Publisher: Addison-Wesley
  • Publication date: 10/16/2000
  • Series: XP Series
  • Edition description: New Edition
  • Edition number: 1
  • Pages: 160
  • Product dimensions: 7.20 (w) x 9.00 (h) x 0.40 (d)

Meet the Author

Kent Beck consistently challenges software engineering dogma, promoting ideas like patterns, test-driven development, and Extreme Programming. Currently affiliated with Three Rivers Institute and Agitar Software, he is the author of many Addison-Wesley titles.

Martin Fowler is the Chief Scientist of ThoughtWorks, an enterprise-application development and delivery company. He's been applying object-oriented techniques to enterprise software development for over a decade. He is notorious for his work on patterns, the UML, refactoring, and agile methods. Martin lives in Melrose, Massachusetts, with his wife, Cindy, and a very strange cat. His homepage is http://martinfowler.com.

Read More Show Less

Read an Excerpt

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 http://www.martinfowler.com
July 2000

I have a cunning plan.
—Baldrick, Blackadder

Read More Show Less

Table of Contents

Foreword.

Preface.

Acknowledgments.

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.

Index. 0201710919T04062001

Read More Show Less

Preface

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 http://www.martinfowler.com
July 2000

I have a cunning plan.
--Baldrick, Blackadder

0201710919P04062001

Read More Show Less

Foreword

In On War, Carl von Clausewitz tells us that military history is a pendulum swinging back and forth between the relative advantages of armor and of mobility. The knights in shining armor were able to dominate any knight without, but they were no match for the quick, nearly naked pony warriors that swept across the plains with Genghis Kahn and his Mongols. Light cavalry itself was doomed as soon as there were tanks, and tanks were no match for fleet-footed Palestinian teenagers with Sagger missiles. With the Maginot Line, the French were gambling that the pendulum had swung again toward armor, but it hadn't, and the Germans simply went around it.

In the field of IT, we are just emerging from a time in which armor (process) has been king. And now we arc moving into a time when only mobility matters. Building a product the right way still sounds like a laudable goal, but-let's face it-what really matters today is building it fast. Because we arc process-obsessed in our field, we have tended to react to this new imperative as we reacted to the imperatives thrust upon us in the 1980s and 1990s. We have asked, "What shall we add to our process to deal with this new situation?" No answer to that question is going to be right because the question itself is wrong.

What the new mobility imperative requires is that we subtract from process: We need to get light.

Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star

(0)

4 Star

(0)

3 Star

(0)

2 Star

(0)

1 Star

(0)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously
Sort by: Showing all of 4 Customer Reviews
  • Anonymous

    Posted August 11, 2006

    Outstaning Stories

    This book is very well written. It's enjoyable to read and to learn. Beck gets to the point and makes difficult concepts easier. It's one of the best books I have ever read. Unlike many other XP or agile authors, Beck has the readers' interest as his top priority. I feel that he does not use the book as a brochure to sell his consulting service like many other authors in this area do. Any agile practitioners will benefit substantially from this book which was written ahead of the time that Agile become popular. Agile and XP Programming are essentially the same thing. Just change the words ¿Sprint¿ to ¿Iteration¿ and so on. With my engineering background, I find this book based beautifully on solid engineering principles.

    Was this review helpful? Yes  No   Report this review
  • Anonymous

    Posted September 16, 2002

    easy to read, clearly explained

    The book is well-planned itself. I feel it enthusiastic, precise to the point and easily digested. At least it won't feel like some textbooks that only make you have a headache.

    Was this review helpful? Yes  No   Report this review
  • Anonymous

    Posted July 31, 2002

    Excellent for small fast S/W development

    This is the best of the Extreme Programming books that I've read. It explains Extreme Programming well, and gives more help on the management side of things. (Extreme programming is the ideal way to develop high quality software for projects with 10 engineers or less.) Very good!

    Was this review helpful? Yes  No   Report this review
  • Anonymous

    Posted October 31, 2008

    No text was provided for this review.

Sort by: Showing all of 4 Customer Reviews

If you find inappropriate content, please report it to Barnes & Noble
Why is this product inappropriate?
Comments (optional)