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:

1. Integration points are quite clear and so developers can work without dependencies on others fairly easily
2. 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:

1. Completion of an entire feature becomes a bit grey as no single person is responsible for an entire feature (story?)
2. 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:

1. A person is responsible for one entire feature so it's "complete" state can be clearly defined
2. Code overlap into different areas will occur so each individual has good coverage over the entire application

CONS:

1. 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?
2. Following a convention might be harder as developers are adding to all areas of the project
3. 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..
4. Bugs could more easily be introduced into areas not thought about by the developer
5. 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?