Agile Software Development
Автор: Alistair Cockburn /
CHAPTER 4. Methodologies XP Under Glass
-
Часть 2
-
Feedback is rapid. The customers get quick feedback as to the implementation implications of their requirements requests during the planning session. They see running code within days and can adjust accordingly their views on what should really be programmed. The programmers get immediate correction on the code they enter, because another person sitting next to them is watching what they type and because there are unit tests for each function they write. When changing the design, they get rapid feedback from the extensive unit and acceptance tests. They get fairly rapid feedback on their process, about every few weeks, through the iteration cycles.
XP uses human strength of communication. Through pair work and rapid feedback, it compensates for the human tendency to make mistakes.
XP is a high-discipline methodology. It calls for tight adherence to strict coding and design standards, strong unit test suites that must pass at all times, good acceptance tests, constant working in pairs, vigilance in keeping the design simple, and aggressive refactoring.
These disciplines are protected through two mechanisms and are exposed in three places.
It turns out (much to the surprise of many) that most people like working in pairs. It provides pride-in-work, because they get more done in less time, with fewer errors, and usually end up with a better design than if they were working alone. They like this. As a result, they do it voluntarily. While in pairs, they help each other write tests and follow coding standards. Thus, pair programming helps hold unit-testing in place.
Having a coach helps keep the other disciplines in place. Reports from various groups indicate to me that even better than having a coach is having several very enthusiastic XP practitioners on the team. This is because the coach is an external force, while enthusiastic teammates create peer pressure—an internal, and hence more powerful, force.
The places where XP is still exposed with respect to being high-discipline are coding standards, acceptance tests, and aggressive refactoring. Of those, aggressive refactoring probably will remain the most difficult, because it requires consistency, energy, and courage, and no mechanisms in the methodology reinforce it.
There are some high-ceremony (low-tolerance) standards. The policy standards include the use of iterations. Design and programming are done in tiny increments of hours or a few days. Planning and development cycles are two to four weeks, releases one to four months. The testing policy standard is that all unit tests run at 100% for all checked-in code. A policy standard states that the team is to be colocated, with a strong recommendation toward the "caves and commons" seating (Auer 2001).
XP includes within its definition a selection of techniques that the people need to learn: the planning game, the daily stand-up meeting, refactoring, and test-first development.
XP is designed for small, colocated teams aiming to get quality and productivity as high as possible. It does this through the use of rich, short, informal communication paths with emphasis on skill, discipline, and understanding at the personal level, minimizing all intermediate work products.
Adjusting XP
Two traits of XP are controversial: absence of documentation and the restriction to small teams.
Absence of Documentation
We can explore the documentation issue in terms of the cooperative game. XP targets success at the primary goal: delivering software.
It targets succeeding at the secondary goal, setting up for the next game, solely through the tacit knowledge built up within the project team.
The knowledge that binds the group and the design is tacit knowledge: the sum of knowledge of all the people on the team. The tacit knowledge is communicated through osmotic communication, rotation in the pair programming, clear, simple code, and extensive unit tests. People joining the team gain this tacit knowledge by pair programming with experienced people in rotation.
While the attention to tacit knowledge is good, sometimes the sponsors want other deliverables besides the system in operation. They may want usage manuals or paperwork describing the system's design. Even if the customers don't need these things, the organization's executives are likely to want to protect themselves against the eventual disappearance of the team's tacit knowledge.
Although it is not likely that everyone will quit at one time, it is likely that the organization will reduce staff size after the main development period of the project. At that point the tacit knowledge starts to be in jeopardy: If several people leave in quick succession, the new people will not have had enough time to absorb the project details adequately. At that point, the project has neither documents nor tacit knowledge.
XP actually contains a mechanism to deal with this situation: the planning game. It just happens that XP projects to date have not made use of the planning game for this purpose.
In the planning game, the sponsors can write story cards that call for creating documentation instead of new program features. During the planning game, the developers estimate the time it will take to generate the documentation, and the customers prioritize those ones against the stories specifying new features.
-
Закладки
After much coaching for six months, his programs still…
Using the planning game in this way, the sponsors can…
The group of 17 quickly agreed on those value choices.…
13. (FIRST TECHNIQUE). .. your sword now having bounced…
We see an example of needing these normalizing rituals…
The main question is, if you were funding this project,…
That it is people who design software is terribly obvious.…
The industry is littered with projects whose sponsors did…
On a new project, I would use Crystal Orange as a base…
The surprising thing about human success modes is how nebulous…
The chart shows the state of the user stories being worked…
Agility implies maneuverability, a characteristic that…
Crystal Clear is the most tolerant, low-ceremony small-team…
Types of Methodologies Rechtin (1997) categorizes methodologies…
1. Project name, job of person interviewed (the interviewee…
Games are not just for children, although children…
The complete discussion about when and where to apply concurrent…
For us as designers, it was possible to express both…