Agile Software Development
Автор: Alistair Cockburn /
CHAPTER 4. Methodologies Methodology Design Principles
-
Часть 5
-
Beware the methodology author. Your experiences with a methodology may have a lot to do with how well your personal habits align with those of the methodology author.
Seven Principles
Over the years, I have found seven principles that are useful in designing and evaluating methodologies:
1. Interactive, face-to-face communication is the cheapest and fastest channel for exchanging information.
2. Excess methodology weight is costly.
3. Larger teams need heavier methodologies.
4. Greater ceremony is appropriate for projects with greater criticality.
5. Increasing feedback and communication lowers the need for intermediate deliverables.
6. Discipline, skills, and understanding counter process, formality, and documentation.
7. Efficiency is expendable in non-bottleneck activities.
Following is a discussion of each principle.
Principle 1. Interactive, face-to-face communication is the cheapest and fastest channel for exchanging information.
The relative advantages and appropriate uses of warm and cool communications channels was discussed in the last chapter. Generally speaking, we should prefer to use warmer communication channels in software development, since we are interested in reducing the cost of detecting and transferring information.
Principle 1 predicts that people sitting near each other with frequent, easy contact will find it easier to develop software, and the software will be less expensive to develop. As the project size increases and interactive, face-to-face communications become more difficult to arrange, the cost of communication increases, the quality of communication decreases, and the difficulty of developing the software increases.
Figure 4-16. Effectiveness of different communication channels (Repeat of Figure 3-14).
The principle does not say that communication quality decreases to zero, nor does it imply that all software can be developed by a few people sitting in a room. It implies that a methodology author might want to emphasize small groups and personal contact if productivity and cost are key issues. The principle is supported by management research (Plowman 1995, Sillince 1996, among others). [double-check refs]
We also used Principle 1 in the story, "Videotaped Archival Documentation, " on page? ?? [insert cross ref], which describes documenting a design by videotaping two people discussing that design at a whiteboard.
The principle addresses one particular question: "How do forms of communication affect the cost of detecting and transferring information? "
One could ask other questions to derive other, related principles. For example, it might be interesting to uncover a principle to answer this question: "How do forms of communication affect a sponsor's evaluation of a team's conformance to a contract? " This question would introduce the issue of visibility in a methodology. It should produce a very different result, probably one emphasizing written documents.
Principle 2. Excess methodology weight is costly.
Imagine six people working in a room with osmotic communication, drawing on the printing whiteboard. Their communication is efficient, the bureaucratic load low. Most of their time is spent developing software, the usage manual, and any other documentation artifacts needed with the end product.
What size problem can a given number of people attack, using various methodology weights?
Problem size
Many people using a heavier methodology
Many people using a very heavy methodology
Many people using a light methodology
Methodology Weight
Figure 4-17. Effect of adding methodology weight to a large team.
Now ask them to maintain additional intermediate work products, written plans, GANTT charts, requirements documents, analysis documents, design documents, and test plans. In the imagined situation, they are not truly needed by the team for the development. They take time away from development.
Productivity under those conditions decreases. As you add elements to the methodology, you add more things for the team to do, which pulls them away from the meat of software development.
What size problem can a given number of people attack, using various methodology weights?
Problem size a few people using a light methodology a few people using a heavy methodology.
Methodology Weight
Figure 4-18. Effect of adding methodology weight to a small team.
In other words, a small team can succeed with a larger problem by using a lighter methodology (Figure 4-18).
Methodology elements add up faster than people expect. A process designer or manager requests a new review or piece of paperwork that should "only take a half hour from time to time. " Put a few of these together, and suddenly the designers lose an additional 15-20% of their already cramped week. The additional work items disrupt design flow. Very soon, the designers are trying to get their design thinking done in one- or two-hour blocks which, as you saw earlier, does not work well.
This is something I often see on projects: designers unable to get the necessary quiet time to do their work because of the burden of paperwork and the high rate of distractions.
-
Закладки
The complete discussion about when and where to apply concurrent…
Games are not just for children, although children also play…
The group of 17 quickly agreed on those value choices. Developing…
The surprising thing about human success modes is how nebulous…
Using the planning game in this way, the sponsors can…
Walk around your place of work. Notice · The convection…
In arguing for the Theory Building View, the basic issue…
That it is people who design software is terribly obvious.…
While writing, reading, typing, or talking, we pick up traces…
We see an example of needing these normalizing rituals…
The main question is, if you were funding this project, which…
It follows that on the Theory Building View, for the…
Types of Methodologies Rechtin (1997) categorizes methodologies…
Accepting program modifications demanded by changing external…
After much coaching for six months, his programs still looked…
The chart shows the state of the user stories being worked…
The third problem is absence of feedback from the downstream…
For us as designers, it was possible to express both propositional…
Figure 4-1. Elements of a methodology. Roles. Who you…
The industry is littered with projects whose sponsors…