Agile Software Development
Автор: Alistair Cockburn /
CHAPTER 2. Individuals Drawing on Success Modes
-
Часть 2
-
A more extreme example is the way many people sort papers in their offices. They have stacks of papers in general piles and locate reports by looking through the relevant stacks.
The important thing to notice is that this lack of final sorting is not bothersome. Most people do not even notice it but work on the assumption that they can locate things fast enough through scanning and by memory associations.
Trygve Reenskaug gave the following example of being good at looking around on a project: Off-Shore Oil Platform Design
Trygve tried to get a designer of offshore oil platforms interested in a computer-aided design system. Trygve suggested that the system could add value to the project by tracking all the design update activity touching any part of the platform. The engineer replied, "Just have it store the phone numbers of the people working on each part. I'll call them and find out. "
A second example of people using their ability to look around is the way code maintenance is done.
Keeping traceability and design documents up to date is very expensive and unreliable (particularly given the weakness of humans with regard to consistency). In most projects, it is not long before the documentation doesn't match the code.
If keeping the two in sync were essential, project teams would not be able to continue through the maintenance phase. However, code maintainers expect this mismatch, and so they use the faulty documentation simply as a means of getting "close" to the area that will need changing.
As soon as they are close, their eyes and intelligence take care of the rest. They plan on just looking around until they find the section of code to change.
Inside the theory of the cooperative game, we can use this human ability and plan on making the documentation "good enough to get close, " close enough to use the native human ability to look around and find the right place to make a change.
A third place where we count on people being good at looking around is the role of technical lead.
The title "Technical Lead" contains the assumption that this person has done something similar enough before, that he has a sense of when the project is all right and when it is off track. The Technical Lead is not given any instructions about to how to do this. He is simply supposed to "look around and notice" when something is not right and somehow invent a way to get back into the safety zone.
"Looking around and noticing when something is not right" is something that everyone on the project does. I have found people in every possible job description who have detected something amiss with some aspect of the project—very often not their own—and have reported it to the person who should deal with it. Or, they have just dealt with it themselves, specifically stepping outside their own job descriptions to take care of it.
Contributing and Taking Initiative
In the previous section I discussed pride-in-contribution and pride-in-work as strong intrinsic motivators. Now I suggest that they are also core contributors to project success.
People who have pride in their work do a better job than those who do not, but they are also more likely to step outside of their own job descriptions to repair or report some other problem that they notice. Not even the best process can allow for catching every eventuality; therefore, it becomes important that people notice, mention, and resolve problems that they see.
Often, their only reward is knowing that they have done a good deed, and yet I continually encounter people for whom this is sufficient.
Notice that we are back to the spontaneous behavior I mentioned at the start of the chapter. At that time, I presented spontaneity as a difficulty in building a predictive model of humans working in a system. Now I include it as one of the human success modes.
Start with some pride-in-work and a sense of citizenship. Add being good at looking around and acting spontaneously. With these, we see people taking initiative to get the job done every day, an ongoing activity that keeps the project operating at peak form.
This is not an indication of process failure. Even the best process won't be able to account for every surprise that occurs on the project. The good thing to notice is that as the team gets better at pride-in-work, communication, citizenship, and initiative, the process can become less formal, based more on noticing what needs doing.
Combining Success Modes
Is it possible to construct a development methodology just around pride-in-work, citizenship, community, people being good at looking around, and initiative?
It is. The following excerpt (Hock 1999, p. 205-207) is a description of how the first VISA clearing program was developed in 60 days. Note Dee Hock's use of the phrase "self-organization, " synonymous with people taking initiative in a community. Dee Hock's VISA Story We decided to become our own prime contractor, farming out selected tasks to a variety of software developers and then coordinating and implementing results. Conventional wisdom held it to be one of the worst possible ways to build computerized communications systems. We rented cheap space in a suburban building and dispensed with leasehold improvements in favor of medical curtains on rolling frames for the limited spacial separation required. .. .
Swifty, self-organization emerged. An entire wall became a pinboard with every remaining day calendared across the top. Someone grabbed an unwashed coffee cup and suspended it on a long piece of string pinned to the current date. Every element of work to be done was listed on a scrap of paper with the required completion date and name of the person who had accepted the work. Anyone could revise the elements, adding tasks or revising dates, provided that they coordinated with others affected. Everyone, at any time, could see the picture emerge and evolve. They could see how the whole depended on their work and how their work was connected to every other part of the effort. Groups constantly assembled in front of the board as need and inclination arose, discussing and deciding in continuous flow and then dissolving as needs were met. As each task was completed, its scrap of paper would be removed. Each day, the cup and string moved inexorably ahead.
-
Закладки
The complete discussion about when and where to apply…
1. Project name, job of person interviewed (the interviewee…
Games are not just for children, although children also play…
Crystal Clear is the most tolerant, low-ceremony small-team…
The industry is littered with projects whose sponsors did…
That it is people who design software is terribly obvious. ..…
Agility implies maneuverability, a characteristic that is…
The main question is, if you were funding this project, which…
Using the planning game in this way, the sponsors can…
The surprising thing about human success modes is how nebulous…
Walk around your place of work. Notice · The convection currents…
Accepting program modifications demanded by changing…
For us as designers, it was possible to express both…
On a new project, I would use Crystal Orange as a base…
While writing, reading, typing, or talking, we pick up traces…
The chart shows the state of the user stories being worked…
13. (FIRST TECHNIQUE). .. your sword now having bounced upward,…
We see an example of needing these normalizing rituals in the…
The group of 17 quickly agreed on those value choices. Developing…
Figure 4-1. Elements of a methodology. Roles. Who you employ,…