Agile Software Development
Автор: Alistair Cockburn /
CHAPTER 1. A Cooperative Game of Invention and Communication Software and Poetry
-
Часть 1
-
A fruitful way to think about software development is to consider it as a cooperative game of invention and communication.
The first section asks the question, "What would the experience of developing software be like if it were not software we were developing? " The purpose of the section is to get some distance from the subject in order to explore other ways of talking about it.
The second section reviews the broad spectrum of activities called games and finds the place of software development within that spectrum. If you are already familiar with zero-sum, positional, cooperative, finite, and infinite games, you might skim rapidly through the first part of this section. The section continues with a comparison of software development with another team-cooperative game—rock climbing—and two common comparison partners, engineering and model building.
The third section examines the idea of software development as a cooperative game of invention and communication more closely. It considers the primary goal of the game—delivering working software—and the secondary goal—or residue of the game—setting up for the next game. The next game is altering or replacing the system, or creating a neighboring system.
The final section in the chapter relates the ideas to everyday life.
What if software development were not software development? Then what would it be, and what would the experience be like? I suggest that it is like a community writing epic poetry together. I make this comparison not because I think you have experience in community poetry writing, but because I think you don't. Your imagination will supply you with the sorts of contradictions I am interested in evoking.
Imagine 50 people getting together to write a 20, 000-line epic poem on cost and time. What would you expect to find? Lots of arguments, for one thing. People trying to be creative, trying to do their best, without enough talent, time, or resources.
Who are the players in this drama? First, the people who ordered the poem. What do they want? They want something they can use to amuse themselves or impress their friends, not too expensive, and soon.
Next we have the key poem designers.
As you might imagine, this began as a one-person project. But our mythical poet found herself promising much more than she could deliver in the given time frame. So she asked a few friends to help. They designated her the lead poet and poem designer. She blocked out the theme and the poem's sequencing.
Her friends started to help, but then they ran into problems with synchronizing and communicating their work. It also turned out that they couldn't get it all done in time. So they added a couple of clerical people, more friends, and in desperation, even neighbors. The friends and neighbors were not real poets, of course. So our lead designers blocked out sections of the poem that would not require too much talent.
What do you think happened?
There was good news: One person was good at descriptive passages, another was good at the gory bits, and another was good at passages about people. No one was good at emotion except the lead poet, who by now was pulling her hair out because she didn’t have time to write poetry, she was so busy coordinating, checking, and delegating.
Actually, a couple of people couldn't leave well enough alone. Two of them wrote pages and pages and pages of material describing minor protagonists, and our lead poet could not get them to cut it down to size. Another few kept rewriting and revising their work, never satisfied with the result. She wanted them to move on to other passages, but they just wouldn't stop fiddling with their first sections.
As time progressed, the group got desperate and added more people. The trouble was that they were running out of money and couldn't really afford all these people. Communications were horrible, no one had the current copy of the poem, and no one knew the actual state of the poem.
Let's give this story a happy ending. ..
As luck would have it, they engaged a wonderfully efficient administrator who arranged for a plan of the overall poem, an inventory of each person's skills, a time-frame and communication schedule for each part, standards for versioning and merging pieces of the poem, plus secretarial and other technical services.
They delivered the poem to satisfied clients, well over budget, of course. And the lead poet had to go on vacation to restore her senses. She swore she would never do this again (but we know better).
Groups have surely have gotten together to write a long poem together. And I am sure that they ran into most of the issues that software developers run into: temperamental geniuses and average workers, hard requirements, and communication pressures. Humans working together, building something they don't quite understand. Done well, the result is breathtaking; done poorly, dross. Balance in Software Design
As I sat in on a design review of an object-oriented system, one of the reviewers suggested an alternate design approach
The lead designer replied that the alternative would not be as balanced, would not flow as well as the original.
Thus, even in hard-core programming circles, we find designers discussing designs in terms of balance and flow.
Software developers have a greater burden than our hypothetical poets have: logic. The result must not only rhyme; it must behave properly— "accurately enough, " if not correctly.
The point is that although programming is a solitary, inspiration-based, logical activity, it is also a group engineering activity. It is paradoxical, because it is not the case, and at the same time it is very much the case, that software development is:
· Mathematical, as C. A. R. Hoare has often said
· Engineering, as Bertrand Meyer has often said
· A craft, as many programmers say
· A mystical act of creation, as some programmers claim
Its creation is sensitive to tools; its quality is independent of tools. Some software qualifies as beautiful, some as junk. It is a meeting of opposites and of multiple sets of opposites.
It is an activity of cognition and expression done by communicating, thinking people who are working against economic boundaries, conditional to their cultures, sensitive to the particular individuals involved.
-
Навигация [ Часть 1. Глава 3. ]
Закладки
The complete discussion about when and where to apply concurrent…
Crystal Clear is the most tolerant, low-ceremony small-team…
Walk around your place of work. Notice · The convection…
Figure 4-1. Elements of a methodology. Roles. Who you employ,…
That it is people who design software is terribly obvious.…
While writing, reading, typing, or talking, we pick up traces…
In arguing for the Theory Building View, the basic issue…
The industry is littered with projects whose sponsors did…
Using the planning game in this way, the sponsors can properly…
Accepting program modifications demanded by changing external…
Types of Methodologies Rechtin (1997) categorizes methodologies…
The group of 17 quickly agreed on those value choices.…
The chart shows the state of the user stories being worked on…
For us as designers, it was possible to express both propositional…
The main question is, if you were funding this project,…
We see an example of needing these normalizing rituals in…
After much coaching for six months, his programs still…
On a new project, I would use Crystal Orange as a base…