Organizing Projects

Organizing Projects

• Radexx

  As a general rule we recommend having Team Projects be pretty coarse grained things.  Our Team Project, for example has many solutions and dozens of projects.  A Team Project is generally an entire application.
  
  There are cases where you have some shared components that are used by more than one application.  When this happens, I think we generally recommend that you create a separate team project for your globally shared code.  You version control workspaces can contain source from more than one team project.  The Build feature has a bit harder time with this configuration and perhaps someone from that feature team could talk to that.
  
  Brian
  

• greenie

  Another way to think of a team project is as an administration boundary.  A project contains many workitem types.  A project contains a bug, scenario, task etc... workitem types and those types include workflow.
  
  A whole product generally undergoes that same iterations, workflow and progress so they should share the same types, iterations (milestones) etc ...
  
  You wouldn't nexessarily want different pieces of the application to have different milestones and workflow.
  
  You should push for project to be very course so an admin can define a workflow that defines the process for the scope that is needed.
  
  As an internal analagy, if you were sitting in the triage for office, you wouldn't want the word and excel portions to have different bug definitions and workflow.  As a senior office member I would want to query across the org and make the same decisions across all workitems and bars for those workitems.
  
  As an administrator for the office workitem system, I would not want to make the same workitem type changes across many projects.
  

• nicope

  Are there any guidelines for those situations where large numbers of projects are unavoidable   For instance, in our contacting environment we perform a large number of projects for a variety of customers.  We'd love to have some other structure besides naming convention, but this doesn't seem to be possible.

  
  

• wendy_yfl

  I'm also very interested in some guidance on how to organize Team Projects. We are gradually moving to a more and more SOA-based approach where we have lots of rather fine-grained solutions, each of which contains something like 2-4 projects (DAC/BLL/WebService layers etc). All services use a common framework (for the most part using EnterpriseLibrary but with some custom extension) and there are also some dependencies between services. On top of this, we have a couple of web sites (internal and external) and some smart clients that consumes the above-mentioned services.
  
  What would be a good way of organizing this I guess we want a separate project for the common framework. Should we then have one project per service Or should we try to group "related" services into larger projects Or should we try to mimic our organization (i.e. try to map projects in MS Project to projects in TFS) which, for example, would mean creating a new project for every major release.
  
  I just added a blog entry about the question on how to organize team projects.
  
  

• si-borg

  I appologize for not doing this blog post yet.  I haven't forgotten.  I just got swamped with the holiday.  I'm gradually recovering so I hope to get to it soon.
  
  Brian
  

• DrJazz

  Well, the specific project instances can't be combined, they're for different clients and are distinct projects from all perspectives internally.  However, we are mandating that all projects use the same core process that we've been customizing to our business.  There's enough "looseness" in there that (for instance) people not needing requirement->code traceability don't have to use it, but it's there for those specific clients who require it for whatever reason.
  
  My desire, however, is to provide an easy method of grouping this projects by some criteria, for instance by client and state (active, inactive)... so we can easily find the eight active projects for Client X among the fifty active projects and 100's of older projects...
  

• Alan Faux

  We will be providing guidance on this topic an Planning Guide for RTM.  I'll forward this on to someone from the version control team who can give you more guidance on how best to split the source across team projects.
  
  

• _Donnie-Darko_

  Well, we've tested into 100s and even approaching 1000 projects.
  
  From the Workitem Tracking point of view:
  1.  Workitem types cannot span projects so if you want similar workflow and process between multiple projects, making a change to the bug type in one will need a similar change in the other.  This could be an administration headache.
  2.  If you have many project with many different workitem types - try to work together and re-use fields.  Communicate.  Don't have one project create a 'priority' field and have another project create an 'urgency' field.  The workitem becomes a union of all fields so in the query builder for example, you can query across all workitem types in all projects (enables the my workitems scenario no matter how many projects there are).  It also makes the perf better.  Lastly, the whole server can only have just over a 1000 fields.  Well before that limit, you don't want a thousand fields in the querybuilder drop downs.
  
  Personally, from a workitem tracking perspective I would push for less projects - the main consideration is the workflow and administration rules.  Would these many projects have similar process, bug forms workflow etc...  
  
  Hope that helps.
  

  
  
• Organizing Projects