Building on the values of simplicity, communication, feedback, and courage, Extreme Programming is characterized by about a dozen key practices.
Whole Team
The Whole Team practice calls for all the stakeholders—developers, managers, customers, and users—to form a single team. The practice calls for the team to work together and to be together psychologically and even physically. The ideal situation is to have the whole team together, in one room, to do their work.
The Whole Team practice was originally called “On-Site Customer” to reflect the special importance of a tight connection between the people who need the software, customers and users in the XP “Customer” role, and those developing it, developers and managers, whom we call “Programmers.” When customers and programmers are together, information flows freely and rapidly. Perhaps even more important, working together engenders trust and cooperation between these two halves of one project.
This practice, as you can see, supports the values of simplicity, communication, and feedback. It enables the team to use conversation instead of needing so much written material, and because the team members are together, their conversations can be as frequent as needed to keep everyone aligned.
Planning Game
The XP planning practices are called the “Planning Game” to make planning less frightening and to remind us that planning is an activity that works best if we do it willingly and often. XP plans are always produced by the Whole Team, never by a single individual either inside or outside the team. The practices combine the special knowledge of everyone on the team. Customers understand priorities and needs, managers understand time and money budgets, and programmers understand how to build things and how long it will take.
The XP “Release Plan” lays out a picture of the whole project. It looks at all the known requirements in sufficient detail to associate an estimate with each desired feature, or “story,” as we call the features. With estimates in hand, customers and managers can put together the best possible schedule given priority and budget. This plan is, of course, subject to revision as the whole team learns more about all the variables: feature definitions, priorities, actual costs, and changing budgets. An XP Release Plan can give an increasingly accurate picture of what is really going to happen. Wise teams update their Release Plans very frequently.
The XP “Iteration Plan” plans the next iteration. XP teams develop software in short time-boxed periods called iterations, typically spanning one or two weeks. In each iteration, the team plans, builds, and delivers tested new features to the customer. Yes, features are delivered starting with the very first iteration. There’s no “three months to set up the framework” in XP, and just how we go about delivering with the first iteration is the real subject.
At the beginning of each iteration, the Iteration Plan is produced. At first, it can be difficult to know how much we can get done in an iteration, but because we repeat the planning process every week or two, we quickly get quite good at it. The customer, based on the programmers’ estimates of cost and on the team’s observed speed of building features, selects the feature stories to be built. The team puts together a simple plan to get these stories done and then builds, tests, and delivers the software.
These XP planning practices are quite simple. They focus on communication of requirements stories and on feedback about the speed and quality of our implementation. In addition, the customers get good feedback on the quality of their decisions, by seeing the actual results of their requests in tested, running software.
Small Releases
XP teams focus on small releases of tested, running software. With every iteration, the team delivers proven software to its customers. Beyond that, however, we put the software in the hands of real end users as frequently as possible. If an XP project were to run for a year, we would like to ship production versions four or more times during that period.
This practice provides important feedback to stakeholders on how well the team is progressing. Placing the product in real users’ hands also provides important feedback on the quality of requirements stories and on priority decisions.
Customer Acceptance Tests
Although requirements stories are written on cards to serve as planning tokens, and although stories are explained in many conversations between programmers and the on-site customers, requirements in XP have a third critical component: confirmation. The customer confirms that every story is correctly understood and implemented by defining one or more automated “Customer Acceptance Tests”. Let’s underline these points. An XP story includes three aspects: card, conversation, and confirmation. And the story is done when the Customer Acceptance Tests run.
This practice provides important feedback to the customers about the quality of the team’s work—and important feedback about the quality of the customers’ own tests. The customer tests communicate and document the precise requirements in an unambiguous and verifiable way. Seeing the Customer Acceptance Tests coming on line and continuing to work gives the entire team confidence that things are going well and provides the courage to continue.
Simple Design
As a new program comes into being, it starts out small and grows over time. We want the design of the program to be good always, and we observe that a small program’s good design can and should be much simpler than that of a larger program. Because we are building the program incrementally, shipping new and improved versions every couple of weeks, we start with a simple, good, and sufficient design for the small early versions and we grow and improve the design as we add capability to the program. The result is that our design investment is spread over the whole life of the project, rather than loaded at the front. Because of this, we can spread the delivery of features over the life of the project as well, instead of loading feature delivery towards the end. We can even deliver the most important features early in the project lifetime. This practice improves the return on the project investment, and it gives our stakeholders great feedback and courage about the project. We focus on keeping the program as simple as possible but no simpler. We use the rapid feedback of XP’s short iterations to improve the design.
Pair Programming
Extreme Programmers write their production code with two programmers sitting side by side at the same machine. This practice provides immediate code review for every line of code, it improves the design every step of the way, it helps us maintain energy and momentum, and it helps us maintain the discipline to work in the most effective way we know how.
Most programmers have worked together on hard or interesting problems, and usually they find it productive and beneficial. Extreme Programmers work together all the time and gain the benefits all the time.
The practice of pair programming provides immediate feedback on the quality of our work. It helps us communicate the design ideas, and it helps us upgrade our skills through sharing. It gives us courage to work on parts of the code we might otherwise be afraid to touch.
Test-Driven Development
Because we are growing the program as we go, because we are committed to improving the design, and because we must ship working software so frequently, we need great confidence that our new code, and our design changes, work as we intended them to. We cannot afford to have some design change break existing functionality or slow down the adding of new features.
Extreme Programmers accomplish this using “Programmer Unit Tests”, which we write as we go. We write most of the tests one at a time, immediately before adding the feature being tested. When, as inevitably happens, we do find a defect after the fact, we write new tests that first show that the defect exists and that then confirm we have the problem fixed. The existence of this growing family of tests helps us communicate what the code is supposed to do and how to use it, and it gives us feedback as to whether the code does its job correctly. The automated tests give us concrete feedback, showing that our changes haven’t broken anything, and they give us the courage to make the changes needed to keep the program alive and growing.
Design Improvement
If we’re going to start small and simple and to grow the program while keeping its design good, we must improve the design as we go. Extreme Programmers do design improvement using “refactoring,” a highly disciplined technique for improving the design of existing code. The definitive book on this subject is Martin Fowler’s Refactoring: Improving the Design of Existing Code (Addison- Wesley, 1999), and wise programmers everywhere, extreme or not, will study it and learn its lessons.
Refactoring is not about churning the code. It’s about keeping the design clean as requirements are added such that the program remains viable—alive— throughout development.
The refactoring practice supports the simplicity of the design and improves the ability of the code to communicate its design and intent. Continuous refactoring on an XP project is safe because we have our extensive automated tests to give us feedback on our changes and to gives us the courage to continue.
Supporting Practices
The eight practices described so far include the four that help with the customer/programmer interface: Whole Team, Planning Game, Small Releases, and Customer Acceptance Tests. I call these the “Circle of Life.” The other four practices make up the central programming cycle, which might be called the “Circle of Code”: Simple Design, Pair Programming, Test-Driven Development, and Design Improvement. There are five more supporting practices that we need to consider briefly.
XP teams practice Continuous Integration. The program is always integrated, always ready to go. XP teams say that sbdaily builds are for wimps. The best XP teams, even quite large ones, integrate and build the entire system many times per day. This practice provides feedback on the quality of our work, and ensures that we will communicate frequently about what we’re doing.
Extreme Programmers practice Team Code Ownership. Any pair of programmers is empowered to improve any code at any time. This practice is safe because of our many tests and easy to do because we pair program, learning new areas of the system all the time. The practice provides a simple way to put resources where they’re needed, provides a platform for communicating design ideas across the team, and gives feedback to us all so that we can benefit from everyone’s ideas.
XP teams evolve a Coding Standard. Because we work together all the time, a standard is inevitable. We’ll have to agree on a few things, like where to put the curly braces, but most of the standard emerges as a natural result of working in pairs and owning all the code as a team. The coding standard adds simplicity to our process by allowing flexibility and by settling many details. It improves our ability to give feedback by keeping the form of all code familiar. It helps us communicate through the code, and it gives us courage to contribute to any area needing our help.
XP teams use a Metaphor or System of Names to provide a common language for talking about the design of the program. Often a simple metaphor can help us focus on how the system works: “It’s like a swarm of bees that go out on the Web and bring information back to the hive.” Or “It’s like a manufacturing line that manufactures checks instead of cars.” Even if we don’t have an evocative metaphor, we develop a common terminology that helps us communicate quickly and effectively.
XP teams work at a Sustainable Pace. We do not kick way back sometimes and work massive overtime at other times. We strive to go as fast as possible and no faster. While we’ll certainly put in extra hours in an emergency, we are very sensitive to the fact that an over-tired team is a stupid team and stupefied programmers write defective programs. Worse yet, they write those defective programs slowly! We work hard, rest well, and come back to work refreshed. Sustainable Pace is not a license to slack off; it is a demand that we always make our best possible forward speed. This practice provides consistent velocity feedback, which communicates how we’re doing to our customers and other stakeholders. It requires that we know what our best pace is and that we have the courage to stick to it.
When we say “ideal,” we mean it. Recent studies at the University of Michigan found that teams working physically together were two times as effective as those working apart.
Whole Team
The Whole Team practice calls for all the stakeholders—developers, managers, customers, and users—to form a single team. The practice calls for the team to work together and to be together psychologically and even physically. The ideal situation is to have the whole team together, in one room, to do their work.
The Whole Team practice was originally called “On-Site Customer” to reflect the special importance of a tight connection between the people who need the software, customers and users in the XP “Customer” role, and those developing it, developers and managers, whom we call “Programmers.” When customers and programmers are together, information flows freely and rapidly. Perhaps even more important, working together engenders trust and cooperation between these two halves of one project.
This practice, as you can see, supports the values of simplicity, communication, and feedback. It enables the team to use conversation instead of needing so much written material, and because the team members are together, their conversations can be as frequent as needed to keep everyone aligned.
Planning Game
The XP planning practices are called the “Planning Game” to make planning less frightening and to remind us that planning is an activity that works best if we do it willingly and often. XP plans are always produced by the Whole Team, never by a single individual either inside or outside the team. The practices combine the special knowledge of everyone on the team. Customers understand priorities and needs, managers understand time and money budgets, and programmers understand how to build things and how long it will take.
The XP “Release Plan” lays out a picture of the whole project. It looks at all the known requirements in sufficient detail to associate an estimate with each desired feature, or “story,” as we call the features. With estimates in hand, customers and managers can put together the best possible schedule given priority and budget. This plan is, of course, subject to revision as the whole team learns more about all the variables: feature definitions, priorities, actual costs, and changing budgets. An XP Release Plan can give an increasingly accurate picture of what is really going to happen. Wise teams update their Release Plans very frequently.
The XP “Iteration Plan” plans the next iteration. XP teams develop software in short time-boxed periods called iterations, typically spanning one or two weeks. In each iteration, the team plans, builds, and delivers tested new features to the customer. Yes, features are delivered starting with the very first iteration. There’s no “three months to set up the framework” in XP, and just how we go about delivering with the first iteration is the real subject.
At the beginning of each iteration, the Iteration Plan is produced. At first, it can be difficult to know how much we can get done in an iteration, but because we repeat the planning process every week or two, we quickly get quite good at it. The customer, based on the programmers’ estimates of cost and on the team’s observed speed of building features, selects the feature stories to be built. The team puts together a simple plan to get these stories done and then builds, tests, and delivers the software.
These XP planning practices are quite simple. They focus on communication of requirements stories and on feedback about the speed and quality of our implementation. In addition, the customers get good feedback on the quality of their decisions, by seeing the actual results of their requests in tested, running software.
Small Releases
XP teams focus on small releases of tested, running software. With every iteration, the team delivers proven software to its customers. Beyond that, however, we put the software in the hands of real end users as frequently as possible. If an XP project were to run for a year, we would like to ship production versions four or more times during that period.
This practice provides important feedback to stakeholders on how well the team is progressing. Placing the product in real users’ hands also provides important feedback on the quality of requirements stories and on priority decisions.
Customer Acceptance Tests
Although requirements stories are written on cards to serve as planning tokens, and although stories are explained in many conversations between programmers and the on-site customers, requirements in XP have a third critical component: confirmation. The customer confirms that every story is correctly understood and implemented by defining one or more automated “Customer Acceptance Tests”. Let’s underline these points. An XP story includes three aspects: card, conversation, and confirmation. And the story is done when the Customer Acceptance Tests run.
This practice provides important feedback to the customers about the quality of the team’s work—and important feedback about the quality of the customers’ own tests. The customer tests communicate and document the precise requirements in an unambiguous and verifiable way. Seeing the Customer Acceptance Tests coming on line and continuing to work gives the entire team confidence that things are going well and provides the courage to continue.
Simple Design
As a new program comes into being, it starts out small and grows over time. We want the design of the program to be good always, and we observe that a small program’s good design can and should be much simpler than that of a larger program. Because we are building the program incrementally, shipping new and improved versions every couple of weeks, we start with a simple, good, and sufficient design for the small early versions and we grow and improve the design as we add capability to the program. The result is that our design investment is spread over the whole life of the project, rather than loaded at the front. Because of this, we can spread the delivery of features over the life of the project as well, instead of loading feature delivery towards the end. We can even deliver the most important features early in the project lifetime. This practice improves the return on the project investment, and it gives our stakeholders great feedback and courage about the project. We focus on keeping the program as simple as possible but no simpler. We use the rapid feedback of XP’s short iterations to improve the design.
Pair Programming
Extreme Programmers write their production code with two programmers sitting side by side at the same machine. This practice provides immediate code review for every line of code, it improves the design every step of the way, it helps us maintain energy and momentum, and it helps us maintain the discipline to work in the most effective way we know how.
Most programmers have worked together on hard or interesting problems, and usually they find it productive and beneficial. Extreme Programmers work together all the time and gain the benefits all the time.
The practice of pair programming provides immediate feedback on the quality of our work. It helps us communicate the design ideas, and it helps us upgrade our skills through sharing. It gives us courage to work on parts of the code we might otherwise be afraid to touch.
Test-Driven Development
Because we are growing the program as we go, because we are committed to improving the design, and because we must ship working software so frequently, we need great confidence that our new code, and our design changes, work as we intended them to. We cannot afford to have some design change break existing functionality or slow down the adding of new features.
Extreme Programmers accomplish this using “Programmer Unit Tests”, which we write as we go. We write most of the tests one at a time, immediately before adding the feature being tested. When, as inevitably happens, we do find a defect after the fact, we write new tests that first show that the defect exists and that then confirm we have the problem fixed. The existence of this growing family of tests helps us communicate what the code is supposed to do and how to use it, and it gives us feedback as to whether the code does its job correctly. The automated tests give us concrete feedback, showing that our changes haven’t broken anything, and they give us the courage to make the changes needed to keep the program alive and growing.
Design Improvement
If we’re going to start small and simple and to grow the program while keeping its design good, we must improve the design as we go. Extreme Programmers do design improvement using “refactoring,” a highly disciplined technique for improving the design of existing code. The definitive book on this subject is Martin Fowler’s Refactoring: Improving the Design of Existing Code (Addison- Wesley, 1999), and wise programmers everywhere, extreme or not, will study it and learn its lessons.
Refactoring is not about churning the code. It’s about keeping the design clean as requirements are added such that the program remains viable—alive— throughout development.
The refactoring practice supports the simplicity of the design and improves the ability of the code to communicate its design and intent. Continuous refactoring on an XP project is safe because we have our extensive automated tests to give us feedback on our changes and to gives us the courage to continue.
Supporting Practices
The eight practices described so far include the four that help with the customer/programmer interface: Whole Team, Planning Game, Small Releases, and Customer Acceptance Tests. I call these the “Circle of Life.” The other four practices make up the central programming cycle, which might be called the “Circle of Code”: Simple Design, Pair Programming, Test-Driven Development, and Design Improvement. There are five more supporting practices that we need to consider briefly.
XP teams practice Continuous Integration. The program is always integrated, always ready to go. XP teams say that sbdaily builds are for wimps. The best XP teams, even quite large ones, integrate and build the entire system many times per day. This practice provides feedback on the quality of our work, and ensures that we will communicate frequently about what we’re doing.
Extreme Programmers practice Team Code Ownership. Any pair of programmers is empowered to improve any code at any time. This practice is safe because of our many tests and easy to do because we pair program, learning new areas of the system all the time. The practice provides a simple way to put resources where they’re needed, provides a platform for communicating design ideas across the team, and gives feedback to us all so that we can benefit from everyone’s ideas.
XP teams evolve a Coding Standard. Because we work together all the time, a standard is inevitable. We’ll have to agree on a few things, like where to put the curly braces, but most of the standard emerges as a natural result of working in pairs and owning all the code as a team. The coding standard adds simplicity to our process by allowing flexibility and by settling many details. It improves our ability to give feedback by keeping the form of all code familiar. It helps us communicate through the code, and it gives us courage to contribute to any area needing our help.
XP teams use a Metaphor or System of Names to provide a common language for talking about the design of the program. Often a simple metaphor can help us focus on how the system works: “It’s like a swarm of bees that go out on the Web and bring information back to the hive.” Or “It’s like a manufacturing line that manufactures checks instead of cars.” Even if we don’t have an evocative metaphor, we develop a common terminology that helps us communicate quickly and effectively.
XP teams work at a Sustainable Pace. We do not kick way back sometimes and work massive overtime at other times. We strive to go as fast as possible and no faster. While we’ll certainly put in extra hours in an emergency, we are very sensitive to the fact that an over-tired team is a stupid team and stupefied programmers write defective programs. Worse yet, they write those defective programs slowly! We work hard, rest well, and come back to work refreshed. Sustainable Pace is not a license to slack off; it is a demand that we always make our best possible forward speed. This practice provides consistent velocity feedback, which communicates how we’re doing to our customers and other stakeholders. It requires that we know what our best pace is and that we have the courage to stick to it.
When we say “ideal,” we mean it. Recent studies at the University of Michigan found that teams working physically together were two times as effective as those working apart.
|
|
0 comments
Post a Comment