Having recently migrated to TFS 2010 I was wondering what the best or most widely accepted definition or configuration is for an Area?
The only useful article I can find online is this one and is what I would have assumed to be correct. However it got me thinking if any of the following is indeed more widely accepted.
It really depends on the product/project you 're building, I suppose it was made available as a general-purpose placeholder which can get its meaning from the context of the team & the team mission.
I can imagine projects, where ignoring it on the grand total, would also be a perfectly acceptable solution.
Our initial TeamProject structure in fact did ignore Areas for our flagship product we construct in a Team Collection. This resulted in a reporting nightmare, since we needed it on a platform-level (TeamCollection), rather than a distinct part of it (Team Project). When we realized the problem, we went searching & found this article, which made us change course: we are now using TFS Areas within one single Team Project & found what fitted best to our situation.
In our universe Area = a distinct release line within the platform.
Areas in my opinion is a grouping mechanism, with Areas you can group your wortitems in any kind you want.
I think everything which fits to your development process and or make you more productive is ok.
All of your items on the list are valid types of areas, I saw all of them in projects.
But too deep hierarchies are not really helpfull, because if you create a workitem you than you have to choose/select the right area.
