Agile Software Development
Автор: Alistair Cockburn /
CHAPTER 4. Methodologies Methodology Concepts
-
Часть 4
-
Relevance Whether or not to speak about a topic. User interface prototypes do not discuss the domain model. Infrastructure design is not relevant to collecting user functional requirements. Methodologies discuss different areas of relevance.
Tolerance How much variation is permitted.
The team standards may require revision dates to be put into the program code—or not. The tolerance statement may say that a date must be found, either put in by hand or added by some automated tool. A methodology may specify line breaks and indentation, leave those to peoples' discretion, or state acceptable bounds. An example in a decision standard is stating that a working release must be available every 3 months, plus or minus one month.
Visibility How easily an outsider can tell if the methodology is being followed. Process initiatives such as ISO9001 focus on visibility issues. Because achieving visibility creates overhead (cost in time, money, or both), agile methodologies as a group lower the emphasis on such visibility. As with ceremony, different amounts of visibility are appropriate for different situations. Scale How many items are rolled together to be presented as a single item. Booch's former "class categories" provided for a scaled view of a set of classes. The UML "package" allows for scaled views of use cases, classes, or hardware boxes. Project plans, requirements, and designs can all be presented at different scales.
Scale interacts somewhat with precision. The printer or monitor's dot density limits the amount of detail that can be put onto one screen or page. However, even if it could all be put onto one page, some people would not want to see all that detail. They want to see a rolled-up or high-level version.
Stability How likely it is to change. I use only three stability levels: wildly fluctuating, as when a team is just getting started; varying, as when some development activity is in mid-stride; and relatively stable, as just before a requirements / design / code review or product shipment.
One way to find the stability state is to ask: "If I were to ask the same questions today and in two weeks, how likely would I be to get the same answers? "
In the wildly fluctuating state, the answer is "Are you kidding? Who knows what this will be like in two weeks! "
In the varying state, the answer is "Somewhat similar, but of course the details are likely to change. "
In the relatively stable state, the answer is "Pretty likely, although a few things will probably be different. "
Other ways to determine the stability may include measuring the "churn" in the use case text, the diagrams, the code base, the test cases, and so on (I have not tried these).
Figure 4-5. A project map: a low-precision version of a project plan.
Precision is a core concept manipulated within a methodology. Every category of work product has low-, medium-, and high-precision versions.
Here are the low-, medium-, and high-precision versions of some key work products.
The Project Plan
The low-precision view of a project plan is the project map (Figure 4-5). It shows the fundamental items to be produced, their dependencies, and which are to be deployed together. It may show the relative magnitudes of effort needed for each item. It does not show who will do the work or how long the work will take (which is why it is called a map and not a plan).
Those who are used to working with PERT charts will recognize the project map as a coarse-grained PERT chart showing project dependencies, augmented with marks showing where releases occur.
This low-precision project map is very useful in organizing the project before the staffing and timelines are established. In fact, I use it to derive timelines and staffing plans.
The medium-precision version of the project plan is a project map expanded to show the dependencies between the teams and the due dates.
The high-precision version of the project plan is the well-known, task-based GANTT chart, showing task times, assignments, and dependencies.
The more precision in the plan, the more fragile it is, which is why constructing GANTT charts is so feared: it is time-consuming to produce and gets out of date with the slightest surprise event. Behavioral Requirements / Use Cases Behavioral requirements are often written with use cases.
The lowest level of precision version of a set of use cases is the Actors-Goals list, the list of primary actors and the goals they have with respect to the system (Figure 4-6). This lowest-precision view is useful at the start of the project when you are prioritizing the use cases and allocating work to teams. It is useful again whenever an overview of the system is needed.
Figure 4-6. An Actors-Goals list: the lowest-precision view of behavioral requirements.
The medium level of precision consists of a one-paragraph brief synopsis of the use case, or the use case's title and main success scenario.
The medium-high level of precision contains extensions and error conditions, named but not expanded.
The final, highest level of precision includes both the extension conditions and their handling.
These levels of precision are further described in (Cockburn 2000).
The Program Design
The lowest level of precision in an object-oriented design is a Responsibility-Collaborations diagram, a very coarse-grained variation on the UML object collaboration diagram (Figure 4-7). The interesting thing about this simple design presentation is that people can already review it and comment on the allocation of responsibilities.
A medium level of precision is the list of major classes, their major purpose, and primary collaboration channels.
-
Закладки
The complete discussion about when and where to apply…
Accepting program modifications demanded by changing…
For us as designers, it was possible to express both propositional…
The chart shows the state of the user stories being worked on…
After much coaching for six months, his programs still…
13. (FIRST TECHNIQUE). .. your sword now having bounced…
Using the planning game in this way, the sponsors can…
Walk around your place of work. Notice · The convection currents…
Figure 4-1. Elements of a methodology. Roles. Who you…
On a new project, I would use Crystal Orange as a base…
The surprising thing about human success modes is how…
1. Project name, job of person interviewed (the interviewee…
We see an example of needing these normalizing rituals in…
Games are not just for children, although children also…
While writing, reading, typing, or talking, we pick up…
Agility implies maneuverability, a characteristic that…
The third problem is absence of feedback from the downstream…