Agile Software Development
Автор: Alistair Cockburn /
CHAPTER 4. Methodologies Methodology Design Principles
-
Часть 7
-
Software to control the movement of the rods in a nuclear reactor fall into this category, as do pacemakers, atomic power plant control, and the space shuttles. Typically, members of teams whose programs can kill people know they are working on such a project and are willing to take more care.
As the degree of potential damage increases, it is easy to justify greater development cost to protect against mistakes. In keeping with the second principle, adding methodology adds cost, but in this case, the cost is worth it. The cost goes into defect reduction rather than communications load.
Principle 4 addresses the amount of ceremony that should be used on a project. Recall that ceremony refers to the tightness of the controls used in development and the tolerance permitted. More ceremony means tighter controls and less tolerance.
Consider a team-building software for the neighborhood bowling league. The people write a few sentences for each use case, on scraps of paper or a word processor. They review the use cases by gathering a few people in a room and asking what they think.
Consider, in contrast, a different team-building software for a power plant. These people use a particular tool, fill in very particular fields in a common template, keep versions of each use case, and adhere to strong writing style conventions. They review, baseline, change control, and sign off the use cases at several stages in the life cycle.
The second set of use cases is more expensive to develop. The team works that way, though, expecting that fewer mistakes will be made. The team justifies being less tolerant of variation by the added safety of the final result.
Principle 5. Increasing feedback and communication reduce the need for intermediate deliverables.
Recall that a deliverable is a work product that crosses decision boundaries. An intermediate deliverable is one that is passed across decision boundaries within the team. These might include the detailed project plan, refined requirement documents, analysis and design documents, test plans, inter-team dependencies, risk lists, etc.
I refer to them also as "promissory notes, " as in:
"I promise that the system will look like these requirements describe. "
"I promise that this analysis model will work as the core for the system's design. "
"I promise that this design will work well over time. " There are two ways to reduce the need for promissory notes:
1. Deliver a working piece of the system quickly enough that the sponsor can tell whether the team understood the requirements properly. Delivering a working piece of the system quickly leads to these other benefits:
· The requirements writers will be able to tell whether the requirements they wrote are actually going to meet the user’s needs.
· The team needs fewer requirements reviews and can often simplify the requirements process in other ways.
· The designers can see the effects of their decisions early rather than after many other decisions have been built on top of a mistake.
· Test planning becomes much simpler. Sometimes another intermediate work product, the Test Plan, can be replaced by the running test cases.
2. Reduce the team size, putting everyone close enough together that they can simply tell each other what they are doing instead of writing internal documents to each other.
Note the word internal. The sponsors may still require written documentation of different sorts as part of the external communication needs.
Principle 6. Discipline, skills, and understanding counter process, formality, and documentation.
When Jim Highsmith says, "Don't confuse documentation with understanding, " he means that much of the knowledge that binds the project is tacit knowledge, knowledge that people have inside them, not on paper anywhere.
The knowledge base of a project is immense, and much of that knowledge consists of knowing the team's rituals of negotiation, which person knows what information, who contributed heavily in the last release, what pieces of discussion went into certain design decisions, and so on. Even with the best documentation in the world, a new team cannot necessarily just pick up where the previous team left off. The new team will not start making progress until the team members build up their tacit knowledge base.
When referring to "documentation" for a project, be aware that the knowledge that becomes documentation is only a small part of what there is to know. People who specialize in technology transfer know this. As the one IBM Fellow put it, "The way to get effective technology transfer is not to transfer the technology itself but to transfer the heads that hold the technology! " ("Jumping Gaps across Time, " on page? ?? [insert cross ref])
Jim continues, "Process is not discipline. " Discipline involves a person choosing to work in a way that requires consistency. Process involves a person following instructions. Of the two, discipline is the more powerful. A person who is choosing to act with consistency and care will have a far better effect on the project than a person who is just following instructions.
The common mistake is in thinking that somehow a process will impart discipline.
-
Закладки
After much coaching for six months, his programs still…
Games are not just for children, although children also play…
For us as designers, it was possible to express both propositional…
The industry is littered with projects whose sponsors did not…
1. Project name, job of person interviewed (the interviewee…
On a new project, I would use Crystal Orange as a base methodology…
Types of Methodologies Rechtin (1997) categorizes methodologies…
While writing, reading, typing, or talking, we pick up traces…
Using the planning game in this way, the sponsors can properly…
In arguing for the Theory Building View, the basic issue…
Crystal Clear is the most tolerant, low-ceremony small-team…
Figure 4-1. Elements of a methodology. Roles. Who you employ,…
It follows that on the Theory Building View, for the primary…
Accepting program modifications demanded by changing external…
Walk around your place of work. Notice · The convection currents…
The group of 17 quickly agreed on those value choices.…
The third problem is absence of feedback from the downstream…