| Lecture 3: Uses Cases Again; Working in Pairs | ||||||||||||||||||
Use Cases RevisitedStudy this simple story, tease out the concepts, sketch a graph, write use cases:
Compare your use cases with the graphs of other people. Map the concepts in your use cases to those of the graph. Are any concepts missing in the graph? Are relations missing? Are your use cases overlooking concepts from the graph? Working in PairsWorking in pairs means working together. It does not working separately and combining the results of the separate work into one product. At any moment, one person is the driver and the other one is the navigator. The terms are borrowed from driving cars; you may also find pilot and co-pilot. Furthermore, partners may switch roles while they work together on a task, though they don't have to. Some pairs designate drivers for entire tasks. Sometimes they just switch during tasks. It depends on the emphasis and the organization of the surrounding team. Examples of how you should work together in this class:
Perceived Problems of Pair ProgrammingPair programming comes with several perceived and true disadvantages. Williams and Kessler (see end) call them "myths". Here are the ones that you need to know about both for this course and for working in industry later:
Sometimes people report that a partner discovers nothing but syntax errors during programming sessions. This is an easily overcome problem with pair programming. Give your driver time to find mistakes on his own. Instead focus on the larger picture. Don't look for the pot holes on the road; look for rail road crossings, forks, and other markers on the road map. Once you figure out this part your collaboration is likely to be smooth. TeamsMany companies use programming teams. Typically a programming team consists of a chief programmer and his co-pilot; a tools person who knows the chosen language, its libraries, and the chosen IDE really well; the archive person who manages the code archive and the version control system; the programmers who take on specific components; and sometimes other support staff, including testers, technical writers, and customer representatives (literal or virtual). The chief programmer and his co-pilot tend to design components and their interfaces. The rest of the team implements these components. At some point, the chief programmer and his co-pilot begin the integration work. This last step is often full of surprises and requires deep and broad changes to the product. Don't ever believe that integration is a one-shot activity. In this course, we will not practice team programming. Your projects are pieces that are usually assigned to solo programmers in a team. Do not distribute the work and integrate it later. Integrating causes such a huge overhead that you are likely to fail. Work in pairs. Bibliography |
last updated on Tue Jun 9 22:03:19 EDT 2009 | generated with PLT Scheme |