Working in a team question
-
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.
-
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.