The Software Engineering Principles course I'm currently taking is meant to prepare us for Software Engineering Practices, the "Senior Experience" course for CS majors (and for my made-up degree). The Practices course involves working on a big group project for the entire semester, doing all phases of the software development cycle (requirements, design, coding, testing, etc.). So to help us prepare for that, we've been doing a small group project in our current class.
It hasn't been very good. Our class only had five students, and one dropped out fairly early in the project after having an argument with me (a very civil argument over a mild question; I'm not sure why he got as angry as he appeared to, and I'm not at all sure this is why he dropped out).
Of the four we have left, there is me (smart, moderately diligent), W (smart, moderately diligent, extremely busy and with almost no time to put into school right now), H (smart, a total fuck-off), and B (learning-disabled, may have skills that have not yet been revealed, has not done any work to date). And Dr. P has been contributing to the project himself.
Nevertheless, it's been my best group project for school ever. When we talk about design issues in class, and really hammer them out, it's incredibly fun and feels really productive. I never thought working on a team could be like this. (I can only imagine what it would be like if I had teammates who ever did any work.)
Our project itself currently resides in a file repository managed by cvs. Basically cvs manages it so that multiple people can work on various files, sort of checking them out and then back in with changes. It stores all of the previous version of files, so if you need to revert to one that you didn't yet screw up, you can. When people make changes, they upload their changed files with a comment about what they did.
It's fun checking the repository every day for new stuff, and reading the history logs (the comments people made when they checked things in) on the rare occasions that someone has done something. (Actually, Dr. P does something fairly often, and I usually do some work a couple of times a week, but otherwise, almost nothing ever happens.)
Here are a few things I have learned about doing this kind of group work using a repository.
Donut offenses - Don't break stuff that other people need to do their work. In some workplaces, doing so is known is a "donut offense" and you owe one donut to each person whose work you interrupted.
Submit early - You shouldn't wait until you get your stuff (whatever you're working on) completely finished to put it on the repository. Just because you created a file doesn't mean it's "yours" - it's better to go ahead and upload it when you're at a stopping point so other people can work on it in the meantime. Relinquish ownership.
Group decisions - Design issues need to be ratified by the group. It's fine to go implement stuff on your own, or make mock-ups or prototypes of anything you think might be interesting, but you can't change the project design without consulting with your teammates. For instance, we have a database schema that has been fairly well hammered out in a lot of group discussions. I've written all of the code for the schema, but I can't just go adding stuff without discussing the design with the group.
No ego - A lot of the above relies on not having a lot of ego-attachment to your work. One way you can be productive, as I mentioned, is to make mock-ups or prototypes of things you think might be neat. But this only works if you understand that your prototype is probably not going to become the product, and your mock-ups may be totally trashed (gently) by your teammates. You have to do everything from the perspective of trying to be useful to the collective effort, rather than with the idea that your stuff is the best and will naturally be adopted. Or you have to at least fake it pretty well.
Avoid parallel play - Some people in our group always just do their own stuff without seeming to even check the repository or message boards first. Sometimes what they do has already been done by someone else, or someone else has made remarks that might influence the decisions you make. So even though it's OK to do some stuff totally on your own and then submit it to the group, it's good if you keep in the loop about what's going on in the project as a whole rather than just totally doing your own thing. ("Parallel play" is what they call it when tiny children, who aren't old enough for social interactions, play together. They basically just play alongside each other.)
Groups aren't useless - A few times now, we've had a design task (mostly around the database our product is based around), and I've spent time in advance thinking about it a lot, and have been pretty sure I had it nailed down. One time I wrote up a whole document with two approaches to something, and arguments about why one approach was superior. In that case, trying to explain it to the group, and discussing why one design or the other might be better, yielded a third design that was better than either of my original two. In every case, group discussion has resulted in better designs than anyone had come up with on their own. (A note about design: it's best IME to do design on your own and then hash it out in a group. You can't really design things "on the fly" - you get much better ideas if you think about it for a couple of days by yourself. So I'm talking about refining the design or choosing between alternatives.) This kind of goes against our common sense that groups just muddle things up and accomplish nothing.
Be a self-starter - Sometimes people in the group don't do anything because they feel like nobody told them what they were supposed to do. When you're working in a group of peers, you can't expect someone to tell you what to do. You know what's going on with the project - see what's needed and go do some of it. If you can't think of any defined tasks you can do, go do something you think might be helpful (remember: no ego attachment!) even if you're not sure it's "wanted."
It's sad that this crummy group has been my best group work experience ever, but the parts that have gone well (and even badly) have been real eye-openers.
