Agile Software Development
Автор: Alistair Cockburn /
CHAPTER 4. Methodologies XP Under Glass
-
Часть 1
-
Extreme Programming (XP) is an agile methodology that illustrates the ideas in this book very well. Additionally, it is effective, well documented, and controversial. Thus, it makes a wonderful sample methodology to examine. At this point, we finally have enough vocabulary to put it under the methodology microscope.
The short story is that XP scores very high within its area of applicability. It (like all others) needs to be adjusted when applied outside its sweet spot.
XP in a Nutshell
The briefest of reviews of XP is in order, although much has been written about it elsewhere (Beck 1999, Jeffries 2000, XP URL).
Following is a summary, as brief as it would be if given as instructions over the phone or e-mail:
Use only 3-10 programmers. Arrange for one or several customers to be on site to provide ongoing expertise. Everyone works in one room or adjacent rooms, preferably with the workstations clustered, monitors facing outwards in a circle, half as many workstations as programmers.
Do development in three-week periods, or "iterations. " Each iteration results in running, tested code of direct use to the customers. The compiled system is rolled out to its end users at the end of each release period, which may be every two to five iterations.
The unit of requirements gathering is the "user story, " user-visible functionality that can be developed within one iteration. The customers write the stories for the iteration onto simple index cards. The customer(s) and programmers negotiate what will get done in the next iteration in the following way:
· The programmers estimate the time to complete each card.
· The customers prioritize, alter, and de-scope as needed so that the most valuable stories are most likely to get done in the allotted time period.
The programmers write the tasks for each story on flipcharts on the wall or a whiteboard, estimating the time they will need for each task. Over time, the customers and programmers can reprioritize or de-scope the tasks or stories.
Development on a story starts with the programmers discussing the story with the expert customer. Because this discussion is guaranteed to take place, the text written on the story card can be very brief, just enough to remind everyone of what the conversation is going to be about. The understanding of the requirements grow through those conversations and any pictures or documents the people decide they need.
Programmers work in pairs. They follow strict coding standards that they set up at the beginning of the project. They create unit tests for everything they write and make sure that those tests run at 100% every time they check in their code to the mandatory versioning and configuration-management system. They develop in tiny increments of 15 minutes to a few hours long, integrating their code several times a day. At the end of each of these integrations, they ensure that the entire code base passes all unit tests.
At any time, any two programmers sitting together may change any line of code in the system. In fact, they are supposed to. Any time the two find a section of code that appears hard to understand or overly complex, they are to revise it, constantly simplifying and improving it. At all times, they are to keep the overall design as simple as they can and the code as clear as they can. This constant refactoring is possible because of the extensive unit test suites in place. It is also possible because the programmers rotate pair assignments every day or so, and so knowledge of the changes in the code structure pass through the group through the shifting partnerships.
While the programmers are working, the customers are doing three things: They visit with the programmers to clarify ideas, they write system acceptance tests to be run during and at the end of the iteration, and they select stories to be built for the next iteration. They may be on the project full time or not, as they decide.
The team holds a stand-up meeting every day, in which they describe what they are working on, what is working well for them, and what they might need help with. The meeting is held standing up to keep it short. At the end of each iteration, they hold another meeting in which they review what they did well and what they want to work on next time. They post this list for all to see during the next iteration.
XP prizes four values: communication, simplicity, testing, and courage. The "courage" value is intended as courage to go ahead and make improvements to the system at any time.
One person on the team is designated the "coach" for the team. This person reviews with the team members their use of the key practices: use of pair programming and testing, pair rotation, keeping design simple, communicating, and so on.
Dissecting XP
An XP team makes great use of osmotic communication, face-to-face communication, convection currents of information flow, and information radiators on the wall.
The consistent availability of experts means that the delay from question to answer is short. The time and energy cost to discover a needed piece of information is low; the rate of information dispersion is high.
-
Навигация [ Часть 1. Глава 20. ]
Закладки
Agility implies maneuverability, a characteristic that…
In arguing for the Theory Building View, the basic…
13. (FIRST TECHNIQUE). .. your sword now having bounced upward,…
Accepting program modifications demanded by changing external…
The chart shows the state of the user stories being…
The main question is, if you were funding this project, which…
The third problem is absence of feedback from the downstream…
The complete discussion about when and where to apply concurrent…
Figure 4-1. Elements of a methodology. Roles. Who you employ,…
Games are not just for children, although children also play…
After much coaching for six months, his programs still looked…
Crystal Clear is the most tolerant, low-ceremony small-team…
Using the planning game in this way, the sponsors can…
1. Project name, job of person interviewed (the interviewee…
That it is people who design software is terribly obvious.…
For us as designers, it was possible to express both…
Types of Methodologies Rechtin (1997) categorizes methodologies…