Agile Software Development
Автор: Alistair Cockburn /
CHAPTER 1. A Cooperative Game of Invention and Communication Software and Games
-
Часть 1
-
Games are not just for children, although children also play games. Games are invented and used by many people including novelists, mathematicians, and corporate strategists.
Kinds of Games
If you are sitting around the living room on a winter's evening and someone says, "Let's play a game, " what could you play?
You could play charades (play-acting to uncover a hidden phrase). You could play tic-tac-toe or checkers, poker or bridge. You could play hide-and-seek or table tennis. You could play "When I took a trip. .. ," a game in which each person adds a sentence onto a story that grows in the telling. You could, especially if you have younger children, end up having a wrestling match on the living room floor.
Games fall into many categories: zero-sum, nonzero-sum, positional, competitive, cooperative, finite, and infinite, to name a few (see Figure 1-1). As a way to help identify what kind of game software http://www.o-perfum.ru development could be, let's look at those choices.
Figure 1-1. Different categories of games.
Zero-sum games are those with two sides playing in opposition, so that if one side wins, the other loses. Checkers, tic-tac-toe, bridge, and tennis are examples. Software development is clearly not a zero-sum game.
Non-zero-sum games are those with multiple winners or multiple losers. Many of the games you would consider playing on that winter's evening are non-zero-sum games: poker, pachisi, and hide-and-seek. Software development is also a non-zero-sum game.
Positional games are those in which the entire state of the game can be discovered by looking at the markers on the board at that moment. Chess and tic-tac-toe are examples. Bridge isn't, because the played cards don't show which person played them.
Some people try to play software development as a positional game, requiring that the documentation reflect the history and current state of the project. They intend that, should anyone leave the project, a replacement person will be able to join, read the documentation, and pick up where the other person left off. We shall come to see that this is not an effective gaming strategy for software development.
(Positional games are actually far more interesting than the simple description above implies. John Conway, in his book On Numbers and Games, was able to show how two-person, positional games form a superset of all numbers: real, imaginary, finite, and transfinite. He constructs the notion of number directly from two-person, positional games. )
All the above are competitive games, in which there is a clear notion of winning and losing.
In cooperative games, the people work either to win together or to continue the game as long as they consider it worth playing. The former are goal-seeking cooperative games, the latter non-goal-seeking cooperative games. Story telling, playing jazz, and carpet wrestling are non-goal-seeking cooperative games. In these latter games, the players do not seek to end the game by reaching a goal as fast as possible. They come to an end only when enough people get tired of playing and step out.
Charades, rock climbing and software development are goal-seeking cooperative games (see Figure 1-1 again).
All of the above are finite games, games intended to end. Infinite games are those in which the players' primary intention is to keep the game going. Organizations, corporations, and countries play these. Their core purpose is to stay in existence.
A person's profession is also an infinite game. The person, wanting to continue the profession, makes a set of moves that permit his practice of that profession to continue.
Often, a person or company aims to play well on a particular project in order to get the best position on the next game. As with the card game appropriately named "So long, sucker, " these sorts of teams and alliances change continually and without notice.
Software and Rock Climbing
Of all the comparison partners for software development that I have seen, rock climbing has emerged as the best. It is useful to have such a comparison partner, to get some distance from the subject, and open a vocabulary that we can reapply to software development. Rock climbing is not a metaphor for software development but a comparison partner, another member of the same class of games.
Let's see how some of the words and phrases associated with rock climbing relate to software development.
Cooperative and goal-seeking. A team of rock climbers work together to reach the top. They will evaluate the climb based on how well they climbed together and how much they enjoyed themselves, but the first measure of success is whether they reached the top. Reaching the endpoint is a primary goal, and the game is over when they reach the top.
(If you are a rock climber, you might well interrupt me here. For many rock climbers, the moment of reaching the end of the climb is a sad one, for it signals the end of the game. That is true of cooperative games in general. The game comes to an end when the endpoint is reached, but if the players have been enjoying themselves, they may not want to stop. Similarly, sometimes software developers do not want to finish their design, because then the fun part of their work will be over. )
Load bearing. The climbers must actually support their weight on their hands and feet. This is a particularly valuable point of comparison between the two: Software must run and produce reasonable responses. While multiple solutions are possible, not just any solution will do.
Team. Climbing is usually done in teams. There are solo climbers, but under normal circumstances, climbers form a team for the purpose of a climb.
Individuals with talent. Some people just naturally climb better than others do. Some people will never handle certain climbs.
-
Навигация [ Часть 1. Глава 4. ]