Agile Software Development
Автор: Alistair Cockburn /
CHAPTER 4. Methodologies Methodology Concepts
-
Часть 3
-
The point is that both are "methodologies. " The scope of their concerns is different.
The scope of a methodology can be characterized along three axes: lifecycle coverage, role coverage, and activity coverage (Figure 4-3).
· Life-cycle coverage indicates when in the life cycle of the project the methodology comes into play, and when it ends.
· Role coverage refers to which roles fall into the domain of discussion.
· Activity coverage defines which activities of those roles fall into the domain of discussion. The methodology may take into account filling out time sheets (a natural inclusion as part of the project manager's project monitoring and scheduling assignment) and may omit vacation requests (because it is part of basic business operations).
Figure 4-3. Scope of Extreme Programming.
Clarifying a methodology's intended scope helps take some of the heat out of methodology arguments. Often, two seemingly incompatible methodologies target different parts of the life cycle or different roles. Discussions about their differences go nowhere until their respective scope intentions are clarified.
In this light, we see that the early OO methodologies had a relatively small scope. They addressed typically only one role, the domain designer or modeler. For that role, only the actual domain modeling activity is represented, and only during the analysis and design stages. Within that very narrow scope, they covered one or a few techniques and outlined one or a few deliverables with standards. No wonder experienced designers felt they were inadequate for overall development.
The scope diagram helps us see where methodology fragments combine well. An example is the natural fit of Constantine and Lockwood's user interface design recommendations (Constantine 1999) with methodologies that omit discussion of UI design activities (leaving that aspect to authors who know more about the subject).
Figure 4-4. Scope of Constantine Lockwood's Design for Use methodology fragment.
Without having these scoping axes at hand, people would ask Larry Constantine, "How does your methodology relate to the other Agile Methodologies on the market? " In a talk at Software Development 2001, Larry Constantine said he didn't know he was designing a methodology, he was just discussing good ways to design user interfaces.
Having the methodology scope diagram in view, we easily see how they fit. XP's scope of concerns is shown in Figure 4-3. Note that it lacks discussion of user interface design. The scope of concerns for Design for Use is shown in Figure 4-4. We see, from these figures, that the two fit together. The same applies for Design for Use and Crystal Clear.
Conceptual Terms
To discuss the design of a methodology, we need different terms: methodology size, ceremony, and weight, problem size, project size, system criticality, precision, accuracy, relevance, tolerance, visibility, scale, and stability.
Methodology Size The number of control elements in the methodology. Each deliverable, standard, activity, quality measure, and technique description is an element of control. Some projects and authors will wish for smaller methodologies; some will wish for larger.
Ceremony The amount of precision and the tightness of tolerance in the methodology. Greater ceremony corresponds to tighter controls (Booch 1995). One team may write use cases on napkins and review them over lunch. Another team may prefer to fill in a three-page template and hold half-day reviews. Both groups write and review use cases, the former using low ceremony, the latter using high ceremony.
The amount of ceremony in a methodology depends on how life critical the system will be and on the fears and wishes of the methodology author, as we will see. Methodology Weight The product of size and ceremony, the number of control elements multiplied by the ceremony involved in each. This is a conceptual product (because numbers are not attached to size and ceremony), but it is still useful.
Problem Size The number of elements in the problem and their inherent cross-complexity.
There is no absolute measure of problem size, because a person with different knowledge is likely to see a simplifying pattern that reduces the size of the problem. Some problems are clearly different enough from others that relative magnitudes can be discussed (launching a space shuttle is a bigger problem than printing a company's invoices).
The difficulty in deciding the problem size is that there will often be controversy over how many people are needed to deliver the product and what the corresponding methodology weight is.
Project Size The number of people whose efforts need to be coordinated: staff size. Depending on the situation, you may be coordinating only programmers or an entire department with many roles.
Many people use the phrase "project size" ambiguously, shifting the meaning from staff size to problem size even within a sentence. This causes much confusion, particularly because a small, sharp team often outperforms a large, average team.
The relationship between problem, staff, and methodology size are discussed in the next section.
System Criticality The damage from undetected defects. I currently classify criticality simply as one of loss of comfort, loss of discretionary money, loss of irreplaceable money, or loss of life. Other classifications are possible.
Precision How much you care to say about a particular topic. Pi to one decimal place of precision is 3. 1, to four decimal places is 3. 1416. Source code contains more precision than a class diagram; assembler code contains more than its high-level source code. Some methodologies call for more precision earlier than others, according to the methodology author's wishes.
Accuracy How correct you are when you speak about a topic. To say "Pi to one decimal place is 3. 3" would be inaccurate. The final object model needs to be more accurate than the initial one. The final GUI description is more accurate than the low-fidelity prototypes. Methodologies cover the growth of accuracy as well as precision.
-
Закладки
Agility implies maneuverability, a characteristic that…
For us as designers, it was possible to express both propositional…
On a new project, I would use Crystal Orange as a base methodology…
Accepting program modifications demanded by changing…
Using the planning game in this way, the sponsors can properly…
The complete discussion about when and where to apply…
The surprising thing about human success modes is how nebulous…
The chart shows the state of the user stories being worked…
Games are not just for children, although children also play…
That it is people who design software is terribly obvious. ..…
After much coaching for six months, his programs still looked…
Figure 4-1. Elements of a methodology. Roles. Who you employ,…
Types of Methodologies Rechtin (1997) categorizes methodologies…
While writing, reading, typing, or talking, we pick up traces…
The third problem is absence of feedback from the downstream…
13. (FIRST TECHNIQUE). .. your sword now having bounced…
1. Project name, job of person interviewed (the interviewee…
The industry is littered with projects whose sponsors did…