Agile Software Development
Автор: Alistair Cockburn /
CHAPTER 1. A Cooperative Game of Invention and Communication A Second Look at the Cooperative Game
-
Часть 3
-
The sponsors of the Chrysler Comprehensive Compensation project eventually halted funding for the project. As the people left the development team, they left no archived documentation of their requirements and design other than the two-sentence user stories, the tests, and the program source code. Eventually, enough people left that the oral tradition and group memory were lost.
This team masterfully understood the cooperative game principle during system construction but missed the point of setting up the residue for the following game.
Deciding on the residue is a question that the project team cannot avoid. The team must ask and answer both of these questions:
· How do we complete this project in a timely way?
· When do we construct what sorts of markers for the next team?
Some people choose to spend more money, earlier, to create a safety buffer around the secondary goal. Others play a game of brinksmanship, aiming to reach the primary goal faster and creating as little residue as possible, as late as possible.
In constructing responses, the team must consider the complexity of both the problem and the solution, the type of people who will work on it next, and so on. Team members should balance the cost of overspending for future utility against the risk of under documenting for the future. Finding the balance between the two is something of an art and is the proper subject of this book.
A Game within a Game
Although any one project is a cooperative and finite game, the players are busy playing competitive and infinite games at the same time.
Each team member is playing an infinite game called career. These individuals may take actions that are damaging to the project-as-game but which they view as advantageous to their respective careers.
Similarly, the company is playing an infinite game: its growth. To the company, the entire project is a single move within that larger game. Under certain competitive situations, a company's directors may deliberately hinder or sabotage a project in order to hurt a competitor or in some other way create a better future situation for itself.
Watching military subcontracting projects, it sometimes seems that the companies spend more time and money jockeying for position than developing the software. Thinking about any one project in isolation, this doesn't seem to be sensible behavior. If we consider the larger set of competitive, infinite games the companies are playing, though, then the players' behavior suddenly makes more sense. They use any one project as a playing board on which to build their position for the next segment of the game.
The cooperative game concept does not imply that competitive and infinite games don't exist. Rather, it provides words to describe what is happening across the games.
Open-Source Development
Finally, consider open-source projects. They are grounded in a different economic structure than commercial projects: They do not presume to be resource-limited.
An open-source project runs for as long as it runs, using whatever people happen to join in. It is not money-limited, because the people do not get paid for participating. It is not people-resource limited, because anyone who shows up can play. It is not time limited, because it is not run to a schedule. It just takes as long as it takes.
The moves that are appropriate in a game that is not resource-limited are quite naturally different from those in a resource-limited game. The reward structure is also different. Thus it is to be expected that an open-source project will use a different set of moves
As you practice this new vocabulary on your current project, you should start to see new ways of finishing the job in a timely manner while protecting your interests for future projects. Here are some ideas for becoming more comfortable with the ideas in this chapter:
Read "Programming as Theory Building" in Appendix B. Then, watch
· The people on the design team build their theories
· The people doing last-minute debugging, or program maintenance, build their theories
· The difference in the information available to the latter compared to the former
· How their different theories result in different programs being produced
· How your understanding of your problem changes over time and how that changes your understanding of the solution you are building
Look around your project, viewing it as a resource-limited cooperative game of invention and communication. Ask: to get through the game. The creation of the software, though, is still cooperative and is still a game of invention and communication.
One may argue that open-source development is not really goal seeking. Linus Torvalds did not wake up one day and say, "Let's finish rewriting this UNIX operating system so we can all go out and get some real jobs. " He did it first because it was fun (Torvalds 2001) and then to "make this thing somewhat better. " In other words, it was more like kids carpet wrestling or musicians playing music than rock climbers striving to reach the top.
While that is true to some degree, it is still goal-directed in that a person working on a section of the system works to get it to "the next usable state. " The people involved in that section of the system still work the cooperative game of invention and communication to reach that goal.
· Who are the players in this game?
· Which are playing a finite, goal-directed team game?
· Which are playing their own infinite game instead?
· When are your teammates inventing together, and when they are laying down tracks to help others get to where they are? Track this carefully for five consecutive workdays, to see them move from one to the other.
View the project decisions as "moves" in a game. Imagine it as a different sort of game, crossing a swamp:
· Recall the project setup activities as a preliminary plan of assault on the swamp, one that will change as new information emerges about the characteristics of the swamp and the capabilities of the team members.
· Watch as each person contributes to detecting deep or safe spots and builds a map or walkway for other people to cross.
-
Навигация [ Часть 3. Глава 5. ]
Закладки
The chart shows the state of the user stories being worked…
Crystal Clear is the most tolerant, low-ceremony small-team…
Games are not just for children, although children also play…
Types of Methodologies Rechtin (1997) categorizes methodologies…
For us as designers, it was possible to express both propositional…
Accepting program modifications demanded by changing external…
The third problem is absence of feedback from the downstream…
While writing, reading, typing, or talking, we pick up traces…
The surprising thing about human success modes is how nebulous…
In arguing for the Theory Building View, the basic issue is…
The industry is littered with projects whose sponsors did…
On a new project, I would use Crystal Orange as a base…
Using the planning game in this way, the sponsors can…
1. Project name, job of person interviewed (the interviewee…
13. (FIRST TECHNIQUE). .. your sword now having bounced…
After much coaching for six months, his programs still looked…