Agile Software Development
Автор: Alistair Cockburn /
INTRODUCTION The Impossibility of Communication
-
Часть 4
-
Figure I-1. One arc and an arc pair.
From these and some small circles I put together the next shape, which looks a bit like an owl’s face (Figure I-2). At this point, notice that I have biased your future perception of these shapes. One of the points in this discussion is the bias created by my giving you the name of the shape early on.
Figure I-2. Arcs forming a face.
Putting two owl heads together produces pictures that might look like lima beans, faces, an apple core, or some other shape that you choose to name (Figure I-3).
Figure I-3. Apple cores?
Finally, I build the picture I had in mind (Figure I-4). What do you see in it? How do you parse it into distinguishable sections? Do you see eye shades, embryos, or lima beans? Do you see two yin-yang shapes?
Figure I-4. Complex circle.
Actually, I had in mind two overlapping yin-yang shapes (Figure I-5). Nothing in my intention had to do with arcs, owls, apple cores, or embryos. All of those were secondary effects, artifacts that showed up when I combined the two yin and yang icons, one mirrored and rotated from the other, and parsed the picture according to a different pattern.
The point of my presenting the images in a different order is to illustrate three things:
· Any complex shape can be parsed according to different patterns.
· Our perception about "what is there" proceeds in different directions depending on how we separate elements.
· What we notice is biased by the vocabulary we start with.
Figure I-5. Yin and Yang.
In software development, each person uses his own pattern to parse the experience of being on a project. Each person also falls prey to common errors.
A person might have the notion that humidity is a critical success factor in software development. This person would consequently spend a great deal of effort on measuring and controlling the humidity on projects. A person who is really convinced that humidity is key would not notice for a long time that no great correlation exists between humidity and project outcome. Since I don't have humidity in my project parsing pattern, I couldn't tell you what the humidity was in each of my projects, how it varied over time, or how it might have correlated with project outcome.
A person might believe that following a defined process is crucial to project success. This person would consequently spend a great deal of effort measuring and controlling adherence to the process. A person really convinced that process is key would not notice for a long time the absence of correlation between following a process and the project outcome.
Just as bad as focusing on something irrelevant is omitting something crucial in the parsing pattern. Suppose, for a moment, that a scientist who is doing geo-magnetic experiments in a building is unaware that the walls of the building contain iron. . Not only will she get anomalous results, but she will not understand where they came from or how to alter any of the other variables in the experiments to compensate.
The presence of people on a project is just such a crucial element of project outcome.
Those who do not have the people element in their parsing pattern will simply not notice the effects of the people on their projects. When reading articles that recounts the effect of using a particular new process (for example, Webb, 1999), you may notice that the body of the narrative comments on people but that the conclusion omits commentary regarding people. Researchers who miss this key element in their operating vocabulary cannot use it to adjust the outcome of a project.
The same argument applies to every practitioner, methodologist, and researcher, including me. It is one reason I waited 13 years before writing this book. Much like discovering the difference between texture and taste in evaluating steaks, I kept discovering new parsing patterns for development projects. The results of using the different patterns were so different that I could not commit to any one of them.
These days, when I study a project, I am periodically reawakened to the fact that I don't know what it is that I don't know but should know---what I should be paying attention to but don't have a parsing element for.
This concept of being limited in our awareness of underlying parsing patterns does not reflect something abnormal. The world is not kind enough to give us in advance the yin and yang shapes to use in our daily experiences. We are not first given the parsing pattern and then asked what the result looks like. Rather, we are given a complex experience on which any number of parsing patterns work and in which secondary artifacts easily command our attention. Although this condition can cause difficulty, it is normal and is worth reconsidering from time to time.
Detecting Parsing Patterns
My job as a research and field methodologist is to parse software development experiences that happen at full speed, detect boundaries fit for parsing, and give the pieces names that can be recalled for the next project. Detecting and naming these distinctions provides additional filters through which to examine the software development experience. This work does not create new techniques; it allows us to better detect what is already occurring in the projects and put the pieces back together in ways that will more closely match future experiences.
These days, I ask people to tell a story from a project (preferably something that worked, but any relevant episode will do). Then I see if I can reconstruct the story using the labels that I have in mind about project experience. With slowly increasing frequency, I can. When I can't, I store the story for later comparison. When two stories contain similarities, I look for words I can use to label the common parts.
We are still in the infancy of naming what is really happening on software development projects. The answer is not process, modeling, or mathematics, although those play parts. The answer has much more to do with craft, community, pride, and learning, as we will discuss.
-
Закладки
That it is people who design software is terribly obvious.…
The third problem is absence of feedback from the downstream…
On a new project, I would use Crystal Orange as a base…
1. Project name, job of person interviewed (the interviewee…
Types of Methodologies Rechtin (1997) categorizes methodologies…
For us as designers, it was possible to express both propositional…
The surprising thing about human success modes is how nebulous…
Agility implies maneuverability, a characteristic that is more…
The industry is littered with projects whose sponsors did…
Using the planning game in this way, the sponsors can…
Games are not just for children, although children also play…
We see an example of needing these normalizing rituals in the…
Accepting program modifications demanded by changing external…
After much coaching for six months, his programs still…
Figure 4-1. Elements of a methodology. Roles. Who…
Crystal Clear is the most tolerant, low-ceremony small-team…