Agile Software Development
Автор: Alistair Cockburn /
CHAPTER 3. Communicating, Cooperating Teams Teams as Communities
-
Часть 2
-
Good citizenship is a matter of acting in ways that benefit others. Citizenship shows up with people
· Getting to meetings on time
· Answering questions from other people
· Bothering to mention things that one notices
· Following group coding conventions
· Using code libraries Citizenship permits programmers who disagree on coding styles to nontheless create a common coding standard for themselves. As many lead programmers have said, "It's not what I would like, but I recognize that there many ways work, and selecting any one of them is better than not selecting any at all. "
Helping other people in the company is a characteristic of citizenship. Dixon (2000) reports on the strong effect of taking time to help other people. She cites, among many examples, a woman at Tandem Computers who was asked about taking away from her work time to answer questions posted on the corporate discussion boards. The woman responded, "Answering questions like this is part of being a good company citizen"
I would suggest increasing citizenship levels to get better project results, except that I usually find workers already show citizenship and sacrifice, and management already takes too much advantage of it.
People join a new company and work overtime, thinking that after they contribute this extra work, the company will repay the compliment and give them more recognition and time off. What they don't realize is that their bosses and colleagues assume that however they work in the first month is how they will work and act forever. As a result, people regularly get poor evaluations for dropping their working hours from 65 down to a mere 50!
I am afraid that managers will use the pretext of good citizenship to coerce people into working yet more overtime. Read Death March (Yourdon 1998) for examples of this.
Citizenship should be encourages within normal working hours, not as a means of lengthening normal working hours. There are plenty of ways to apply citizenship within working hours.
Hostile XP vs. Friendly XP
To round out this discussion, let's look at the consequences of working with and without attention to community. I choose to discuss XP, because although communication and community are core values within XP, I have seen it practiced with and without that community, "friendly" XP and "hostile" XP, as it were. The difference is profound.
The three following situations are ones in which customers and programmers might magnify their differences and create a hostile XP:
· The customers are not quite sure what they want. The programmers insist, "Tell us what to build, " so the customers say something The programmers build exactly that and then ask, "Tell us what to build next. "
In this situation, neither group is really sure what is the correct thing build next. The programmers escape the pressure of the situation by shifting the burden over to the customers (which they are allowed to do). The customer experiences the situation as unsettling: there is little time to reflect, examine, experiment, and sort out options.
As a result, the customer's instructions over succeeding iterations conflict with each other ("Build this. .. No, now build this. .. No, try building that, now"). Both parties become depressed about the lack of clear progress.
· The programmers do whatever the customer says, even if they are sure it is a silly idea.
As with the story, "Not enough conflict, " a project suffers when the developers don't mention problems they notice. The project loses the creative interplay of sharp programmers offering their insights into the requests of the customers.
· The customers tell the programmers that a particular feature will be coming up, and would the programmers please design the system to handle that gracefully. The programmers cite a series of the XP mantras: "keep it simple, " "you aren't gonna need it, " "we'll do the simplest thing that will possibly work, " and ignore any suggestion of what to build into the software.
The consequence is that the designers run through a sequence of designs everyone knows are incorrect, until the critical requirements finally appear. By then, time has been spent redesigning the system several times. In the cases I have encountered, the programmers were happy about the exercise, and the sponsors were unhappy.
In each of these cases, the programmers withheld information. Withholding their own thoughts and experience from the discussion, they abdicated responsibility toward the overall project. By doing so, they damaged the project by concealing from view superior development strategies.
In friendly XP, practiced with community, the three situations play out differently. In each case, the programmers actively share their views, experiences, cost estimates, and solutions.
· In the first situation, not knowing what to build next, the programmers help the customers gain experience in voicing what they want. They can do this by producing small working prototypes tailored to discovering the desired characteristics.
· In the case of the silly idea, the programmers volunteer their information in an amicable dialogue, "I'm not sure you really want this thing you asked for. It will be so-and-so difficult to implement, and has the following roll-on effects. " The customer might still request the feature, but quite often, the person had no idea about those effects, and is happy to have it mentioned. Usually, the customer appreciates the insights, whether or not she changes the request.
· In the story sequencing situation, the programmers help the customers by finding those story cards that affect the decisions in question. They would then jointly consider in what order these cards might be tackled. The new order might not simply ask for more functionality along a business-value trajectory, but might converge more quickly on the actual system the customers want.
Any development methodology, even those that advocate amicability and community, can be practiced without it, to the detriment of the project.
Building "Team" by Winning
Team spirit was once built through singing company songs and attending company functions. (Any of you still have your IBM songbook? ) When singing on the job went out of style, nothing immediate took its place.
Some companies start projects with one or several days of off-site team-building. This is good, even if it is good mostly because the people recognize the effort the company is putting forth in showing show that teamwork is important. While not every team-building exercise actually builds a team, a number of successful teams have pointed to their team-building days at the start of the project as having helped them work together more effectively. As a result, their company leaders consider the money well spent, and plan on continuing the tradition.
Programmers give mixed reviews to outside-of-work team building exercises. Several said, roughly, "I'm not interested in whether we can barbeque together or climb walls together. I'm interested in whether we can produce software together. "
-
Закладки
The group of 17 quickly agreed on those value choices. Developing…
The chart shows the state of the user stories being worked on…
Types of Methodologies Rechtin (1997) categorizes methodologies…
The main question is, if you were funding this project,…
Games are not just for children, although children also…
Crystal Clear is the most tolerant, low-ceremony small-team…
Figure 4-1. Elements of a methodology. Roles. Who you employ,…
The third problem is absence of feedback from the downstream…
In arguing for the Theory Building View, the basic issue…
Using the planning game in this way, the sponsors can…
The complete discussion about when and where to apply concurrent…
Walk around your place of work. Notice · The convection currents…
13. (FIRST TECHNIQUE). .. your sword now having bounced upward,…
We see an example of needing these normalizing rituals…
That it is people who design software is terribly obvious.…
1. Project name, job of person interviewed (the interviewee…
The surprising thing about human success modes is how nebulous…