methodology for a team coursework [closed]

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 3 years ago.

Improve this question

I need a methodology to organize my team for a university assignment.

I am a university student and already have some programming experience. My experience of working in teams of more then 2 people on a relatively large project is that everything usually gets done very quickly and badly in last week or so because of planning, organization and communication issues. In January I will have to do a (quite challenging for my skill) programming project (Java application on Oracle) in a team of 6. I already know my team members and was elected the project leader. It won't be realistic to expect people to get together for any meaningful-sized amount of time - everyone is free at different time and probably nothing more then weekly 1-hour meetings is rea开发者_StackOverflowlistic. People are hard-working and devoted to success, but everyone has their own circumstances. Mostly distributed work is the likely way to go.

I've looked through XP, Scrum, but they all require to sit together (unlikely), aimed at full-time development of a project (people have other assignments and part-time jobs) and customer involvement (we will have written specs and as far as experience goes, emails from tutor will be answered at best in 2-3 days).

Any suggestions how to organize people and divide the work? I am serious on researching this topic, because there will be much more of this kind of works later on.

Any help appreciated.

---

While not a programming project, I am currently in a position similar to you - elected group leader in a 5-person group assignment. We will be finished two weeks early, so I would say that the group has been a success. A few things that I did, as group leader, to ensure that this happened (I am also drawing on experience of managing projects in a 'real world' situation, so perhaps have a little more advantage):

• Set ground rules from the offset. Make sure that everyone knows what is expected of them: Meeting attendance, work deadlines, what to do if they are struggling. We have a system at our university where people can be removed from groups if they are not 'pulling their weight.' If your uni has a similar thing, the steps taken for you to initiate that procedure should also be outlined. For example, miss two meetings and you will be 'yellow carded'. Miss another, then it's a 'red card'.
• Break the assignment into manageable chunks and then decide on a time line. If you already know what should be done each week, it will be much easier to assign tasks each week. Or, of course, whatever time frame you decide on.
• Meetings. There should be an initial meeting where everything above is decided on, probably a rather long meeting (our first meeting took 90 minutes). In that meeting, set out tasks to be completed before the next meeting. Then, in each subsequent meeting, validate the work that has been done by each person, ensuring it is both complete and correct. And then, of course, delegate tasks to be completed for the next meeting. And so on...
• Each person, pair, or whatever, should go away and do the work themselves, independently. Because meeting times are so short (as were ours), they should be about making sure everything is completed, plans are made and tasks are delegated.
• Communication. I set up a forum for the members of my group to communicate about the work they are doing and to upload completed material. I also have a specific sub-forum where people can post up any problems they might have - with a rule that they should do so within plenty of time of the next meeting - so that others can help, or tasks can be re-assigned. It's important that each meeting has minutes taken and an agenda set for the next meeting. I get these uploaded to the forum so that anyone who did miss a meeting isn't left in the dark and know exactly what they need to do.

Because your project is a programming project, the following may well help the group stay organised and cohesive:

• Early on - preferably in the first meeting - break your program into 'modules' or classes/procedures/whatever; basically, manageable, stand-alone chunks of code to be written. These can then be assigned to someone each week. To make sure that time won't be wasted on changing code needlessly later on, decide on your global variables, if any. It might be a good idea to also decide on the methods and properties of each class before any coding starts.
• As sgolodetz suggested, you might also want to use version control to keep track of code as it's being written. Again, if you do this, make sure that rules/guidelines are in place for when/how often to update.
• Perhaps arrange that people working on related tasks meet up between meetings to make sure their code integrates well. This way, they can work together to make sure each person's code 'cooperates' with the other's.

I think the key here is to be organised. Have a strict, detailed plan and stick to it as much as possible.

In university, at least, I think it's important to have a certain amount of ruthlessness - remember that if people don't pull their weight it will affect your grade as well. It might just be me, but once the rules are set, they should be abided by and breaking them (ie: Not completing work or not letting people know you're struggling, not turning up for meetings, etc) should always result in the 'card' system - as would have been agreed at the start. It's your future on the line, so don't let people who don't care jeopardise that.

---

I was one of the leaders of a team project (6 people) last year at university. Based on my experience, I have a couple of key points.

While forums, online chat, email, SVN commit messages etc. are all very good communication mechanisms (and I do recommend them), nothing is more important than weekly meetings. These should involve delegating/discussing/monitoring tasks, talking about general issues and the bigger picture, making group decisions, and simply using your app and identifying issues with it as a group. By doing this, it becomes instantly obvious where people are at with their tasks, where they might be confused, and whether they understand what needs to be done. This is crucial because the feeling of being 'lost' and having no idea where to start is often the biggest obstacle to making progress, rather than laziness. And besides, group decisions are best made in person where you can bounce ideas off each other... and this all helps to establish a sense of shared ownership.

There is no one best way to formulate, delegate and monitor tasks. But it is important that you can divide and parallelise (as much as possible) the workload into sensibly sized tasks and identify dependencies between them. Our group maintained a TODO file in our repository which consisted of a list of tasks, dates, and bugs. We prioritised tasks according to factors such as whether they were mandatory requirements or optional niceties (think MoSCoW), whether they were on the critical path, how much risk/uncertainty was attached to them etc. We allocated one or two people to most tasks based on their strengths and whether they actually wanted to do the task, but we also left some tasks open to whoever wanted them (this is potentially dangerous too). A couple of us stronger programmers also played 'floating roles' meaning we could help out with any task. A key point is that the task descriptions should contain anything discussed in the meeting... the what, the why and a couple of 'how' sentences as a kickstart (i.e. "to accomplish this, you might want to read up on blablabla")... anything which makes it easy for your teammates to slip into a task.

---

A few thoughts:

• Communication - perhaps use IRC or a wiki
• Assigning people to tasks - you need to figure out where people's strengths and weaknesses lie, break down the project into chunks and assign them accordingly
• Monitoring - a big problem with projects where people are working remotely is that they may not do the work on time; you need to think about how to keep on top of this (e.g. use version control, and look at the check-ins) - to make this work, everyone needs to buy into it up-front
• Strategic reserve - it might be worth having one person (perhaps you if you're the strongest programmer) who takes on tasks across the project that other people are finding difficult to prevent people getting bogged down

---

First, set up a version control system for the project. This serves the purpose of the code that has been checked in is available to all the team, you can revert to earlier versions if someone breaks something, and all decent professional shops use source control, so it is a job skill it is good to be in the habit of using.

Now you have a way to check on progress. If Joe hasn't cheked anything in, you know he is not doing the work. IF Sally quits in mid_term, you have a record of everything she already did.

Another thing you want to so is code review. Everybody's code gets reviewed by one or more other people. You will all learn a lot from this and this too is a necessary skill for the professional developer.

Plan what has to be done in what order. Make sure the people developing the stuff that everything else depends on are the most reliable devs on your team and that they will meet their early deadlines or nobody else will be able to do their parts.

Weekly progress meetings and don't be afraid to call someone out for not doing his or her part. The sooner you identify a person not pulling his weight, the sooner you can address the issue.