Seperation of project responsibilities in new project
- by dreza
We have very recently started a new project (MVC 3.0) and some of our early discussion has been around how the work and development will be split amongst the team members to ensure we get the least amount of overlap of work and so help make it a bit easier for each developer to
get on and do their work. The project is expected to take about 6 months - 1 year (although not all developers are likely to be on and might filter off towards the end),
Our team is going to be small so this will help out a bit I believe. The team will essentially consist of:
3 x developers (1 a slightly more experienced and will be the lead)
1 x project manager / product owner / tester
An external company responsbile for doing our design work
General project/development decisions so far have included:
Develop in an Agile way using SCRUM techniques (We are still very much learning this approach as a company)
Use MVVM archectecture
Use Ninject and DI where possible
Attempt to use as TDD as much as possible to drive development.
Keep our controllers as skinny as possible
Keep our views as simple as possible
During our discussions two approaches have been broached as too how to seperate the workload given our objectives
outlined above.
OPTION 1:
A framework seperation where each person is responsible for conceptual areas with overlap and discussion primarily in the integration areas. The integration areas would the responsibily of both developers as required.
View prototypes (**Graphic designer**)
|
- Mockups
|
Views (Razor and view helpers etc) & Javascript (**Developer 1**)
|
- View models (Integration point)
|
Controllers and Application logic (**Developer 2**)
|
- Models (Integration point)
|
Domain model and persistence (**Developer 3**)
PROS:
Integration points are quite clear and so developers can work
without dependencies on others fairly easily
Code practices such as naming conventions and style is more easily managed in regards to consistancy
as primarily only one developer will be handling an area
CONS:
Completion of an entire feature becomes a bit grey as no single
person is responsible for an entire feature (story?)
A person might not have a full appreciation for all areas of the project and so code overlap might be lacking
if suddenly that person left.
OPTION 2:
A more task orientated approach where each person is responsible for the completion of the entire task from view - controller - model.
PROS:
A person is responsible for one entire feature so it's "complete" state can be clearly defined
Code overlap into different areas will occur so each individual has good coverage over the entire application
CONS:
Overlap of development will occur in all the modules and developers
can develop/extend without a true understanding of what the original code owner was intending. This could potentially lead more easily to code bloat?
Following a convention might be harder as developers are adding to all areas of the project
If a developer sets up a way of doing things would it be harder to enforce the other
developers to follow that convention or even build on it (or even discuss it?). Dunno..
Bugs could more easily be introduced into areas not thought about by the developer
It's easier to possibly to carry a team member in so far as one member just hacks code
together to complete a task whilst another takes time to build a foundation that could
be used by others and so help make future tasks easier i.e. starts building a framework?
QUESTION:
As it might appear I'm more in favor of option 1, however I'm interested to see how others might have approached this or what is the standard or best or preferred way of undertaking a project. Or indeed any different approach to handling this?
