Working in a team question
-
Hello I am about to work in a team of four (all programmers) on a small game at university. It should take around three to four months of development time and I have hit a wall already! What roles could be subdivided logically in such a small team? Looking on-line only really shows how larger teams are broken down, for example one person working on the GUI is probably over kill for what we need, yet I still don't know what roles we could assign... Any suggestions? :laugh: Also we have a similar skill set, so speciality based on skills wont really come into play.
I highly recommend looking into self-organized teams, iterative development, and kanban. Story point mapping can be a great tool for iterative development (so that in your first week, you have a full version of the app, but just a skeleton, and you build on it from there). Most of my development has been in a team of five or fewer developers, and I find this really works well. This is a good resource: http://www.personalkanban.com/pk/[^]
-
Michael Bergman wrote:
Height, weight, and age
I think 'Front Bumps' should be in the criteria.
I don't speak Idiot - please talk slowly and clearly 'This space for rent' Driven to the arms of Heineken by the wife
Right. And I'm the one who took the rep points hit.
m.bergman
For Bruce Schneier, quanta only have one state : afraid.
To succeed in the world it is not enough to be stupid, you must also be well-mannered. -- Voltaire
Honesty is the best policy, but insanity is a better defense. -- Steve Landesberg
-
Hello I am about to work in a team of four (all programmers) on a small game at university. It should take around three to four months of development time and I have hit a wall already! What roles could be subdivided logically in such a small team? Looking on-line only really shows how larger teams are broken down, for example one person working on the GUI is probably over kill for what we need, yet I still don't know what roles we could assign... Any suggestions? :laugh: Also we have a similar skill set, so speciality based on skills wont really come into play.
If you want it all done your way, you have to do it yourself.
When posting here, I do not represent anybody but myself.
-
Hello I am about to work in a team of four (all programmers) on a small game at university. It should take around three to four months of development time and I have hit a wall already! What roles could be subdivided logically in such a small team? Looking on-line only really shows how larger teams are broken down, for example one person working on the GUI is probably over kill for what we need, yet I still don't know what roles we could assign... Any suggestions? :laugh: Also we have a similar skill set, so speciality based on skills wont really come into play.
Don't divide, unite. In such a small team as yours, assigning distinct roles to people is IMO counterproductive. Think before you start working. Even if you're late, and have hit a wall, drop everything and start making a plan. If there's one with better leader qualities or skills, he should take coordination upon himself, but not necessarily leadership. If one of you has a stronger and more clear vision than the others, you should all follow him, if you're convinced he's on to something, even if you all have different ideas, but other than that, subdivisions of any sort would be IMO harmful. First make it work, than make it faster. What does a plan mean, in terms of SW dev? Define your system in terms of packages and interfaces. Then distribute work. Than define a way to integrate. Periodically check upon each other and see what progress you have made. Don't fear to move tasks from one another. You know you're on the right path when anybody can do maintenance on anybody else's code. Once the interfaces are defined, start writing tests first, which test only via the interfaces - and which of course will fail, but act as very good descriptions of the interfaces. Passing these tests around will teach each team member how the interfaces are supposed to be used, and allow for early review and critique on interfaces - which is important to happen before implementation. Also, since you aren't going to sit in a room eight hours a day with all team members around, create an architecture based on a few essential abstractions, and implement everything around these abstractions (i.e. define a small set of interfaces - 2-3 dozen at most, ideally less than a dozen - and build your entire application only out of classes implementing these interfaces). This will yield an easily understandable architecture, and allow you not to spend too much time explaining to each other what you did - as long as you stick to an interface with a well defined contract, it doesn't matter how many implementations of that interface you add, or what the particular implementations are.
-
Hello I am about to work in a team of four (all programmers) on a small game at university. It should take around three to four months of development time and I have hit a wall already! What roles could be subdivided logically in such a small team? Looking on-line only really shows how larger teams are broken down, for example one person working on the GUI is probably over kill for what we need, yet I still don't know what roles we could assign... Any suggestions? :laugh: Also we have a similar skill set, so speciality based on skills wont really come into play.
“If you don't know where you are going, any road will get you there.” In short, study the scrum process, find yourself a product owner, set up a back log with user stories and start working on the first. Stop optimizing resources (i.e. Worrying about who should do what etc.). Start working using an agile process, with focus on most important feature first :)
-
Hello I am about to work in a team of four (all programmers) on a small game at university. It should take around three to four months of development time and I have hit a wall already! What roles could be subdivided logically in such a small team? Looking on-line only really shows how larger teams are broken down, for example one person working on the GUI is probably over kill for what we need, yet I still don't know what roles we could assign... Any suggestions? :laugh: Also we have a similar skill set, so speciality based on skills wont really come into play.
I would say it sort of depends on what you want out of the project. If you want to learn something, enjoy it, challenge yourselves, etc, I would suggest some crash-research into scrum & agile (if you haven't already) and run the project that way. Start with your user stories (all of you), split yourselves up into arbitrary scrum roles (if your skill-sets are all similar, this can even be random if you like), create your backlog, plan and execute your first sprint (maybe 2 weeks if the project is 3-4 months total). Then for the next sprint, rotate roles. That way, you all learn something new, hack-y "silos" are prevented, you probably end up with a pretty decent product at the end, and you all learned a marketable set of new technical and organizational skills (working in a cohesive scrum/agile environment). And don't forget to keep it fun! :)
-
Hello I am about to work in a team of four (all programmers) on a small game at university. It should take around three to four months of development time and I have hit a wall already! What roles could be subdivided logically in such a small team? Looking on-line only really shows how larger teams are broken down, for example one person working on the GUI is probably over kill for what we need, yet I still don't know what roles we could assign... Any suggestions? :laugh: Also we have a similar skill set, so speciality based on skills wont really come into play.
Until you have reached the point where you've identified individual tasks, you can't assign any. Forget roles for the moment, as without tasks you have no need to assume a role. You've got a task: "Write a game." What kind of game? What do you have to have to play the game? Gather your requirements just like an analyst would gather business requirements in the business enterprise; all four of you participate in this phase. Until you know what it's required to do, you can't assign tasks, because you don't know yet what you're doing.
-
Someone should be the architect and know the stuff well enough that he can write enough application skeleton so that every other developer can happily develop on his own little piece and integrate it seamlessly in the big picture. Other than that everyone can work on the little bit that he likes more...
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station.... _________________________________________________________ My programs never have bugs, they just develop random features.
The only problem is that usually every last loser on the team wants to be an "architect" and boss others around. Power corrupts, even tiny bits of it, like the honor of being "first among equals"
-
The only problem is that usually every last loser on the team wants to be an "architect" and boss others around. Power corrupts, even tiny bits of it, like the honor of being "first among equals"
Haha, good one! :) Well, maybe they should have an election! And a counter power chanber as developer commity that can demote the architect on 2/3 majority!! :P
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station.... _________________________________________________________ My programs never have bugs, they just develop random features.
-
Hello I am about to work in a team of four (all programmers) on a small game at university. It should take around three to four months of development time and I have hit a wall already! What roles could be subdivided logically in such a small team? Looking on-line only really shows how larger teams are broken down, for example one person working on the GUI is probably over kill for what we need, yet I still don't know what roles we could assign... Any suggestions? :laugh: Also we have a similar skill set, so speciality based on skills wont really come into play.
As you all are similar skills, then you should rotate the working of the guys. This will help in development and the guys working will not get any distraction from the work.