Question

I'm trying to figure out what the best way is to divide up projects and areas. My company maintains one very large website (millions of members and tons of features). We have major feature areas like advertising, articles, membership, etc. Should we:

1. Create a separate project for each feature area?
2. Create one project for the entire website with separate areas for membership, advertising, etc.

Answer 1

I agree with having projects mirror your source code repository setup. That's a good measure for what we mean when we say project.

One thing projects should not be is short-lived. That's better handled in a milestone or area under another persistent project. For instance, if you do client work, you probably don't want to do a new project for every client. Rather, have a client project and an area for each bit of work you do for them.

That said, we don't work on client products, so we may not be the experts here.

Answer 2

I would use a project for each feature area, but the right answer for you also depends to some extent on how you have set up the revision management system for the website - if the features are spread across several repositories or revision control systems or projects within a single repository, you already have a natural collection of projects, and it would be confusing to use a different arrangement for defect tracking.

I reserve areas to distinguish between problems related to the same project for which fixes require different release paths, e.g. Documentation (which has a slightly lower burden to republish) vs Software (which requires a release build, test, and Q/A) vs Firmware (which requires someone burn some EPROMS), or which might have different groups of employees working on them (e.g. User Interface, Database, Business Logic, Interoperability).