Agile Software Development
Автор: Alistair Cockburn /
CHAPTER 2. Individuals Overcoming Failure Modes
-
Часть 3
-
Beck (1999) and Jeffries (2000) described pair programming and test-first design in the context of Extreme Programming.
Careful design checking and statistical testing were detailed in the Cleanroom methodology (Becker 1996).
Humphreys (1996), in his Personal Software Process, provided detailed instructions about how programmers can become more effective through checking where errors are introduced.
Consistent application of any of the above ideas would improve most of the projects I have visited. As Karl Wiegers quipped, "We are not short on practices; we are short on practice. "
Countering with Discipline and Tolerance
Methodologists deal with people's common weaknesses with tolerance or discipline:
· Design the methodology to be tolerant of individual variations.
· Create mechanisms in the methodology that hold strict behavioral standards in place.
Most choose discipline.
Because consistency in action is a human weakness, high-discipline methodologies are fragile. Even when they contain good practices, people are unlikely to keep performing those practices over time. Performing a disciplined activity daily is just as hard in software development as keeping the desk clear in the clean-desk technique just mentioned.
To remain in practice, a high-discipline methodology must contain specific element(s) that keep the discipline in place.
Let's look briefly at three high-discipline methodologies: Cleanroom, Personal Software Process, and Extreme Programming.
In Cleanroom, production code is not allowed to be compiled before being checked in. Typing errors and syntax errors are considered part of the statistical process being controlled (new language features and system calls are learned on nonproduction code). The team doing the compiling can then detect the rate at which errors are introduced during program entry.
This is a high-discipline rule and requires explicit management support and checks.
In the Personal Software Process, the practitioner is to write down how long each activity took and to tabulate at what point errors got introduced. From these notes, the person can determine which activities are most error-prone and concentrate more carefully next time. The difficulty is, of course, that the logs take effort to maintain, requiring consistency of action over time. Not producing them properly invalidates PSP.
PSP contains no specific mechanisms to hold the high-discipline practices in place. It is, therefore, not terribly surprising to find the following experience report coming from even a highly disciplined development group. The following words about PSP were written by a military group that had been trained in PSP and had achieved the Software Engineering Institute's Capability Maturity Model Level 5 rating (Webb 1999):
During the summer of 1996, TIS introduced the PSP to a small group of software engineers. Although the training was generally well received, use of the PSP in TIS started to decline as soon as the classes were completed. Soon, none of the engineers who had been instructed in PSP techniques was using them on the job.
When asked why, the reason was almost unanimous: "PSP is extremely rigorous, and if no one is asking for my data, it's easier to do it the old way. "
Extreme Programming is the third methodology to call for high-discipline practices. It calls for programming in pairs (with pair rotation), extensive and automated unit tests completed prior to code check-in each day, adherence to the group's coding standards, and aggressive refactoring of the code base.
Based on the discussion above, I expected to find adherence to the XP practices to be short-lived in most groups. My interview results were somewhat surprising, though.
People report programming in pairs to be enjoyable. They therefore program in pairs quite happily, after they adapt to each other's quirks. While programming in pairs, they find it easier to talk each other into writing the test cases and adhere to the coding standards.
The main part of XP that is high-discipline and resistant to the pressure of programming in pairs is the code refactoring work. I still find that most people on the team do not refactor often, generally leaving that to the senior project person.
However, unlike PSP, Extreme Programming contains a specific mechanism to help with the discipline. It calls for one person to act as "coach" and keep the team sensitive to the way in which they are using the practices.
It is interesting to note that all three of these methodologies were invented by people who were, themselves, consistent in the habits they required. So it is not as though high-discipline methods can't be used. They just are "fragile. "
The alternative to requiring discipline is being tolerant of individual variation.
Adaptive Software Development (Highsmith 2000) and the Crystal methodology family described in this book (Cockburn 2002) are the only two methodologies I know that are explicitly about being "variation tolerant. " Each methodology calls for the
Reminding ourselves that people vary, that certain broad generalizations hold, and that there are exceptions team members to form consensus on the minimum compliance needed in the work products and practices. Each suggests the use of standards but does require that standards be enforced.
For "tolerant" methodologies to work, the people on the project must care about citizenship issues and generally take pride in their work. In such projects, the people develop a personal interest in seeing that their work is acceptable. Getting this to happen is no more guaranteed than getting people to follow standards, but I do see it accomplished regularly. It was also reported by Dixon (2000, p. 32).
Which is better: high-discipline or high-tolerance methodologies?
· Strict adherence to strict (and effective) practices should be harder to attain but may be more productive in the end.
· Tolerant practices should be easier to get adopted but may be less productive.
Part of the difficulty in choosing between them is that there currently is no consensus as to which practices are effective or ineffective under various circumstances. As a result, project leaders might enforce strict adherence to practices they considered effective and be surprised at the negative result they encounter.
The "Continuous Redocumentation" story in the last chapter gave one example of false adherence to discipline. The sponsors required that every change to any part of the system be immediately reflected in all documentation. They probably thought this would be an effective practice. In their context, though, it proved too costly, and the project was canceled.
In other words, while strict adherence to effective practices leads to an effective team, strict adherence to ineffective practices leads to an ineffective team.
If only we knew which was which. To each generalization, let's look at some of people's natural ways of working.
-
Навигация [ Часть 3. Глава 8. ]
Закладки
It follows that on the Theory Building View, for the primary…
Using the planning game in this way, the sponsors can…
In arguing for the Theory Building View, the basic issue…
Accepting program modifications demanded by changing external…
1. Project name, job of person interviewed (the interviewee…
Games are not just for children, although children also…
The third problem is absence of feedback from the downstream…
Figure 4-1. Elements of a methodology. Roles. Who you…
For us as designers, it was possible to express both propositional…
The industry is littered with projects whose sponsors did…
Crystal Clear is the most tolerant, low-ceremony small-team methodology…
13. (FIRST TECHNIQUE). .. your sword now having bounced upward,…
Walk around your place of work. Notice · The convection currents…
The chart shows the state of the user stories being worked…
The complete discussion about when and where to apply concurrent…
After much coaching for six months, his programs still…
Agility implies maneuverability, a characteristic that is…