Agile Software Development
Автор: Alistair Cockburn /
CHAPTER 1. A Cooperative Game of Invention and Communication A Second Look at the Cooperative Game
-
Часть 2
-
We did have a drawing showing the process we were following, but as far as I know, nobody other than the project managers and I ever looked at it. Sufficiency of work Products
Project "Winifred" project was a fixed-time, fixed-price project costing about $15 million, lasting 18 months, with 24 programmers among 45 people total. We ran it with the cooperative game principle in mind (the principle hadn't been defined back then, but we knew what we wanted), with as much close, informal communication as possible. At the time use cases weren't very well defined, and so the writers wrote just a few paragraphs of simple prose describing what was supposed to take place, and some of the business rules involved.
The analyst responsible for a use case usually went straight from each meeting with the end users to visit the designer-programmers, telling them the outcome of the meeting. The designer-programmers put their new knowledge directly into their programs, based on the verbal description.
This worked effectively, because the time delay from the analyst's hearing the information in the meeting to the programmer's knowing of its effect on the program was just a matter of hours.
There was an odd side effect, however. Halfway through the project, one of the programming leads commented that he didn't know what purpose the use cases were supposed to serve: They certainly weren't requirements, he said, because he had never read them.
The point of the story is that the casual use cases were "sufficient to the task" of holding the requirements in place. The communication channels and the shared understanding between the writers and readers was rich enough to carry the information. Chrysler's Ultralight Sufficiency
Chrysler's Comprehensive Compensation project (C3 1998) ran even lighter than project Winifred. The ten programmers sat together in a single, enormous room, and the team tracker and three customers (requirements experts) sat in the next room, with no door between them. With excellent intra-team communications and requirements available continuously, the group wrote even less than casual use cases. They wrote a few sentences on an index card for each needed system behavior. They called these "user stories. "
When it came time to start on a user story, the programmers involved asked the customer to explain what was needed and then designed that. Whenever they needed more information, they asked the nearby customer to explain. The requirements lived in the discussion between the participants and were archived in the acceptance and unit test suites. The design documentation also lived in a mostly oral tradition within the group. The designers invented new designs using CRC card sessions (Wilkinson 1995). In a CRC-card design session, the designers write the names of potential classes on index cards and then move them around to illustrate the system performing its tasks. The cards serve both to incite new thoughts and to hold in place the discussion so far. CRC cards are easy to construct, to put aside, to bring back into play, and are thus perfectly suited for an evolving game of invention and communication.
After sketching out a possible design with the cards, the designers moved to the workstations and wrote program matching the design, delivering a small bit of system function.
The design was never written down. It lived in the cards, in memories of the conversations surrounding the cards, in the unit tests written to capture the detailed requirements, in the code, and in the shared memories of the people who had worked together on a rotating basis during the design's development.
This was a group highly attuned to the cooperative game principle. Their intermediate work products, while radically minimalist, were quite evidently sufficient to the task of developing the software. The team delivered new function every three weeks over a three-year period.
Sufficiency in the Residue
Thus far, the topic of discussion has been the primary goal of the game: delivering working software. However, the entire project is just one move within a larger game. The project has two goals: to deliver the software and to create an advantageous position for the next game, which is either altering or replacing the system or creating a neighboring system.
If the team fails to meet the primary goal, there may be no next game, and so that goal must be protected first. If the team reaches the primary goal but does a poor job of setting up for the next game, they jeopardize that game.
In most cases, therefore, the teams should create some markers to inform the next team about the system's requirements and design. In keeping with Naur's programming as theory building and the cooperative game principle, these markers should be constructed to get the next team of people reasonably close to the thinking of the team members who completed the previous system. Everything about language games, touching into shared experience, and sufficiency-to-purpose still applies.
The compelling question now becomes this: When does the team construct these additional work products?
One naive answer is to say, "As the work products are created. " Another is to say, "At the very end. " Neither is optimal. If the requirements or designs change frequently, then it costs a great deal to constantly regenerate them—often, the cost is high enough to jeopardize the project itself. On the other hand, if constructing markers for the future is left to the very end of the project, there is great danger that they will never get created at all. Here are two project stories that illustrate: Continuous Redocumentation
Project "Reel" involved 150 people. The sponsors, very worried about the system's documentation becoming out of date and inaccurate, mandated that whenever any part of the requirements, design, or code changed, all documentation that the change affected had to be immediately brought up to date. The result was as you might expect. The project crawled forward at an impossibly slow rate, because the team members spent most of their time updating documentation for each change made.
The project was soon canceled. This project's sponsors did not pay proper attention to the economic side of system development, and they lost the game. Just-never documentation
-
Закладки
Using the planning game in this way, the sponsors can properly…
Walk around your place of work. Notice · The convection currents…
Crystal Clear is the most tolerant, low-ceremony small-team…
While writing, reading, typing, or talking, we pick up…
The complete discussion about when and where to apply concurrent…
The surprising thing about human success modes is how…
That it is people who design software is terribly obvious.…
The group of 17 quickly agreed on those value choices.…
Agility implies maneuverability, a characteristic that…
We see an example of needing these normalizing rituals in the…
After much coaching for six months, his programs still looked…
Types of Methodologies Rechtin (1997) categorizes methodologies…
In arguing for the Theory Building View, the basic issue…
The chart shows the state of the user stories being worked on…
The industry is littered with projects whose sponsors did not…
On a new project, I would use Crystal Orange as a base…
The third problem is absence of feedback from the downstream…
13. (FIRST TECHNIQUE). .. your sword now having bounced upward,…
Games are not just for children, although children also…