Agile Software Development
Автор: Alistair Cockburn /
CHAPTER 1. A Cooperative Game of Invention and Communication Software and Games
-
Часть 2
-
Skill-sensitive. The rock climber must have certain proficiency. The novice can only approach simple climbs. With practice, the climber can attack more and more difficult climbs.
Training. Rock climbers are continually training on techniques to use.
Tools. Tools are a requirement for serious rock-climbing: chalk, chucks, harness, rope, carabiner, and so on. It is important to be able to reach for the right tool at the right moment. It is possible to climb very small distances with no tools. The longer the climb, however, the more critical the tool selection is.
Resource-limited. A climb usually needs to be completed by nightfall or before the weather changes. Climbers plan their climbs to fit their time and energy budget.
Plan. Whether bouldering, doing a single-rope climb, or doing a multi-day climb, the climbers always make a plan. The longer the climb, the more extensive the plan must be, even though the team knows that the plan will be insufficient and even wrong in places.
Improvised. Unforeseen, unforeseeable, and purely chance obstacles are certain to show up on even the most meticulously planned climbing expeditions unless the climb is short and the people have already done it several times before. Therefore, the climbers must be prepared to change their plans, to improvise, at a moment's notice.
Fun. Climbers climb because it is fun. Climbers experience a sense of flow (Csikszentmihalyi 1991) while climbing, and this total occupation is part of what makes it fun. Similarly, programmers typically enjoy their work, and part of that enjoyment is getting into the flow of designing or programming. Flow in the case of rock climbing is both physical and mental. Flow in the case of programming is purely mental.
Challenging. Climbers climb because there is a challenge: Can they really make it to the top? Programmers often crave this challenge, too. If programmers do not find their assignment challenging, they may quit or start embellishing the system with design elements they find challenging (rather like some of the poets mentioned in the epic poetry project).
Dangerous. Probably the one aspect of rock climbing that does not transfer to software development is danger. If you take a bad fall, you can die. Rock climbers are fond of saying that climbing with proper care is less dangerous than driving a car. However, I have not heard programmers express the need to compare the danger of programming with the danger of driving a car.
Software development has been compared with many other things, including math, science, engineering, theatre, bridge building, and law. Although one can gain some insight from looking at any of those activities, the rock-climbing comparison is the most useful for the purpose of understanding the factors involved in the activity.
A Game of Invention and Communication
We have seen that software development is a group game, which is goal seeking, finite, and cooperative. The team, which consists of the sponsor, the manager, usage specialists, domain specialists, designers, testers, and writers, works together with the goal of producing a working and useful system. In most cases, team members aim to produce the system as quickly as possible, but they may prefer to focus on ease of use, cost, defect freedom, or liability protection.
The game is finite because it is over when the goal is reached. Sometimes delivery of the system marks the termination point; sometimes the end comes a bit later. Funding for development usually changes around the time the system is delivered, and new funding defines a new game. The next game may be to improve the system, to replace the system, to build an entirely different system, or possibly to disband the group.
The game is cooperative because the people on the team help each other to reach the goal. The measure of their quality as a team is how well they cooperate and communicate during the game. This measure is used because it affects how well they reach the goal.
If it is a goal-directed cooperative game, what does the game consists of? What constitutes moves in the game?
The task facing the developers is this: They are working on a problem that they don't fully understand, one that lives in emotions, wishes, and thoughts, and that changes as they proceed. They need to
· Understand the problem space
· Imagine some mechanism that solves the problem in a viable technology space
· Express that mental construct in an executable language, which lacks many features of expression, to a system that is unforgiving of mistakes
To work through this situation, they
· Use props and devices to pull thoughts out of themselves or to generate new ideas that might help them understand the problem or construct a solution.
· Leave trails of markers for those who will come later, markers to monitor and test their progress and their understanding. They use those markers again, themselves, when they revisit parts of their work.
Software development is therefore a cooperative game of invention and communication. There is nothing in the game but people's ideas and the communication of those ideas to their colleagues and to the computer.
Looking back at the literature of our field, we see a few people who have articulated this before. Peter Naur did, in his 1986 article "Programming as Theory Building, " and Pelle Ehn did, in "Scandinavian Design: On Participation and Skill" (as well as his magnificent but out-of-print book Work-Oriented Design of Software Artifacts). Naur and Ehn did this so well that I include those two articles in near entirety in Appendix B. Robert Glass and colleagues wrote about it in “Software Tasks: Intellectual or Clerical? ” (Glass 1992), and Fred Brooks saw it as such a wickedly hard assignment that he wrote the article "No Silver Bullet" (Brooks 1995).
The potential consequences of this cooperative game of invention and communication are outlined in the remainder of this chapter. The remainder of the book examines those consequences.
-
Закладки
The group of 17 quickly agreed on those value choices. Developing…
Figure 4-1. Elements of a methodology. Roles. Who you employ,…
The industry is littered with projects whose sponsors did…
We see an example of needing these normalizing rituals…
Agility implies maneuverability, a characteristic that is more…
The third problem is absence of feedback from the downstream…
The main question is, if you were funding this project,…
Crystal Clear is the most tolerant, low-ceremony small-team…
While writing, reading, typing, or talking, we pick…
The complete discussion about when and where to apply concurrent…
1. Project name, job of person interviewed (the interviewee…
That it is people who design software is terribly obvious.…
Types of Methodologies Rechtin (1997) categorizes methodologies…
It follows that on the Theory Building View, for the…
In arguing for the Theory Building View, the basic issue…
Accepting program modifications demanded by changing external…
The surprising thing about human success modes is how nebulous…
Walk around your place of work. Notice · The convection currents…
After much coaching for six months, his programs still looked…
The chart shows the state of the user stories being…