Agile Software Development
Автор: Alistair Cockburn /
CHAPTER 1. A Cooperative Game of Invention and Communication A Second Look at the Cooperative Game
-
Часть 1
-
At the University of Aalborg, in Denmark, a new Informatics major was defined that involves both software design and communication skill (Mathiassen 2000). The department head, Lars Mathiassen, reports that the difference in people's personalities is noticeable: The new curriculum attracts those who are willing to accept the communications load, and the old curriculum attracts those who have less interest in communication.
To the extent that software development really is a game of invention and communication, we will have to see a greater emphasis on communication in the university curricula.
Gaming Faster
We should not expect orders of magnitude improvement in program production.
As much as programming languages may improve, programming will still be limited by our ability to think through the problem and the solution, working through the details of how the described solution deals with the myriad cases it will encounter. This is Naur’s "programming as theory building" (Appendix B).
To understand why exponential productivity growth is not an appropriate expectation, we need only look at two other fields of thought expression: writing novels and writing laws. Imagine being worried that lawyers are not getting exponentially faster at creating contracts and laws!
In other words, we can expect the game of invention and the business of communicating those intentions to a computer to remain difficult.
Markers and Props
Intermediate work products help with Naur's "theory building" and Ehn's "language games, " as reminders for our reflection. They provide shared experiences to refer to or serve as support structures for new ideas.
The former need only be complete enough to remind a person of an earlier thought or decision. Different markers are appropriate for different people with different backgrounds.
The latter act as props to incite new thoughts. Laser Printer Mockups
Ehn's team considered introducing laser printers to a group that had no experience with them, back in 1982. They constructed cardboard mockups, not to remind the participants of what they already knew, but to allow them to invent themselves into the future, by creating an inexpensive and temporary future reality to visualize.
These mockups are not second-class items, used only due to some accidental absence of technology. Rather, they are a fundamental technique used to help people construct thoughts about new situations. Any work product that helps the group invent a way forward in the game is appropriate. Whether they keep the mockup around as a reminder of the discussion is up to them in the playing of their game.
Diminishing Returns
Because the typical software development project is limited in time, people, and money, spending extra of those resources to make an intermediate work product better than it needs to be for its purpose is wasteful. One colleague expressed it this way: Diminishing Returns
It is clear to me as I start creating use cases, object models, and the like, that the work is doing some good. But at some point, it stops being useful and starts being both drudgery and a waste of effort. I can't detect when that point is crossed, and I have never heard it discussed. It is frustrating, because it turns a useful activity into a wasteful activity.
The purpose of each activity is to move the game forward. Work products of every sort are sufficiently good as soon as they permit the next move.
Knowing this permits a person to more easily detect the crossover from value adding to diminishing returns, to hit the point of being sufficient-to-purpose. That point has been nicknamed "satisficing" (Simon 1987, Bach URL).
Sufficiency for the Primary Goal
Intermediate work products are not important as models of reality, nor do they have intrinsic value. They have value only as they help the team make a move in the game. Thus, there is no idea to measure intermediate work products for completeness or perfection. An intermediate work product is to be measured for sufficiency: Is it sufficient to remind or inspire the involved group?
These three short stories illustrate how quickly sufficiency can be reached: Sufficiency in a Meeting
On a project called "Winifred" (Cockburn, 1998), I was asked partway through the project to review, for the approximately 40 people on the project, the process we were following and to show samples of the work products. The meeting would be held in the cafeteria. I copied onto overhead transparencies a sample of each work product: a use case, a sequence chart, a class diagram, a screen definition, a fragment of Smalltalk code, and so on.
As luck would have it, the overhead projector bulb blew out just before my little presentation. As I was wearing a white shirt that day, I asked everyone to move closer and held up the sample use case in front of my shirt. "I can't read it! " someone called out, not too surprisingly, from the back. "You don't need to read it, " I said. (The group laughed. ) "All you need to see is that a use case is paragraphs of text, approximately like this. There are lots of them online for you to look at. We write them as requirements, .. ." and I described who was writing them, who was reading them, and how they were being used. I held a sample class diagram in front of my shirt.
"I can't read it! " someone called out again. "You don't need to read it. " (The group laughed again. ) "All you need to see is that it is a diagram with boxes and lines. It is written by. .. " and I discussed the role of the class diagram in the project.
I went through the work products this way. In each case, all that the group needed was a visual image of what one of these things looked liked, who wrote it, who read it, and how it served the project. Real examples were all online and could be examined by anyone on the project.
This was communication sufficient to the purpose that people could have a visual memory of what each product looked like, to anchor the sentences about how they were used.
-
Навигация [ Часть 1. Глава 5. ]
Закладки
The complete discussion about when and where to apply concurrent…
The third problem is absence of feedback from the downstream…
Crystal Clear is the most tolerant, low-ceremony small-team…
Agility implies maneuverability, a characteristic that…
We see an example of needing these normalizing rituals in the…
1. Project name, job of person interviewed (the interviewee…
After much coaching for six months, his programs still looked…
The industry is littered with projects whose sponsors did…
On a new project, I would use Crystal Orange as a base methodology…
The group of 17 quickly agreed on those value choices. Developing…
The chart shows the state of the user stories being worked…
The surprising thing about human success modes is how nebulous…
For us as designers, it was possible to express both propositional…
While writing, reading, typing, or talking, we pick up traces…
Using the planning game in this way, the sponsors can…
The main question is, if you were funding this project, which…
13. (FIRST TECHNIQUE). .. your sword now having bounced upward,…
Figure 4-1. Elements of a methodology. Roles. Who…