Book Details

Extreme Programming Explained

Embrace Change

• Kent Beck
• Addison-Wesley Professional
• October 1999

Top

Preface

• XP is a lightweight methodology for small-tomedium-sized teams developing software in the face of vague or rapidly changing requirements.
• Why the "extreme" in the name?

  XP takes commonsense principles and practices to extreme levels:

  • If code reviews are good, we'll review code all the time (pair programming).
  • If testing is good, everybody will test all the time (unit testing), even the customers (functional testing).
  • If design is good, we'll make it part of everybody's daily business (refactoring).
  • If simplicity is good, we'll always leave the system with the simplest design that supports its current functionality (the simplest thing that could possibly work).
  • If architecture is important, everybody will work defining and refining the architecture all the time (metaphor).
  • If integration testing is important, then we'll integrate and test several times a day (continuous integration).
  • If short iterations are good, we'll make the iterations really, really short—seconds and minutes and hours, not weeks and months and years (the Planning Game).
• XP makes two sets of promises.
  • To programmers: they will be able to work on things that really matter, every day.

    They won't have to face scary situations alone.

    They will be able to do everything in their power to make their system successful.

    They will make decisions that they can make best, and they won't make decisions they they aren't best qualified to make.

  • To customers and managers: they will get the most possible value out of every programming week.

    Every few weeks they will be able to see concrete progress on goals they care about.

    They will be able to change the direction of the project in the middle of development without incurring exorbitant costs.

• In short, XP promises to reduce project risk, improve responsiveness to business changes, improve productivity throughout the life of a system, and add fun to building software in teams—all at the same time.

This Book

• This book talks about the thinking behind XP—its roots, philosophy, stories, myths.
• It is intended to help you make an informed decision about whether or not to use XP on your project.
• This isn't a book about precisely how to do Extreme Programming.

  You won't read lots of checklists here, or see many examples, or lots of programming stories.

What Is XP ?

• XP is a lightweight, efficient, low-risk, flexible, predictable, scientific, and fun way to develop software.
• It is distinguished from other methodologies by:
  • Its early, concrete, and continuing feedback from short cycles.
  • Its incremental planning approach, which quickly comes up with an overall plan that is expected to evolve through the life of the project.
  • Its ability to flexibly schedule the implementation of functionality, responding to changing business needs.
  • Its reliance on automated tests written by programmers and customers

    to monitor the progress of development, to allow the system to evolve, and to catch defects early.

  • Its reliance on oral communication, tests, and source code to communicate system structure and intent.
  • Its reliance on an evolutionary design process that lasts as long as the system lasts.
  • Its reliance on the close collaboration of programmers with ordinary skills.
  • Its reliance on practices that work with both the short-term instincts of programmers and the long-term interests of the project.
• XP is a discipline of software development. It is a discipline because there are certain things that you have to do to be doing XP.
• None of the ideas in XP are new. Most are as old as programming.
• The innovation of XP is
  • Putting all these practices under one umbrella.
  • Making sure they are practiced as thoroughly as possible.
  • Making sure the practices support each other to the greatest possible degree.

Enough

• XP is an experiment in answer to the question, "How would you program if you had enough time?"
• If you had enough time, you would write tests; you would restructure the system when you learned something; you would talk a lot with fellow programmers and with the customer.
• Such a "mentality of sufficiency" creates its own efficiencies, just as the mentality of scarcity creates its own waste.

Outline

• The Problem

  sets up the problem Extreme Programming is trying to solve and present criteria for evaluating the solution.

  This section will give you an idea of the overall worldview of Extreme Programming.

• The Solution

  turns the abstract ideas in the first section into the practices of a concrete methodology.

  This section will not tell you exactly how you can execute the practices, but rather talks about their general shape.

  The discussion of each practice relates it to the problems and principles introduced in the first section.

• Implementing XP

  describes a variety of topics around implementing XP—

  how to adopt it, what is expected from the various people in an extreme project, how XP looks to the business folks.

Top

Chapter 1. Risk: The Basic Problem

• The basic problem of software development is risk:
  • Schedule slips

    the day for delivery comes, and you have to tell the customer that the software won't be ready for another six months.

  • Project canceled

    after numerous slips, the project is canceled without ever going into production.

  • System goes sour

    the software is successfully put into production, but after a couple of years the cost of making changes or the defect rate rises so much that the system must be replaced.

  • Defect rate

    the software is put into production, but the defect rate is so high that it isn't used.

  • Business misunderstood

    the software is put into production, but it doesn't solve the business problem that was originally posed.

  • Business changes

    the software is put into production, but the business problem it was designed to solve was replaced six months ago by another, more pressing, business problem.

  • False feature rich

    the software has a host of potentially interesting features, all of which were fun to program, but none of which makes the customer much money.

  • Staff turnover

    after two years, all the good programmers on the project begin to hate the program and leave.

• How does XP address the risks listed above?
  • Schedule slips

    XP calls for short release cycles, a few months at most, so the scope of any slip is limited.

    Within a release, XP uses one- to four-week iterations of customer requested features for fine-grained feedback about progress.

    Within an iteration, XP plans with one- to three-day tasks, so the team can solve problems even during an iteration.

    Finally, XP calls for implementing the highest priority features first, so any features that slip past the release will be of lower value.

  • Project canceled

    XP asks the customer to choose the smallest release that makes the most business sense,

    so there is less to go wrong before going into production and the value of the software is greatest.

  • System goes sour

    XP creates and maintains a comprehensive suite of tests, which are run and re-run after every change to ensure a quality baseline.

    XP always keeps the system in prime condition. Cruft is not allowed to accumulate.

  • Defect rate

    XP tests from the perspective of both programmers writing tests function-by-function and customers writing tests program-feature-by-program-feature.

  • Business misunderstood

    XP calls for the customer to be an integral part of the team.

    The specification of the project is continuously refined during development,

    so learning by the customer and the team can be reflected in the software.

  • Business changes

    XP shortens the release cycle, so there is less change during the development of a single release.

    During a release, the customer is welcome to substitute new functionality for functionality not yet completed.

    The team doesn't even notice if it is working on newly discovered functionality or features defined years ago.

  • False feature rich

    XP insists that only the highest priority tasks are addressed.

  • Staff turnover

    XP asks programmers to accept responsibility for estimating and completing their own work,

    gives them feedback about the actual time taken so their estimates can improve, and respects those estimates.

    The rules for who can make and change estimates are clear.

    Thus, there is less chance for a programmer to get frustrated by being asked to do the obviously impossible.

    XP also encourages human contact among the team, reducing the loneliness that is often at the heart of job dissatisfaction.

    Finally, XP incorporates an explicit model of staff turnover.

    New team members are encouraged to gradually accept more and more responsibility, and are assisted along the way by each other and by existing programmers.

Top

Chapter 2. A Development Episode

• Notice in XP development cycle:
  • Pairs of programmers program together.
  • Development is driven by tests.

    You test first, then code. Until all the tests run, you aren't done.

    When all the tests run, and you can't think of any more tests that would break, you are done adding functionality.

  • Pairs don't just make test cases run. They also evolve the design of the system.

    Changes aren't restricted to any particular area.

  • Integration immediately follows development, including integration testing.

Top

Chapter 3. Economics of Software Development

• three factors:
  • Cash flows in and out: simply analyze what makes a software project valuable
  • Interest rates: calculate the net present value of the cash flows
  • Project mortality: probability that the project will survive to pay or earn those cash flows
• strategies for maximizing the economic value of the project:
  • Spending less: difficult because everyone starts off with pretty much the same tools and skills.
  • Earning more: only possible with a superior marketing and sales organization, not topics we will cover in this book.
  • Spending later and earning sooner: so we pay less interest on the money we spend and we earn more interest on the money we receive.
  • Increasing the probability that the project will stay alive: so we are more likely to get the big payoff late in the project.

Options

• Another way of looking at the economics of a software project — as a series of options:
  • Option to abandon: you can get something out of the project even if you cancel it.

    The more value you can take from the project without actually delivering it in its originally envisioned form, the better.

  • Option to switch: you can change the direction of a project.

    A project management strategy is more valuable if halfway through a project the customers can change the requirements.

    The more often and the more violently the requirements can change, the better.

  • Option to defer: you can wait until the situation has sorted itself out before investing.

    A project management strategy is more valuable if you can wait to spend money without completely losing the opportunity to invest.

    The longer the deferral and the more money that can be deferred, the better.

  • Option to grow: if a market looks to be taking off, you can grow quickly to take advantage of it.

    A project management strategy is more valuable if it can gracefully scale up to greater and greater production given greater investment.

    The faster and longer the project can grow, the better.

• There are five factors involved:
  • The amount of investment required to get the option
  • The price at which you can purchase the prize if you exercise the option
  • The current value of the prize
  • The amount of time in which you can exercise the options
  • The uncertainty in the eventual value of the prize

    (comes from technical risk, a changing business environment, or rapidly evolving requirements)

• The worth of options is generally dominated by the last factor, the uncertainty.

  The greater the uncertainty, the more valuable the strategy will become.

  We create a project management strategy that maximizes the value of the project analyzed as options by providing:

  • Accurate and frequent feedback about progress
  • Many opportunities to dramatically change the requirements
  • A smaller initial investment
  • The opportunity to go faster

Top

Chapter 4. Four Variables

• Here is a model of software development from the perspective of a system of control variables:
  • Cost
  • Time
  • Quality
  • Scope
• External forces (customers, managers) get to pick the values of any three of the variables.

  The development team gets to pick the resultant value of the fourth variable

• The solution is to make the four variables visible.

  If everyone—programmers, customers, and managers—can see all four variables, they can consciously choose which variables to control.

  If they don't like the result implied for the fourth variable, they can change the inputs, or they can pick a different three variables to control.

Interactions Between the Variables

• Cost

  More money can grease the skids a little, but too much money too soon creates more problems than it solves.

  On the other hand, give a project too little money and it won't be able to solve the customer's business problem.

• Time

  More time to deliver can improve quality and increase scope.

  Since feedback from systems in production is vastly higher quality than any other kind of feedback, giving a project too much time will hurt it.

  Give a project too little time and quality suffers, with scope, time, and cost not far behind.

• Quality

  Quality is terrible as a control variable.

  You can make very short-term gains (days or weeks) by deliberately sacrificing quality, but the cost—human, business, and technical—is enormous.

• Scope

  Less scope makes it possible to deliver better quality (as long as the customer's business problem is still solved).

  It also lets you deliver sooner or cheaper.

• There is not a simple relationship between the four variables:
  • Cost
    • You can't just get software faster by spending more money. (Nine women cannot make a baby in one month.)
    • In many ways, cost is the most constrained variable.

      The investment has to start small and grow over time.

    • All the constraints on cost can drive managers crazy, especially if they are focused on an annual budgeting process.
    • The other problem with cost is that higher costs often feed tangential goals, like status or prestige.

      "Of course, I have a project with 150 people (sniff, sniff)." (the manager wanted to look impressive)

    • Within the range of investment that can sensibly be made, by spending more money you can increase the scope,

      or you can move more deliberately and increase quality, or you can (to some extent) reduce time to market.

  • Time
    • The time variable is often out of the hands of the project manager and in the hands of the customer.

      The end of the year; before the quarter starts; when the old system is scheduled to be shut off; a big trade show.

  • Quality
    • Often, by insisting on better quality you can get projects done sooner, or you can get more done in a given amount of time.
    • This happened to me when I started writing unit tests.

      As soon as I had my tests, I had so much more confidence in my code that I wrote faster, without stress.

      I could clean up my system more easily, which made further development easier.

    • As soon as the teams start testing, or as soon as they agree on coding standards, they start going faster.