Agile Software Development
Автор: Alistair Cockburn /
CHAPTER 4. Methodologies Methodology Design Principles
-
Часть 8
-
Jim's third distinction is, "Don't confuse formality with skill. "
Insurance companies are in an unusual situation. We fills in forms, send them to the insurance back office, and receive insurance policies. This is quite amazing. Probably as a consequence of their living in this unusual realm, I have several times been asked by insurance companies to design use case and object-oriented design forms. Their goal, I was told on each occasion, was to make it fool-proof to construct high-quality use cases and OO designs.
Sadly, our world is not built that way. A good designer will read a set of use cases and create an OO design directly, one that improves as he reworks the design over time. No amount of form filling yet replaces this skill. Similarly, a good user interface designer creates much better programs than a mediocre interface designer can create. .
Figure 4-22 shows a merging of Jim's and my thoughts on these issues.
Figure 4-22. Documentation is not understanding, process is not discipline, formality is not skill.
Jim distinguishes exploratory or adapting activities from optimizing activities. The former, he says, is exemplified by the search for new oil wells.
In searching for a new oil well, one cannot predict what is gong to happen. After the oil well is functioning, however, the task is to keep reducing costs in a predictable situation.
In software development, we become more like the optimizing oil company as we become more familiar with the problem to be solved, the team, and the technologies being used. We are more like the exploratory company, operating in an adaptive mode, when we don't know those things.
Light methodologies draw on understanding, discipline, and skill more than on documentation, process, and formality. They are therefore particularly well suited for exploratory situations. The typical heavy methodology, drawing on documentation, process, and formality, is designed for situations in which the team will not have to adapt to changing circumstances but can optimize its costs.
Of the projects I have seen, almost all fit the profile of exploratory situations. This may explain why I have only once seen a project succeed using an optimizing style of methodology. In that exceptional case, the company was still working in the same problem domain and was using the same basic technology, process, and architecture as it had done for several decades.
The characteristics of exploratory and optimizing situations run in opposition to each other. Optimizing projects try to reduce the dependency on tacit knowledge, personal skill, and discipline and therefore rely more on documentation, process, and formality. Exploratory projects, on the other hand, allow people to reduce their dependency on paperwork, processes, and formality by relying more on understanding, discipline, and skill. The two sets draw away from each other.
Jim and I hypothesize that any methodology design will live on the track shown in the figure, drawing either to one set or the other, but not both.
Principle 7. Efficiency is expendable in non-bottleneck activities.
Principle 7 provides guidance in applying concurrent development, and is a key principle in tailoring the Crystal methodologies for different teams in different situations. It is closely related to Elihu Goldratt's ideas as expressed in The Goal (Goldratt 1992) and The Theory of Constraints (Goldratt 1990).
To get a start on the principle, imagine a project with five requirements analysts, five Smalltalk programmers, five testers, and one relational database designer (DBA), all of them good at their jobs. Let us assume, for the sake of this example, that the group cannot hire more DBAs. Figure 4-23 shows the relevant part of the situation, the five programmers feeding work to the single DBA.
Figure 4-23. The five Smalltalk programmers feeding work to the one DBA.
The DBA clearly won't be able to keep up with the programmers. This has nothing to do with his skills, it is just that he is overloaded. In Goldratt's terms, the DBA's activity is the bottleneck activity. The speed of this DBA determines the speed of the project.
To make good progress, the team had better get things lined up pretty well for the DBA so that he has the best information possible to do his work. Every slowdown, every bit of rework he does, costs the project directly.
That is quite the opposite story from the Smalltalk programmers. They have a huge amount of excess capacity compared with the DBA.
Faced with this situation, the project manager can do one of two things:
· Send four of the programmers home so that the Smalltalk programmers and the DBA have matched capacities.
· Make use of the programmers' extra capacity. If he is mostly interested in saving money, then he sends four of the programmers home and lives with the fact that the project is going to progress at the speed of these two solo developers.
If he is interested in getting the project done as quickly as possible, he doesn't send the four Smalltalk programmers home. He takes advantage of their spare capacity.
He has them revise their designs several times, showing the results to users, before they hand over their designs to the DBA. This way, they get feedback that enables them to change their designs before, not after, the DBA goes through his own work.
-
Закладки
Agility implies maneuverability, a characteristic that is…
The surprising thing about human success modes is how…
While writing, reading, typing, or talking, we pick up…
That it is people who design software is terribly obvious.…
The group of 17 quickly agreed on those value choices.…
We see an example of needing these normalizing rituals in the…
The third problem is absence of feedback from the downstream…
1. Project name, job of person interviewed (the interviewee…
Crystal Clear is the most tolerant, low-ceremony small-team methodology…
Walk around your place of work. Notice · The convection currents…
The complete discussion about when and where to apply…
Figure 4-1. Elements of a methodology. Roles. Who you employ,…
The main question is, if you were funding this project, which…
Types of Methodologies Rechtin (1997) categorizes methodologies…
The chart shows the state of the user stories being worked…
After much coaching for six months, his programs still looked…
In arguing for the Theory Building View, the basic issue…
The industry is littered with projects whose sponsors did…