Agile Software Development
Автор: Alistair Cockburn /
CHAPTER 4. Methodologies Methodology Design Principles
-
Часть 6
-
This principle contains a catch, though.
If you try to increase productivity by removing more and more methodology elements, you eventually remove those that address code quality. At some point the strategy backfires, and the team spends more time repairing bad work than making progress.
The key word, of course, is excess. Different methodology authors produce different advice as to where "excess" methodology begins. Based on the strengths of people we have discussed so far—being communicating beings and being good citizens—I find that a project can do with a lot less methodology than most managers expect. Jim Highsmith is more explicit about this. His suggestion would be that you start lighter than you think will possibly work!
There are two points to draw from this discussion:
· Adding a "small" amount of bureaucratic burden to a project adds a large cost.
· Some part of the methodology should address the quality of the output.
Principle 3. Larger teams need heavier methodologies.
With only four or six people on the team, it is practical to put them together in a room with printing whiteboards and allow the convection currents of information to bind the ongoing conversation in their cooperative game of invention and communication. After the team size exceeds 8 or 12 people, though, that strategy ceases to be so effective. As it reaches 30-40 people, the team will occupy a floor. At 80 or 100 people, the team will be spread out on multiple floors, in multiple buildings, or in multiple cities.
With each increase in size, it becomes harder for people to know what others are doing and how not to overlap, duplicate, or interfere with each other's work. As the team size increases, so does the need for some form of coordination and communication.
Figure 4-17 shows the effect of adding methodology to a large team. With very light methodologies, they work without coordination. As they start to coordinate their work, they become more effective (this is the left half of the curve). Eventually, for any size group, diminishing returns set in and they start to spend more time on the bureaucracy than on developing the system (the right half of the curve).
Principle 2 describes the left half of the curve: "Larger teams need heavier methodologies. " The right half of the curve is described in Principle 3, "Excess methodology weight is costly. "
Principle 4. Greater ceremony is appropriate for projects with greater criticality.
This principle addresses ceremony and tolerance, as discussed in the second section of this chapter. A Portfolio of Projects
In the IT department of the Central Bank of Norway, we worked on many kinds of projects.
One was to allow people to order dinners from the cafeteria when they worked late.
One was to provide SQL programming support for staff who were investigating financialinvestments.
A third was to track all the bank-to-bank transactions in the country. A fourth was to convert the entire NB system to be Year-2000 safe.
The cost of leaving a fault in the third and fourth systems was quite different from the cost of leaving a fault in the first two. I use the word criticality for this distinction. It was more critical to get the work correct in the latter two than in the former two projects.
Just as communications load affects the appropriate choice of methodology, so does criticality. I have chosen to divide criticality into four categories, according to the loss caused by a defect showing up in operation:
· Loss of comfort. The cafeteria produces lasagne instead of a pizza.
At the worst, the person eats from the vending machine.
· Loss of discretionary moneys. Invoicing systems typically fall into this category.
If a phone company sends out a billing mistake, the customer phones in and has the bill adjusted.
Many project managers would like to pretend that their project causes more damage than this, but in fact, most systems have good human backup procedures, and mistakes are generally fixed with a phone call. I was surprised to discover that the bank-to-bank transaction tracking system actually fit into this category. Although the numbers involved seemed large to me, they were the sorts of numbers that the banks dealt in all the time, and they had human backup mechanisms to repair computer mistakes.
· Loss of essential moneys.
Your company goes bankrupt because of certain errors in the program. At this level of criticality, it is no longer possible to patch up the mistake with a simple phone call.
Very few projects really operate at this level. I was recently surprised to discover two.
One was a system that offered financial transactions over the Web. Each transaction could be repaired by phone, but there were 50, 000 subscribers, estimated to become 200, 000 in the following year, and a growing set of services being offered. The call-in rate was going to increase by leaps and bounds. The time cost of repairing mistakes already fully consumed the time of one business expert who should have been working on other things and took up almost half of another business expert's time. This company decided that it simply could not keep working as though mistakes were easily repaired.
The second was a system to control a multiton, autonomous vehicle. Once again, the cost of a mistake was not something to be fixed with a phone call and some money. Rather, every mistake of the vehicle could cause very real, permanent, and painful damage. · Loss of life.
-
Закладки
The third problem is absence of feedback from the downstream…
Figure 4-1. Elements of a methodology. Roles. Who you…
13. (FIRST TECHNIQUE). .. your sword now having bounced…
Games are not just for children, although children also play…
The chart shows the state of the user stories being worked…
We see an example of needing these normalizing rituals…
It follows that on the Theory Building View, for the…
In arguing for the Theory Building View, the basic issue…
Crystal Clear is the most tolerant, low-ceremony small-team…
For us as designers, it was possible to express both…
1. Project name, job of person interviewed (the interviewee…
While writing, reading, typing, or talking, we pick up traces…
The industry is littered with projects whose sponsors did…
The complete discussion about when and where to apply concurrent…
Types of Methodologies Rechtin (1997) categorizes methodologies…
Agility implies maneuverability, a characteristic that is…
After much coaching for six months, his programs still…
That it is people who design software is terribly obvious. ..…
Walk around your place of work. Notice · The convection currents…
Using the planning game in this way, the sponsors can…