2.6 Working in teams
2.6 Working in teamsCommunicationMake sure to exchange email addresses and phone numbers at the earliest opportunity. Make an address alias in your email program including the addresses of all the team members . Try sending a message to the whole team at least once per week, and preferably at least once between each class meeting. To supplement email, you can also bring copies of printed texts to team meetings to make double sure that everyone gets the message. Practice doing code hand-off. The idea is to (a) clean out the unnecessary files from your source directory (we supply a clean.bat batch file for doing this), (b) use the well-known WinZip utility to make a *.zip file, being sure to include all files needed for a successful build, and (c) hand off the code by emailing it as an attachment or putting it on a disk. Doing this right takes a little practice, so make sure before handing off your zip that you can in fact build the executable from the unzipped files. Take the time to test it. We discuss this a little more in Chapter 21: Tools for Software Engineering. Don't overdo the sending of attachments. It can be a burden to get a large *.zip file over email. It's also possible to exchange your new files in class, bringing them in on disk, or copying them across the lab's high-speed local network. In exchanging informational documents, remember that you can just paste the document into the email instead of making it a Word attachment. Due to macro viruses, people are increasingly uneasy about opening attached text documents. It's easy to do an Edit Select All on a text document, followed by an Edit Copy in the document and then an Edit Paste in the email document. If you do get a Word document you're uncomfortable in opening, use Windows Programs Accessories WordPad to open it, as this app doesn't support macros. Merging codeUnless you happen to be working completely alone, other people are going to be working on other code modules at the same time you work on the modules you're responsible for. Every day, or every few days, you'll have to merge the modules. That is, you put all the updated modules into one directory and try and build the program from there. Usually you'll have to fix a few things to get all of the new modules to build together. When working in a group it is especially useful to maintain a 'log' section of comments at the beginning of the modules you are changing. Merging the code is a bit tricky when two people have worked on the same module, but sometimes that can't be avoided “ it might be, for instance, that they've added new functions to their own modules, and these functions need to be called from the main module. In this case the two developers will each have changes to the main module. When two people have changes to the same module, someone needs to use a utility program which can locate the lines where similar files differ . Chapter 21: Tools for Software Engineering describes how to use the Microsoft Windiff utility. Team rolesThere are a number of separate tasks involved in making a complete program. Seven of the main tasks are the following.
In a company, these roles might be filled by seven completely different departments. Management might come up with the program design, the technical department might write and debug the code, the so-called 'build' or 'development' group would integrate the files and build the executables, the quality assurance or 'QA' department would test for bugs , the technical publications department would create the documentation, the multimedia department would provide bitmaps and sound files for use in the program, and marketing would go out and give demos of the program. On a small team of students a more typical situation is that the group jointly arrives at a design they all can agree on. And then each of the students might write some of the code. From week to week, it's necessary to integrate the code. It's important to have one single individual in charge of the code integration each week, as otherwise there will be uncertainty about which is the 'real' new build. Let's call this person the 'builder'. It is the responsibility of the builder to bring in the executable for the current class presentation or professor evaluation. If the builder fouls up and doesn't do his or her job, the team can get a poor grade. Remember to do code hand-off when it's time to change builders. As well as being a position of responsibility, being the builder is a position of some power, as it's up to the builder to decide which pieces of the code to put in, and which pieces to change or to leave out. For this reason, it's a good idea to let the position of 'builder' change from one student to another every couple of weeks, so that each student has the experience of being the builder. Another key role during the project is the 'documenter.' It's the documenter's responsibility to produce the written User's Guide and (later on) the help files. As the periodic project evaluations are based on the current executable and the current documentation, it's the builder and the documenter who determine the team's grades. As with the 'builder', it's a good idea to let the ' documenter ' role change every couple of weeks. A third element in the project evaluation is the 'presenter', that is, the student who stands up in front of the class and explains the current state of the program. Each student should be the 'presenter' at least once. At this level, it's not always useful to think of any one student as being a 'team leader'. All the students are still learning, and it's a good idea to try and let everyone have a go at a variety of roles. If anyone is really the 'leader' it's probably the 'builder,' which is why it is important to let this role shift from student to student every few weeks. In parceling out the coding duties , the fact that we'll be using object-oriented design is helpful. Once the team agrees on a class's members, it is (theoretically) possible to have someone implement the class members separately from someone who's writing code to use the class. In practice, though, these tasks need to be done hand-in-hand, as you always find that the way you plan to use a class will change your ideas about what the class's methods should be. And it's not really practical to write code that uses a class without having the class already implemented so you can test it. An easier kind of coding division is between the program and its interface. Sometimes it is practical to have one person working on the way the program runs while having someone else work on the menus and the dialog boxes. A common pattern is that two students get very involved in the coding, while the other one or two members do not. The students who write less code should try and do more in the other areas: the documentation, the testing, and the art. By the time you get down to the project's end and the last build, you'll have a good idea of which individual is going to do the best job at the final coding push, and this will be the person the team should pick for the final builder. By the same token, there will be a person who works best with the documentation, and that person should handle the final documentation. Finally there will be a student who's going to be your best candidate for the presenter. For the final version of your program, use the most appropriate team member for each role. Inevitably the members of the team are going to be better at different things. It's important for each member to find some area that he or she 'owns' and is responsible for during the final push. For fairness, nobody should do everything, and everybody should do something. In order to try and balance the contributions of team members, the author usually groups together students who have accumulated similar cumulative point totals on the assignments and tests given before the teams are assigned. Although a reasonable standard policy is to give the same grade on a project to each member of the team there can occasionally be some variations within the team's grades based on the individual contribution. |
