Agile Software Development
Автор: Alistair Cockburn /
CHAPTER 5. Agile and Self-Adapting Agile
-
Часть 3
-
Successful Distributed Development
I spent an evening talking with a couple of people who were successfully using four or five people who never met as a group.
They said that besides partitioning the problem carefully, they spent a lot of time on the phone, calling each person multiple times each day.
In addition to those obvious tactics, the team coordinator worked particularly hard to keep trust and amicability levels very high. She visited each developer every few weeks and made sure that they found her visits helpful (not blame sessions).
This coordinator was interested in replicating their development model. We concluded, by the end of the evening, that she would need to find another development coordinator with a similar personal talent for developing trust and amicability. Two aspects of their development struck me: Their attention to building trust among themselves, The vast amount of energy they invested into communication on a daily basis, to achieve opportunistic learning, trust and feedback.
Open-Source Development
Open source development, although similar in appearance to distributed development, differs in its philosophical, economic, and team structure models. In contrast to the resource-constrained cooperative game most software development projects play, an open-source project is playing a non-resource-constrained cooperative game.
An industrial project aims to reach its goal in a given time frame with a given amount of money. The constraints of money and time limit how many people can work on it, and for how long. In these games we hear three phrases: "Finish it before the market window closes! " "Your job is to make the trade-off between quality and development time! " "Ship it! " An open-source development project, on the other hand, runs with the idea that with enough eyes, minds, fingers and time, really good designs and really good quality code will show up. There are, in principle, an unlimited number of people interested in contributing, and no particular market window to hit. The project has its own life and existence. Each person improves the system where it is weak, at whatever rate that time and energy indicate.
The reward structure is also different, being based on intrinsic, as opposed to external rewards (see Chapter 2). People develop open-source code for pleasure, as service to a community they care about, and for peer recognition. The motivational model is discussed at length in "Homesteading the noosphere" (? ? URL).
A goal for an industrial developer would be to become the next Bill Gates. The corresponding goal for an open-source developer would be to become the next Linus Torvalds.
Finally, the open-source team structure of open-source development is different. Anyone may contribute code, but there is a designated gate-keeper protecting the center, the code base. That gatekeeper needn't be the best programmer, but needs to be a good programmer with good people skills and a very good eye for quality. Over time, the few, best contributors come to occupy the center, becoming intellectual owners of the design. Around these few people are an unlimited number of people who contribute patches and code suggestions, detect and report bugs, and who write documentation.
It has been suggested, and I find it plausible, that one of the key aspects of open-source development
If you have been reading this book from the beginning, you should still see one mystery at this point.
Every person is different, every project is different, a project differs internally across subject areas, subsystems, subteams and time. Each situation calls for a different methodology (set of group conventions).
All communication is visible to anyone. I find this plausible using the following comparison with industrial projects:
On an industrial project with a colocated team, trouble comes if the team evolves into a society with an upper and a lower class. If analysts sit on one side of the building and programmers sit on the opposite side, an "us-them" separation easily builds that causes hostility between the groups (I almost wrote "factions"). In a well-balanced team, however, there is only "us", there is not an "us-them" sensation. A key role in the presence or absence of this split is the nature of the background chit-chat within the group. When the seating forms enclaves of common specialists (I almost wrote "ghettos"), that background chit-chat almost inevitably contains comments about "them. "
In open-source development, the equivalent situation would be that one sub-group, the colocated one, is thought to be having a set of discussions that the others are not able to see. The distributed people would find it easy to develop a sense of being second-class citizens, cut away from the heart of the community, and cut off from relevant and interesting conversations.
When all communication is online, visible to everyone, there is no natural place for rumors to grow in hiding, and once again there is only "us. "
I would like one day to see or do a decent investigation of this aspect of open-source development.
The mystery is how to construct a different methodology for each situation, without spending so much time designing the methodology that the team doesn't deliver software. You also don't want everyone on your project to have to grow into a methodology expert.
I hope you can guess what's coming.
-
Навигация [ Часть 3. Глава 24. ]
Закладки
After much coaching for six months, his programs still looked…
For us as designers, it was possible to express both propositional…
13. (FIRST TECHNIQUE). .. your sword now having bounced…
Figure 4-1. Elements of a methodology. Roles. Who you employ,…
The third problem is absence of feedback from the downstream…
Types of Methodologies Rechtin (1997) categorizes methodologies…
While writing, reading, typing, or talking, we pick…
We see an example of needing these normalizing rituals in…
In arguing for the Theory Building View, the basic issue…
The complete discussion about when and where to apply concurrent…
Using the planning game in this way, the sponsors can properly…
It follows that on the Theory Building View, for the…
Crystal Clear is the most tolerant, low-ceremony small-team…
Games are not just for children, although children also…
1. Project name, job of person interviewed (the interviewee…
On a new project, I would use Crystal Orange as a base methodology…
Walk around your place of work. Notice · The convection currents…
Agility implies maneuverability, a characteristic that…
The chart shows the state of the user stories being worked…