Working in a team question
-
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
-
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
More like one person should create the initial overview and structure that can be used for reference, and then step back and just be a normal team member, picking up coding tasks like everyone else. If re-thinks are needed, they can either be handled by discussion within the team, or by re-appointing one team member (not necessarily the same one) to the architectural role.
I wanna be a eunuchs developer! Pass me a bread knife!
-
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'm not sure you really should subdivide it into roles other than "let one guy make the calls in collaboration with the others". In game development this is commonly referred to as "lead programmer". Give this person responsibility to set up a time plan, discuss it with other people (designers, graphic artists, project leader ...) Once you have a timeplan you see what needs to be done, then just make sure that every programmer on the team has something to do every day and be sure to divide the tasks between you. Making sure that everyone gets something fun to do during the timespan that they can look forward to.
-
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.
No roles, here's why: Let's keep it simple and say you have to build a web application. You have one html/css guy, one hosting guy and one usercontrol programmer guy. Now, suppose either one of them dies. What will happen to the project? It will be doomed! X| Better is to divide the project into small steps and make clear agreements who will/can finish which step at what given time. Have short meetings regularly to see if there are any unforeseen problems so you can change course or shift the schedule. The big advantage of a task-oriented approach is that it's concrete, everyone has equal control/responsibility over the project; so there's less nagging. :thumbsup:
Giraffes are not real.
-
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 guess you have an idea of the game you want to create... if developing the game is the only thing thats left then you need to discuss about the roles... so...i guess in such small team you cant just have a role.. you may need to have 2 or three roles each. discuss about each ones preferences and field of knowledge each would like to explore... but there are many parameters at which you should look at... is the game 2d or 3d?? will you use an game engine or are you going to make it from scratch??? :confused: my suggestion is that you should try to look on the parameters of the game and then start giving roles... some specific roles may need even two programmers to work in a subgroup... :cool: PS. someone has to be also game or discussion manager... democracy doesn't work well in these kind of situations as far as i know... :laugh:
-
i guess you have an idea of the game you want to create... if developing the game is the only thing thats left then you need to discuss about the roles... so...i guess in such small team you cant just have a role.. you may need to have 2 or three roles each. discuss about each ones preferences and field of knowledge each would like to explore... but there are many parameters at which you should look at... is the game 2d or 3d?? will you use an game engine or are you going to make it from scratch??? :confused: my suggestion is that you should try to look on the parameters of the game and then start giving roles... some specific roles may need even two programmers to work in a subgroup... :cool: PS. someone has to be also game or discussion manager... democracy doesn't work well in these kind of situations as far as i know... :laugh:
Thanks again for the helpful feedback! :-D From all of the replies we decided that it would be best to: x - Not assign global roles x - Assign "local" roles on a per scenario/stint basis We might still have a lead programmer role somewhere in there, but over all we will tackle subdivision depending on the problem. - Thanks again :laugh:
-
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.
My guess is that you will eventually find someone performing all of the Roles on the list you reference. Role != Single Individual. On a small team each person will fill multiple Roles and multiple people will share the same Role. If you are seriously talking about a 3-4 month project, then you will need good organization to keep it all straight. Figure out how (and when) the list of Roles will map onto your team.
-
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.
Why worry about 'assigning' roles at all? In a team of 4, with a clear vision of what it is you wish to develop, this should be a no brainer. Collectively determine what needs to be done, then in what order it needs to be done. For each sprint, each member steps up and takes a piece of the pie. For non-development tasks (i.e., documentation, revision control, back-log management, etc.) determine who in the group is either A. most qualified or B. least objectionable to fulfilling each task. The most anal attentive to detail member should naturally handle revision control. The best communicator should handle documentation. The most organized should manage the back-log. If everyone on the team have similar traits and personalities, then change roles every sprint until you find what works best. Just my $.02
-
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.