[mc_hammer]

personally i like to write the mvc skeleton myself and decide which frameworks will be used and go from there. or a leader for the backend who assigns out small tasks as small as a "function to draw this btn or move this element" or to "find me a library that does X and is..." and then he can merge them in... then once it takes shape you can share the files and the work.

i suppose usually for me one guy (say techsupp or network admin) sets up the svn/webserver/db, one guy decides on frameworks, one guy writes the skeleton, one guy starts on the interface, art guy does art stuff, typically the lead dev is watching over all this and merging stuff and when ready gives orders and access to the repo. if theres at least some structure and one template or working file/interface the juniors will have more success imo.

[bitwalker]

I think the lead should be setting up source control, the dev/staging environment, deciding on the frameworks used (for the big stuff at least), and defining the architecture and code style for the project, and last but not least, they should break up the project into major features, and individual modules/components/tasks. As far as the last bit goes, the level of detail I shoot for is something like this (given a fabricated web app as the software being developed):

Feature: User can register an account

Tasks:

  - Registration page markup/styles

  - Registration page JavaScript (form validation/submission)

  - Registration API endpoint (validate properties, ensure user doesn't already exist, persist user model, send email confirmation).

Prerequisites:

  - Data access layer implementation

  - User model

  - App layout markup/styles

  - Email service implementation

I agree with the lead setting up the initial project skeleton, but I'd take it one step farther and say the lead should also document the conventions for adding new modules/etc, so that the structure doesn't start to fall apart once the lead stops being the one managing it day to day.