Agile Software Development
Автор: Alistair Cockburn /
INTRODUCTION The Impossibility of Communication
-
Часть 7
-
How do you ever know what message your listener receives? In conversation, she returns messages, and you convince yourself that she really understood your intended message (at least closely enough).
Of course, sometimes you misunderstand her return message and falsely conclude that she understood your message. When you eventually find out, you exclaim, "But I thought my message was clear! "
The success of communication, then, lies in the sender and receiver having a shared experience to refer to. Grimace at the Store
Yesterday, when you and I were at the store, I grimaced when the sales clerk made a particular remark. Today, I make the same grimace. Your mind flashes back to the situation with the sales clerk. Comparing the situation at the current moment with that one, you detect commonality and transfer yesterday's emotional state to today's situation. You get my intended meaning, because we share a memory of the grimace.
When you have an experience sufficiently in common with another person, all you need to do is re-evoke that experience within him. When you touch a second experience in close succession, you link the two, creating new information. The fact of considering those two experiences as relevant to the moment is a new, shared experience for the two of you, one that you can later refer to. In this way, people jointly construct new concepts a little at a time, building new touch points from known experiences. Someone joining at the end of the conversation lacks those intermediate touch points, and must be "brought up to speed", that is, given sufficient touch points to join in.
These touch points grow as a person progresses in experience from beginner to junior, expert, and eventually working partner.
Beginners attend a programming school, where they pick up an initial vocabulary on which to build. They learn standardized notations and simple idioms, which create touchpoints for the low-level elements of design. Those who are learning object-oriented design become familiar with subclassing and polymorphism at the early stages, sequence charts and cardinality soon after, and perhaps a few of the Design Patterns (Gamma 1995). An experienced person trying to communicate a design to someone with this background can only work from these low-level terms. The experienced designer typically experiences this as tedious and missing the overall intention behind the design.
A junior programmer joins a series of projects, building common vocabulary and ideas in stages. The experienced person describing a design to a person at this stage might review some source code, do some joint programming, role-play the operation with some index cards, draw UML diagrams of various kinds, and draw arbitrary scribbles on the whiteboard while talking. The experienced person helps build a different vocabulary in the junior person, and the two of them create new experience they can later refer to.
Two experienced programmers who have not been on projects together refer to common, advanced idioms of design. Their conversation might include fragments such as, ". .. Just use Composite here, with a Decorator for the side view. " ". .. Set them up as dot-h files, but incorporate. .. " and so on. Through these large elements of description and additional squiggles on the whiteboard, the one can convey an understanding of the design structure and perhaps reach the intention of the design.
Programmers who have worked together for years have many touch points of shared experience. Their descriptions of requirements and design can be very brief, built on references to previous projects. ". .. It's the same pseudo-DNA structure we used on the Fox project, but this time separating out the. .. .” The shortcut expressions allow them to communicate and move at a speed not possible with even advanced outsiders. They are able to convey much better the intentions they had while designing.
In professional life, people don't have time to rebuild the vocabulary from the ground up each time they need to communicate. They look for the highest level of common experience they share and build new experiences from there. In no case can they ever be sure the listener really understands what was intended.
Managing Imperfect Communication
Communication is never perfect and complete. Such a thing is not even possible. Even assuming for the moment that you, yourself, know what you intend, the receivers of the communication must jump across a gap at some point and must do that all on their own.
People with similar experience can jump a large gap, working even from mumblings and gestures.
The more different another person is from you, the smaller the communication gap that she can jump. You have to back up, explain basic concepts, and then work forward until she builds her own bridge of experience and understands what you are saying.
There is no end to this backing up. No matter how much you back up, there is always someone who will not understand.
The irony is apparent: In the computer industry, we write specification and design documents as though we could actually ever explain what we mean. We can't. We can never hope to completely specify the requirements or the design.
We have to assume that the reader has a certain level of experience. If we can assume more experience, then we can write less. If we have to assume less experience, then we have to write more. The Russian Programmers
A group in an American firm that was contracting their programming to a Russian company contacted me. They wanted me to teach them how to write use cases for Russian programmers who knew neither English nor the domain very well.
I said, "You can't hope to teach them the domain inside the requirements document. First teach them the domain, then write a short requirements document that speaks to someone knowledgeable in the domain. " After trying for hours to get me to reveal the secret of communicating across this enormous gap, they finally admitted they had previously (and successfully) worked simply by putting the key people in the same room. They were just hoping that I had a way to communicate the requirements across the ocean perfectly using use cases.
In the end, they improved on my suggestion. They wrote a short requirements document for their local domain experts and then flew one of those experts to Russia to translate, explain, and generally ensure that the programmers were doing the right thing.
The domain expert could jump the large gap presented by the short use case document and then produce, as needed, and only as needed, communication to fill in and reduce the size of the gaps so that the Russian programmers could jump across.
The domain expert did not attempt to communicate perfectly. He managed the continuous incompleteness of the communications by interacting with the programmers in person and watching what they produced. Luke Hohmann (1998) refers to this as "reducing the equivocality" in the communication.
What the domain expert understood was that he did not have to reduce the equivocality to zero. He only had to reduce it to the point that the Russian programmers could take meaningful action.
Given that complete communication is never possible, the task on a project is not to try for complete communication but to manage the incompleteness of our communications.
The target is to reduce equivocality enough for appropriate action to be taken. That means guessing how much is needed, where to stop, when and how to make the gaps smaller, and how to can help the receivers to jump larger gaps.
Software projects are short on time and money, and making the gap smaller costs both. You need to discover how large a gap you can get by with at each moment, how much equivocality you can tolerate, and stop there.
-
Навигация [ Часть 7. Глава 1. ]
Закладки
The chart shows the state of the user stories being worked…
13. (FIRST TECHNIQUE). .. your sword now having bounced upward,…
It follows that on the Theory Building View, for the primary…
The main question is, if you were funding this project, which…
In arguing for the Theory Building View, the basic…
On a new project, I would use Crystal Orange as a base methodology…
After much coaching for six months, his programs still…
The third problem is absence of feedback from the downstream…
1. Project name, job of person interviewed (the interviewee…
The complete discussion about when and where to apply concurrent…
Accepting program modifications demanded by changing external…
That it is people who design software is terribly obvious. ..…
Games are not just for children, although children also play…
The industry is littered with projects whose sponsors…
While writing, reading, typing, or talking, we pick…
Agility implies maneuverability, a characteristic that is more…
Using the planning game in this way, the sponsors can properly…
The group of 17 quickly agreed on those value choices. Developing…