7

I just started doing PhD and we are supposed to do a project for a class, there are 14 people taking the class and we are supposed to develop a system all together.

I was away from academia and working in the industry before, and I know it is very hard to manage even a couple of people towards the same goal.

We are going to make the first meeting in a couple of weeks. First, I will suggest using a version control system like SVN. Second, I will try to take the lead for the architecture of the system, because I think I am more experienced. Since the class is about computer vision and I anticipate that most of the people's background is research related so there is a big chance that I am more experienced. I will gladly hand architecture to someone else if he/she is more experienced.

What else should we do to progress without much hassle?

PS. You can assume every one of us is going to work remotely, and meet once in a week at it's best (not everyone will attend though). And the project needs to be finished in 2 months. It does not need to be a perfect, complete product, we just need to make a prototype.

PPS. The aspects of the group reminds me of open source project groups, maybe the answers will be helpful for those groups as well.

Thomas Owens
  • 82,739
nimcap
  • 613

3 Answers3

8

  1. A distributed VCS is a much better choice than SVN. Mercurial should fit your needs nicely - it's similarly powerful to Git, but it is much easier to wrap your head around it and it has nice documentation. However, if it turns out that most people in the team (or even just you!) are much more familiar with SVN and are not in the mood to learn a DVCS, I wouldn't push for it.

  2. Get an issue tracker that is as light and easy to learn as possible. If the learning curve is too steep, people will not really use it, and you'll end up with no issue tracker at all. That's why I wouldn't advice JIRA or Bugzilla. Lighthouse has always worked great for me.

  3. Introduce some sort of lightweight agilish process. Having a slightly better structured environment may help the team deliver the prototype.

  4. 14 people looks like a rather large team. Maybe you could subdivide yourself into 3 smaller teams responsible for different parts of the prototype?

  5. However, try to enforce some sort of discipline when it comes to the non-essential (not directly related to research) parts of the project. After all, computer vision stuff is hard enough as it is - you don't want to fail because of a broken build system or something similar, right?

Last but not least: you shouldn't overdo the whole managing a project thing. After all, if I understand correctly, the goal of the project is to do science - not to have an industry level process. Try to keep all the tools as lightweight as possible - otherwise people will start working around them, and you'll end as if you were doing freestyle development (that's for example why I think Mercurial is a better choice than Git, even though I personally prefer the latter). Finally, remember that academia is more about Learning Cool Stuff on the Way than about Getting Things Done. Try to have fun!

Ryszard Szopa
  • 1,810
  • +1: for something as short as 2 months, any project management will get in the way. Heck, even the most agile 'processes' will only have 3-4 iterations in that time. – Steven Evers Oct 09 '10 at 22:18
4

Note that this isn't specific to school since the problem you said is a pretty generic issue

  • Pick a reliable VCS and stick with it. SVN is the easiest but depending on how your developing it (see below), you could also consider something a little less linear. Something like Git (but not Git itself) would be better since you can do easy branching.
  • Divide the project into distinct modules. This way you can hand somebody a module outline and say "Write this". Code separation helps greatly.
  • Get something like Bugzilla or JIRA to track issues/features (unless your using something like Google code that has this stuff built in) and assign people reports there. This way somebody can just browse through the reports and figure out who's working on what.
  • Pick one or two of the most experienced/knowledgeable people to be project leaders as well. This way it looks like more of a group effort and your not the only weak link in the design ("Where's nimcap?" "Oh he's sick" "Well what am I supposed to do? I've [insert problem]")
Community
  • 1
TheLQ
  • 13,580
-1
  • A DVCS like git or hg sounds more appropriate than svn for what you're descibing.
  • Setting up some web based project management tool would help in keeping track of who's working on what etc.
julien
  • 1,533