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.
-
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.
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.
-
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.
Just get a good design chart started. Rather than worry about how to break up the team, just make sure it's modular (weather it's a functional chart, object design, etc) and then just work on it one piece at a time. Then anyone can pull from any part, and no one gets assigned a specific role.
-
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 more answers, the merrier! :)
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.
-
Just get a good design chart started. Rather than worry about how to break up the team, just make sure it's modular (weather it's a functional chart, object design, etc) and then just work on it one piece at a time. Then anyone can pull from any part, and no one gets assigned a specific role.
So far it seems that a key pattern is, someone overlook the flow of information through the system and the others can add to it over time somewhat multi-responsibly. Big Grin | :-D Similar answer to what me and the team thought, but we are noobs - what do we know? xD
-
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.
Its a good one, If only one person do the skeleton then the application will look like an application done by a team as one. It will be neat.
-
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.
For uni purposes, I'd agree on the basics of the game, and have: a) one person assigned to documenting what it is to do. b) one person would be assigned to obtain resources (sound, graphics) and provide routines to supply them (Playsound(), ShowSprite() etc. c) one person design the main game logic d) one person as the final assembler - putting it all together, testing and doing things like menus You can then assign the roles according to availability (i.e. the documenter needs to get his act together earlier, but will be finished earlier too) person b) may need help, depending on what framework / language you are using. person c) may need help, depending on the game complexity person d) may need help, depending on how well a) b) and c) did!!!! The idea is that a) drafts the documented game design. b) can provide some quick sound and video routines - enough to display something and make a noise and c) and work on the logic, based on a) and b) initial work a) and b) can continue to improve their parts - depending on feedback from the others (e.g. the initial design is far too complex, change the docco!) Person d) can write the framework of the menu, help or whatever, ready to slot in the game logic sound and graphics of course, you should try to work together rather than in isolation - but I reckon splitting it like that will give good mileage for a uni project The critical point in all this is person c) so (s)he should maybe be the driver of the project - i.e. if they need help, the others come a-runnin'
MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
-
For uni purposes, I'd agree on the basics of the game, and have: a) one person assigned to documenting what it is to do. b) one person would be assigned to obtain resources (sound, graphics) and provide routines to supply them (Playsound(), ShowSprite() etc. c) one person design the main game logic d) one person as the final assembler - putting it all together, testing and doing things like menus You can then assign the roles according to availability (i.e. the documenter needs to get his act together earlier, but will be finished earlier too) person b) may need help, depending on what framework / language you are using. person c) may need help, depending on the game complexity person d) may need help, depending on how well a) b) and c) did!!!! The idea is that a) drafts the documented game design. b) can provide some quick sound and video routines - enough to display something and make a noise and c) and work on the logic, based on a) and b) initial work a) and b) can continue to improve their parts - depending on feedback from the others (e.g. the initial design is far too complex, change the docco!) Person d) can write the framework of the menu, help or whatever, ready to slot in the game logic sound and graphics of course, you should try to work together rather than in isolation - but I reckon splitting it like that will give good mileage for a uni project The critical point in all this is person c) so (s)he should maybe be the driver of the project - i.e. if they need help, the others come a-runnin'
MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
yes, and shout at them a lot. They will respect you for that. Bryce
MCAD --- To paraphrase Fred Dagg - the views expressed in this post are bloody good ones. --
Our kids books :The Snot Goblin, and Book 2 - the Snotgoblin and Fluff The Snotgoblin for the Ipad -
yes, and shout at them a lot. They will respect you for that. Bryce
MCAD --- To paraphrase Fred Dagg - the views expressed in this post are bloody good ones. --
Our kids books :The Snot Goblin, and Book 2 - the Snotgoblin and Fluff The Snotgoblin for the Ipadi found beer more effective!
MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
-
i found beer more effective!
MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
-
Then Shouting them :beer: is the ultimate management tool. :thumbsup:
I don't speak Idiot - please talk slowly and clearly 'This space for rent' Driven to the arms of Heineken by the wife
A five, Sir, for linguistic ingenuity!
MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
-
A five, Sir, for linguistic ingenuity!
MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
-
_Maxxx_ wrote:
A five, Sir, for linguistic ingenuity!
You are a gentleman.:thumbsup:
I don't speak Idiot - please talk slowly and clearly 'This space for rent' Driven to the arms of Heineken by the wife
That's what you think :)
MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
-
That's what you think :)
MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
-
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.
venomation wrote:
What roles could be subdivided logically in such a small team?
Height, weight, and age. Not necessarily in that order.
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
-
venomation wrote:
What roles could be subdivided logically in such a small team?
Height, weight, and age. Not necessarily in that order.
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.
-
What I think does not really matter (Damned Banana Bender) now does it!?
I don't speak Idiot - please talk slowly and clearly 'This space for rent' Driven to the arms of Heineken by the wife
Not one jot, sir, not one jot.
MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
-
For uni purposes, I'd agree on the basics of the game, and have: a) one person assigned to documenting what it is to do. b) one person would be assigned to obtain resources (sound, graphics) and provide routines to supply them (Playsound(), ShowSprite() etc. c) one person design the main game logic d) one person as the final assembler - putting it all together, testing and doing things like menus You can then assign the roles according to availability (i.e. the documenter needs to get his act together earlier, but will be finished earlier too) person b) may need help, depending on what framework / language you are using. person c) may need help, depending on the game complexity person d) may need help, depending on how well a) b) and c) did!!!! The idea is that a) drafts the documented game design. b) can provide some quick sound and video routines - enough to display something and make a noise and c) and work on the logic, based on a) and b) initial work a) and b) can continue to improve their parts - depending on feedback from the others (e.g. the initial design is far too complex, change the docco!) Person d) can write the framework of the menu, help or whatever, ready to slot in the game logic sound and graphics of course, you should try to work together rather than in isolation - but I reckon splitting it like that will give good mileage for a uni project The critical point in all this is person c) so (s)he should maybe be the driver of the project - i.e. if they need help, the others come a-runnin'
MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
Thanks for a nice logical separation of responsibilities :-D