Agile Software Development
Автор: Alistair Cockburn /
INTRODUCTION The Impossibility of Communication
-
Часть 3
-
Other energetic reviewers I would like to recognize and thank (in first-name alphabetical order) are Alan Harriman, Allen Galleman, Andrea Branca, Andy Sen, Bill Caputo, Charles Herbaut, Charlie Toland, Chris Lopez, Debbie Utley, Glenn Vanderburg, James Hanrahan, Jeff Miller, Jeff Patton, Jesper Kornerup, Jim Sawyer, John Brewer, John Cook, Keith Damon, Laurence Archer, Michael Van Hilst, Nick Fortescue, Patrick Manion, Phil Goodwin, Richard Pfeiffer, Ron Holiday, Scott Jackson, Ted Young, Tom DeMarco, and Tracy Bialik.
The Silicon Valley Patterns Group took the trouble to dissect the draft as a group, for which I doubly thank them.
All these people did their best to see that I fixed the weak parts and kept the good parts. If I had had another few years to keep reworking the book, I might even have been able to get it to the point that they would have accepted it.
In the absence of those extra years, I thank them for their efforts and apologize for not being able to fix all the awkward spots.
Thank goodness the Beans Brews coffee shop finally started playing jazz and rock again. I lost several months of writing to heavy metal and country music.
Unknowable and Incommunicable
This introductory chapter sets up two questions: "Can you ever know what you are experiencing, and can you ever communicate it? " The short answer, "No, you can't, " creates the basic dilemma that this book addresses.
If you can't know what you are experiencing, how can you reflect on projects, and how can you form recommendations for doing better? Both spending time on irrelevant factors and overlooking important factors will hurt you. This inescapable problem faces every person who is trying to work better: methodologist, researcher, and practitioner alike.
Knowing that perfect communications are impossible relieves you of trying to reach that perfection. Instead, you learn to manage the incompleteness of communication. Rather than try to make the requirements document or the design model comprehensible to everyone, you stop when the document is sufficient to the purpose of the intended audience. "Managing the incompleteness of communications" is core to mastering agile software development.
After setting up the two questions, this chapter introduces the idea of operating at different levels of expertise. A novice listens differently than an expert does and asks for different guidance. This third section discusses the importance of understanding the listening levels of the people who are involved in the project.
The final section relates theabstract concepts to everyday life.
This is the most abstract chapter in the book. If you don't enjoy abstract topics, then skim it for now and return to it after reading some of the later, more concrete chapters.
The Problem with parsing experience
The Wine Label
A good guest, I gave the hostess my bottle of wine as I arrived, and I watched with curiosity as she put it into the refrigerator.
When she pulled it out at dinnertime, she said,
"This will go well with the fish. "
"But that's red wine, " I finally offered.
"It’s white, " she said.
"It's red, " I insisted, pointing to the label.
"Of course not. It's red. It says so right here. .. "
She started to read the label out loud.
". .. Oh! It's red! Why did I put it into the refrigerator? "
We laughed and spent time recalling each attempt we had made to check our respective views of the "truth.
"How on earth, she asked, could she have looked at the bottle so many times and not noticed that it was a red wine? "
People who report on software development projects also make mistakes of observation that get passed along as "facts. " Requirements writers are not exempt, either. They observe their user community and produce documents that they think contain only “requirements” but that often contain mistakes of observation as well.
Conflicting Parsing Patterns
When we live through an experience, we parse it, to use the linguistic term. We chop the experience into separate, meaningful chunks that we store for later retrieval. The human mind does this whether we want it to or not.
There are many, and many different, patterns we can use to chop experience into pieces. Each pattern produces a unique perception of the experience. Steak Tasting
When I was first going out to restaurants, I worked at distinguishing and enjoying the taste of steaks. One day, someone told me that it is not the taste but the texture that differentiates steaks.
Parsing Experience
That single idea invalidated what I had thought about steaks up to then and set up a new parsing pattern for the future.
Each parsing pattern leaves small, unresolved gaps in the result. When we parse according to any one pattern and later put our pieces back together, we get a distorted, simplified, incomplete result. We only hope that it is "close enough" to be useful in the ways we use the recollection.
When two people use different parsing patterns, the resulting, differently shaped thoughts give them quite different vocabularies for describing the same events and different results when the pieces are put back together (all distorted, simplified, and incomplete). Thus, one person might describe steaks based on taste, and another might describe them based on texture. Neither description is complete; worse than that, the two people can't share results with each other.
Let's look at this idea in two separate contexts, first with a visual example and then as it applies to software development.
For the visual example, look at how I put together a shape made entirely from 1/8-circle arcs (Figure I-1).
-
Закладки
The third problem is absence of feedback from the downstream…
Figure 4-1. Elements of a methodology. Roles. Who you…
13. (FIRST TECHNIQUE). .. your sword now having bounced…
We see an example of needing these normalizing rituals…
The chart shows the state of the user stories being…
Using the planning game in this way, the sponsors can…
After much coaching for six months, his programs still looked…
Agility implies maneuverability, a characteristic that…
The surprising thing about human success modes is how nebulous…
Walk around your place of work. Notice · The convection…
The main question is, if you were funding this project, which…
Types of Methodologies Rechtin (1997) categorizes methodologies…
That it is people who design software is terribly obvious.…
1. Project name, job of person interviewed (the interviewee…
Crystal Clear is the most tolerant, low-ceremony small-team…
On a new project, I would use Crystal Orange as a base…