views:

46

answers:

3

Hi, I have a task assigned to me but I am not a project manager. Doh. So here is the problem. Imagine that you have 100 tasks which should be done in 1 year. So we want to do 5 or six releases during this year. Our team is small, about 10 people. Now we go trough all the tasks and mark 15 of them for example to be released in 2 months. But 1 developer is ready with his tasks 1 month ahead and he has no tasks until we release.

We use SVN and currently we work in the trunk. How you suppose to organize our SVN repository? We want the developer who finished his tasks to start working on tasks for the next release. If we create a branch for each release and work there (trunk is only a result of merging with branches) is something like suicide.

Can you give me suggestions. Thanks

A: 

make each release a tag in SVN. that way every time you commit something, you can make sure you're committing it towards a specific release.

and when the time comes to make a release, you can just check out all of the files tagged as release 1 (or 2 or 3 or 4).

if you make a branch for every release, you will have to merge a branch back into the head after the release (you want the code in release 2 to contain everything you did in 1, dont you?)

Oren Mazor
Generally, once something is tagged, it doesn't change. Ideally, he should have each person start on trunk, tag releases as they happen, and if someone gets ahead, either a) shift tasks forward accordingly or b) have them work on a branch until after the release.
CaseySoftware
you're right. the best bet is to branch when you get ahead and merge back in after the release.
Oren Mazor
thats right Oren. This was actually our best option before posting the question => "the best bet is to branch when you get ahead and merge back in after the release"
mynkow
+2  A: 

Allow your developers to assist each other and swap tasks, so that if one developer is still on release 1 but two other developers are ready to go to release 3, the developers ahead of schedule can work to dig out the guy who's far behind.

That keeps you at three branches, tops, which is definitely mergeable, and easily merged if folks keep notes.

Dean J
hmm, interesting. I really liked the swap.
mynkow
A: 

You should take a look at a typical DVCS branching model. Even while you are on SVN, there are still good insights on how to use different branches. A good branching model is important, since it seems you are going to develop different parts of the software at the same time.

But 1 developer is ready with his tasks 1 month ahead and he has no tasks until we release.

This seems you assign tasks to developers individually. This sounds very like micro-managing, and should be avoided.

I would suggest to look at an agile project management like scrum, especially the develop in sprints and the prioritized product/sprint backlogs parts. The idea is that the team always has a list with the next things to do, and also knows which is the most important one. Every member works on one item at a time, but all members are working on the same product/release. So there is no time waste when someone has done "it's" task, since then the next item from the backlog gets processed.

Rudi