Agile Software Development
Автор: Alistair Cockburn /
CHAPTER 4. Methodologies Methodology Concepts
-
Часть 2
-
Types of Methodologies
Rechtin (1997) categorizes methodologies themselves as being either normative, rational, participative, or heuristic.
Normative methodologies are based on solutions or sequences of steps known to work for the discipline. Electrical and other building codes in house wiring are examples. In software development, one would include state diagram verification in this category.
Rational methodologies (no connection with the company) are based on method and technique. They would be used for system analysis and engineering disciplines.
Participative methodologies are stakeholder based and capture aspects of customer involvement.
Heuristic methodologies are based on lessons learned. Rechtin cites their use in the aerospace business (space and aircraft design).
As a body of knowledge grows, sections of the methodology move from heuristic to normative and become codified as standard solutions for standard problems. In computer programming, searching algorithms have reached that point. The decision about whether to put people in common or private offices has not.
Most of software http://o-broderie.ru development is still in the stage where heuristic methodologies are appropriate.
Milestones are markers for where interesting things happen in the project. At each milestone, one or more people in some named roles must get together to affect the course of a work product.
Three kinds of milestones are used on projects, each with its particular characteristics. They are
· Publications
· Declarations
In a review, several people examine a work product. With respect to reviews, we care about the following questions: Who is doing the reviewing? What are they reviewing? Who created that item? What is the outcome of the review? Few reviews cause a project to halt; most end with a list of suggestions that are supposed to be incorporated.
A publication occurs whenever a work product is distributed or posted for open viewing. Sending out meeting minutes, checking source code into a configuration-management system, and deploying software to users' workstations are different forms of publication. With respect to publications, we care about the following: What is being published? Who publishes it? Who receives it? What causes it to be published?
The declaration milestone is a verbal notice from one person to another, or to multiple people, that a milestone was reached. There is no object measure for a declaration; it is simply an announcement or a promise. Declarations are interesting because they construct a web of promises inside the team's social structure. This form of milestone came as a surprise to me, when I first detected it. Discovering Declarations
The first declaration milestone I detected was made during a discussion with the manager of the technical writers on a 100-person project. I asked how she knew when to assign a person to start writing the on-line help text (its birth event).
She said it was when a team lead told her that a section of the application was "ready" for her.
I asked her what "ready" meant, whether it meant that the screen design was complete.
She said it only meant that the screen design was relatively stable. The team lead was, in essence, making the following promise:
"We estimate that the changes that we are still going to make are relatively small compared to the work the tech writer will be doing, and the rework the writer will do will be relatively small compared to the overall work. So this would be a good time to get the writing started. "
That assertion is full of social promises. It is a promise, given by a trained person, that in his judgement the tradeoffs are balanced and that this is a good time to start.
A declaration ("It's ready! ") is often the form of milestone that moves code from development to test, alpha delivery, beta delivery, and even deployment.
Declarations are interesting to me as a researcher, because I have not seen them described in process-centric methodologies, which focus on process entry and exit criteria. They are easier to discuss when we consider software development as a cooperative game. In a cooperative game, the project team's web of interrelationships, and the promises holding them together, are more apparent.
The role-deliverable-milestone chart is a quick way to view the methodology in brief and has an advantage over process diagrams in that it shows the parallelism involved in the project quite clearly. It also allows the team to see the key stages of completion the artifacts go through. This helps them manage their actions according to the intermediate states of the artifacts, as recommended in some modern methodologies (Highsmith 1999).
Figure 4-2. The three dimensions of scope.
The scope of a methodology consists of the range of roles and activities that it attempts to cover (Figure 4-2).
The earliest object-oriented methodologies presented the designer as having the key role and discussed the techniques, deliverables, and standards for the design activity of that role. These methodologies were considered inadequate in two ways:
· They were not as broad as needed. A real project involves more roles than just the OO designer, and each role involves more activities, more deliverables, and more techniques than these books presented.
· They were too constricting. Designers need more than one design technique in their toolbox.
Groups with a long history of continuous experience, such as the U. S. Department of Defense, Andersen Consulting, James Martin and Associates, IBM, and Ernst Young already had methodologies covering the standard life-cycle of a project, even starting from the point of project sales and project setup. Their methodologies cover every person needed on the project, from staff assistant through sales staff, designer, project manager, and tester.
-