2. Overview of Extreme Programming

image

© Jennifer M. Kohnke

As developers we need to remember that XP is not the only game in town.

—Pete McBreen

Chapter 1 outlined what agile software development is about. However, the chapter didn’t tell us exactly what to do. It gave us some platitudes and goals but little in the way of real direction. This chapter corrects that.

The Practices of Extreme Programming

Whole Team

We want customers, managers, and developers to work closely with one another so that they are all aware of one another’s problems and are collaborating to solve those problems. Who is the customer? The customer of an XP team is the person or group that defines and prioritizes features. Sometimes, the customer is a group of business analysts, quality assurance specialists, and/or marketing specialists working in the same company as the developers. Sometimes, the customer is a user representative commissioned by the body of users. Sometimes, the customer is in fact the paying customer. But in an XP project, the customer, however defined, is a member of, and available to, the team.

The best case is for the customer to work in the same room as the developers. Next best is if the customer works within 100’ of the developers. The larger the distance, the more difficult it is for the customer to be a true team member. A customer located in another building or in another state it is very difficult to integrate into the team.

What do you do if the customer simply cannot be close by? My advice is to find someone who can be close by and who is willing and able to stand in for the true customer.

User Stories

In order to plan a project, we must know something about the requirements, but we don’t need to know very much. For planning purposes, we need to know only enough about a requirement to estimate it. You may think that in order to estimate a requirement, you need to know all its details. But that’s not quite true. You have to know that there are details, and you have to know roughly the kinds of details there are, but you don’t have to know the specifics.

The specific details of a requirement are likely to change with time, especially once the customer begins to see the system come together. Nothing focuses requirements better than seeing the nascent system come to life. Therefore, capturing the specific details about a requirement long before it is implemented is likely to result in wasted effort and premature focusing.

In XP, we get the sense of the details of the requirements by talking them over with the customer. But we do not capture that detail. Rather, the customer writes a few words on an index card that we agree will remind us of the conversation. The developers write an estimate on the card at roughly the same time that the customer writes it. They base that estimate on the sense of detail they got during their conversations with the customer.

A user story is a mnemonic token of an ongoing conversation about a requirement. A user story is a planning tool that the customer uses to schedule the implementation of a requirement, based on its priority and estimated cost.

Short Cycles

An XP project delivers working software every two weeks. Each of these two-week iterations produces working software that addresses some of the needs of the stakeholders. At the end of each iteration, the system is demonstrated to the stakeholders in order to get their feedback.

The iteration plan

An iteration is usually two weeks in length and represents a minor delivery that may or may not be put into production. The iteration plan is a collection of user stories selected by the customer according to a budget established by the developers.

The developers set the budget for an iteration by measuring how much they got done in the previous iteration. The customer may select any number of stories for the iteration so long as the total of the estimate does not exceed that budget.

Once an iteration has been started, the business agrees not to change the definition or priority of the stories in that iteration. During this time, the developers are free to cut the stories up into tasks and to develop the tasks in the order that makes the most technical and business sense.

The release plan

XP teams often create a release plan that maps out the next six or so iterations. That plan is known as a release plan. A release is usually three months’ worth of work. It represents a major delivery that can usually be put into production. A release plan consists of prioritized collections of user stories that have been selected by the customer according to a budget presented by the developers.

The developers set the budget for the release by measuring how much they got done in the previous release. The customer may select any number of stories for the release, so long as the total of the estimate does not exceed that budget. The business also determines the order in which the stories will be implemented in the release. If the team so desires, it can map out the first few iterations of the release by showing which stories will be completed in which iterations.

Releases are not cast in stone. The business can change the release content at any time. The business can cancel stories, write new stories, or change the priority of a story. However, the business should strive not to change an iteration.

Acceptance Tests

The details about the user stories are captured in the form of acceptance tests specified by the customer. The acceptance tests for a story are written immediately preceding, or even concurrently with, the implementation of that story. They are written in a scripting language that allows them to be run automatically and repeatedly.1 Together, they act to verify that the system is behaving as the customers have specified.

Acceptance tests are written by business analysts, quality assurance specialists, and testers during the iteration. The language they are written in is easy for programmers, customers, and businesspeople to read and understand. It is from these tests that the programmers learn the true detailed operation of the stories they are implementing. These tests become the true requirements document of the project. Every detail about every feature is described in the acceptance tests, and those tests are the final authority as to whether those features are done and correct.

Once an acceptance test passes, it is added to the body of passing acceptance tests and is never allowed to fail again. This growing body of acceptance tests is run several times per day, every time the system is built. If an acceptance tests fails, the build is declared a failure. Thus, once a requirement is implemented, it is never broken. The system is migrated from one working state to another and is never allowed to go unworking for longer than a few hours.

Pair Programming

Code is written by pairs of programmers working together at the same workstation. One member of each pair drives the keyboard and types the code. The other member of the pair watches the code being typed, finding errors and improvements.2 The two interact intensely. Both are completely engaged in the act of writing software.

The roles change frequently. If the driver gets tired or stuck, the pair partner grabs the keyboard and starts to drive. The keyboard will move back and forth between them several times in an hour. The resultant code is designed and authored by both members. Neither can take more than half the credit.

Pair membership changes frequently. A reasonable goal is to change pair partners at least once per day so that every programmer works in two different pairs each day. Over the course of an iteration, every member of the team should have worked with every other member of the team, and they should have worked on just about everything that was going on in the iteration.

Pair programming dramatically increases the spread of knowledge throughout the team. Although specialties remain, and tasks that require certain specialties will usually belong to the appropriate specialists, those specialists will pair with nearly everyone else on the team. This will spread the specialty throughout the team such that other team members can fill in for the specialists in a pinch. Studies by Williams3 and Nosek4 have suggested that pairing does not reduce the efficiency of the programming staff but does significantly reduce the defect rate.

Test-Driven Development (TDD)

Chapter 4 discusses this topic in great detail. What follows is a quick overview.

All production code is written in order to make a failing unit test pass. First, we write a unit test that fails because the functionality it is testing for doesn’t exist. Then we write the code that makes that test pass.

This iteration between writing test cases and code is very rapid, on the order of a minute or so. The test cases and code evolve together, with the test cases leading the code by a very small fraction. (See Chapter 6 for an example.)

As a result, a very complete body of test cases grows along with the code. These tests allow the programmers to check whether the program works. Programming a pair that makes a small change can run the tests to ensure that nothing has broken. This greatly facilitates refactoring (discussed later in this chapter).

When you write code in order to make test cases pass, that code is by definition testable. What’s more, there is a strong motivation to decouple modules so that they can be tested independently. Thus, the design of code that is written in this fashion tends to be much less coupled. The principles of object-oriented design (OOD) play a powerful role in helping you with this decoupling (see Section II).

Collective Ownership

A pair has the right to check out any module and improve it. No programmers are individually responsible for any one particular module or technology. Everybody works on the graphical user interface (GUI).5 Everybody works on the middleware. Everybody works on the database. Nobody has more authority than anybody else over a module or a technology.

This doesn’t mean that XP denies specialties. If your specialty is the GUI, you are most likely to work on GUI tasks. But you will also be asked to pair on middleware and database tasks. If you decide to learn a second specialty, you can sign up for tasks, and work with specialists, who will teach it to you. You are not confined to your specialty.

Continuous Integration

The programmers check their code in and integrate several times per day. The rule is simple. The first one to check in wins; everybody else merges.

XP teams use nonblocking source control. This means that programmers are allowed to check any module out at any time, regardless of who else may have it checked out. When checking the module back in after modifying it, the programmer must be prepared to merge it with any changes made by anyone who checked the module in earlier. To avoid long merge sessions, the members of the team check their modules very frequently.

A pair will work for an hour or two on a task. They create test cases and production code. At some convenient breaking point, probably long before the task is complete, they decide to check the code back in. They first make sure that all the tests run. They integrate their new code into the existing code base. If there is a merge to do, they do it. If necessary, they consult with the programmers who beat them to the check-in. Once their changes are integrated, they build the new system. They run every test in the system, including all currently running acceptance tests. If they broke anything that used to work, they fix it. Once all the tests run, they finish the check-in.

So XP teams will build the system many times each day. They build the whole system from end to end.6 If the final result of a system is a CD-ROM, they cut the CD-ROM. If the final result of the system is an active Web site, they install that Web site, probably on a testing server.

Sustainable Pace

A software project is not a sprint; it is a marathon. A team that leaps off the starting line and starts racing as fast as it can will burn out long before finishing. In order to finish quickly, the team must run at a sustainable pace; it must conserve its energy and alertness. It must intentionally run at a steady, moderate pace.

The XP rule is that a team is not allowed to work overtime. The only exception to that rule is that in the last week in a release, a team that is within striking distance of its release goal can sprint to the finish and work overtime.

Open Workspace

The team works together in an open room. Tables are set up with workstations on them. Each table has two or three such workstations. Two chairs are in front of each workstation. The walls are covered with status charts, task breakdowns, Unified Modeling Language (UML) diagrams, and so on.

The sound in this room is a buzz of conversation. Each pair is within earshot of every other pair. Each has the opportunity to hear when another is in trouble. Each knows the state of the other. The programmers are in a position to communicate intensely.

One might think that this would be a distracting environment. It would be easy to fear that you’d never get anything done, because of the constant noise and distraction. In fact, this doesn’t turn out to be the case. Moreover, instead of interfering with productivity, a University of Michigan study suggested, working in a “war room” environment may increase productivity by a factor of 2.7

The Planning Game

Chapter 3 goes into great detail about the XP planning game. I’ll describe it briefly here.

The essence of the planning game is the division of responsibility between business and development. The businesspeople—customers—decide how important a feature is, and the developers decide how much that feature will cost to implement.

image

At the beginning of each release and each iteration, the developers give the customers a budget. The customers choose stories whose costs total up to that budget and are not allowed to exceed their budget. Developers determine their budget, based on how much they were able to get done in the previous iteration or in the previous release.

With these simple rules in place, and with short iterations and frequent releases, it won’t be long before the customers and developers get used to the rhythm of the project. The customers will get a sense for how quickly the developers are going. Based on that sense, the customers will be able to determine how long their project will take and how much it will cost.

Simple Design

An XP team makes its designs as simple and expressive as they can be. Furthermore, the team narrows its focus to consider only the stories that are planned for the current iteration, not worrying about stories to come. Rather, the team migrates the design of the system from iteration to iteration to be the best design for the stories that the system currently implements.

This means that an XP team will probably not start with infrastructure, probably won’t select the database first, and probably won’t select the middleware first. Rather, the team’s first act will be to get the first batch of stories working in the simplest way possible. The team will add the infrastructure only when a story comes along that forces it to.

Three XP mantras guide the developer.

  1. Consider the simplest thing that could possibly work. XP teams always try to find the simplest possible design option for the current batch of stories. If we can make the current stories work with flat files, we might not use a database. If we can make the current stories work with a simple socket connection, we might not use an ORB, or a Web Service. If we can make the current stories work without multithreading, we might not include mutithreading. We try to consider the simplest way to implement the current stories. Then we choose a practical solution that is as close to that simplicity as we can practically get.
  2. You aren’t going to need it. Yeah, but we know we’re going to need that database one day. We know we’re going to have to have an ORB one day. We know we’re going to have to support multiple users one day. So we need to put the hooks in for those things now, don’t we?

    An XP team seriously considers what will happen if it resists the temptation to add infrastructure before it is strictly needed. The team starts from the assumption that it isn’t going to need that infrastructure. The team puts the infrastructure in only if it has proof, or at least very compelling evidence, that putting the infrastructure in now will be more cost-effective than waiting.

  3. Once and only once. XPers don’t tolerate duplication of code. Wherever they find it, they eliminate it.

There are many sources of code duplication. The most obvious are those stretches of code that were captured with a mouse and plopped down in multiple places. When we find those, we eliminate them by creating a function or a base class. Sometimes, two or more algorithms may be remarkably similar and yet differ in subtle ways. We turn those into functions or use the TEMPLATE METHOD pattern (see Chapter 22). Once discovered, we won’t tolerate duplication, whatever its source.

The best way to eliminate redundancy is to create abstractions. After all, if two things are similar, some abstraction must unify them. Thus, the act of eliminating redundancy forces the team to create many abstractions and further reduce coupling.

Refactoring

Chapter 5 covers refactoring in more detail.8 What follows here is a brief overview.

Code tends to rot. As we add feature after feature and deal with bug after bug, the structure of the code degrades. Left unchecked, this degradation leads to a tangled, unmaintainable mess.

XP teams reverse this degradation through frequent refactoring. Refactoring is the practice of making a series of tiny transformations that improve the structure of the system without affecting its behavior. Each transformation is trivial, hardly worth doing. But together, they combine into significant transformations of the design and architecture of the system.

After each tiny transformation, we run the unit tests to make sure that we haven’t broken anything. Then we do the next transformation, and the next, and the next, running the tests after each. In this manner, we keep the system working while transforming its design.

Refactoring is done continuously rather than at the end of the project, the end of the release, or the end of the iteration, or even the end of the day. Refactoring is something we do every hour or every half hour. Through refactoring, we continuously keep the code as clean, simple, and expressive as it can be.

Metaphor

Metaphor is the only XP practice that is not concrete and direct. Metaphor is the least well understood of all the practices of XP. XPers are pragmatists at heart, and this lack of concrete definition makes us uncomfortable. Indeed, the proponents of XP have often discussed removing metaphor as a practice. Yet in some sense, metaphor is one of the most important practices of all.

Think of a jigsaw puzzle. How do you know how the pieces go together? Clearly, each piece abuts others, and its shape must be perfectly complementary to the pieces it touches. If you were blind and had a very good sense of touch, you could put the puzzle together by diligently sifting through each piece and trying it in position after position.

But something more powerful than the shape of the pieces binds the puzzle together: a picture. The picture is the true guide. The picture is so powerful that if two adjacent pieces of the picture do not have complementary shapes, you know that the puzzle maker made a mistake.

That’s what the metaphor is. It’s the big picture that ties the whole system together. It’s the vision of the system that makes the location and shape of all the individual modules obvious. If a module’s shape is inconsistent with the metaphor, you know that it is the module that is wrong.

Often, a metaphor boils down to a system of names. The names provide a vocabulary for elements in the system and helps to define their relationships.

For example, I once worked on a system that transmitted text to a screen at 60 characters per second. At that rate, a screen fill could take some time. So we’d allow the program that was generating the text to fill a buffer. When the buffer was full, we’d swap the program out to disk. When the buffer got close to empty, we’d swap the program back in and let it run some more.

We spoke about this system in terms of dump trucks hauling garbage. The buffers were little trucks. The display screen was the dump. The program was the garbage producer. The names all fit together and helped us think about the system as a whole.

As another example, I once worked on a system that analyzed network traffic. Every 30 minutes, it polled dozens of network adapters and pulled down the monitoring data from them. Each network adapter gave us a small block of data composed of several individual variables. We called these blocks “slices.” The slices were raw data that needed to be analyzed. The analysis program “cooked” the slices, so it was called “the toaster.” We called the individual variables within the slices “crumbs.” All in all, it was a useful and entertaining metaphor.

Of course, a metaphor is more than a system of names. A metaphor is a vision for the system. A metaphor guides all the developers to choose appropriate names, select appropriate locations for functions, create appropriate new classes and methods, and so on.

Conclusion

Extreme Programming is a set of simple and concrete practices that combine into an agile development process. XP is a good general-purpose method for developing software. Many project teams will be able to adopt it as is. Many others will be able to adapt it by adding or modifying practices.

Bibliography

[ARC97] Alistair Cockburn, “The Methodology Space,” Humans and Technology, technical report HaT TR.97.03 (dated 97.10.03), http://members.aol.com/acockburn/papers/methyspace/methyspace.htm.

[Beck99] Kent Beck, Extreme Programming Explained: Embrace Change, Addison-Wesley, 1999.

[Beck2003] Kent Beck, Test-Driven Development by Example, Addison-Wesley, 2003.

[Cockburn2001] Alistair Cockburn and Laurie Williams, “The Costs and Benefits of Pair Programming,” XP2000 Conference in Sardinia, reproduced in Giancarlo Succi and Michele Marchesi, Extreme Programming Examined, Addison-Wesley, 2001.

[DRC98] Daryl R. Conner, Leading at the Edge of Chaos, Wiley, 1998.

[EWD72] D. J. Dahl, E. W. Dijkstra, and C.A. R. Hoare, Structured Programming, Academic Press, 1972.

[Fowler99] Martin Fowler, Refactoring: Improving the Design of Existing Code, Addison-Wesley, 1999.

[Newkirk2001] James Newkirk and Robert C. Martin, Extreme Programming in Practice, Addison-Wesley, 2001.

[Nosek98] J. T. Nosek, “The Case for Collaborative Programming,” Communications of the ACM, 1998, pp. 105–108.

[Williams2000] Laurie Williams, Robert R. Kessler, Ward Cunningham, Ron Jeffries, “Strengthening the Case for Pair Programming,” IEEE Software, July–Aug. 2000.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
44.192.16.116