Partager via

What is the Definition of an Area in TFS?

  • Article

What is the definition of an Area in Team Foundation Server (TFS)? How should I use it? What is the suggested structure?

These were all questions which I asked myself when I started learning about TFS, but I never found a good definition of an area. So to help those who is learning TFS I'll provide an explanation of how I view an Area, please note that this is my interpretation on this topic and should not be seen as a formal definition from Microsoft.

My Definition of an Area

To me an Area in TFS represents a project competence, i.e. something along which you can sub-divide tasks, bugs, etc. When I think about it, an area as something that I can use as a required competence when I request resources for the project.

Example of Areas

En example of an area structure is the list below which split development activities into four major parts which all require different competencies.

  • Database
  • UI
  • Components
  • Business processes
  • Project management
  • Testcases

These could easily have been refined into:

  • Database
  •    Table structure
  •    Stored procedures
  • UI
  •    InfoPath
  •    MOSS
  •    ASPX
  •    SQL Reporting Services
  • Components
  •    WCF
  •    Business layer
  • Business processes
  •    WF
  •    BizTalk
  • Project management
  •    Internal
  •    External
  • Testcases

So why did I not make it more granular? Well, I thought that further refinement will require more work when entering information and I did not find it interesting to report on such a granular level.

 

I larger projects, where each of these activities represent 1000s of hours it may be more applicable to create a granular area structure. But in those projects you may also have full-time admins who can take responsibility for checking proper usage of areas.

Why should you care about Areas?

Areas are used in most Work Items, the only exception I found was the Review in CMMI, so it is an important concept. However, it is always optional so could ignore it.

You can drill down into details about Areas in most standard reports, i.e. using Areas can give you a more granular view of the state of your project.

Comments

  • Anonymous
    January 20, 2007
    Once you write something down and publish it it's not unusual that you immediately realize that you were

  • Anonymous
    January 22, 2007
    Once you write something down and publish it it's not unusual that you immediately realize that you were

  • Anonymous
    April 29, 2014
    Keeping the spirit of "Agile" practices, I use Areas for defining Bounded Contexts as it relates to "Ubiquitous" language (business terms) as it relates to the business; i.e. Reports, Accounting, Shipping, User Demographic, etc.  By doing this, you align the dev team with the stakeholders and their language; therefore, furthering the Domain Driven Design (DDD) methodology.   I'll avoid putting tech terms in areas at all cost because it boxes the task into the actual implementation; but to some folks, that may not be a bad thing -- as this article suggests. :-)    Also, when the business folks (Domain Experts) create tasks, they can easily drop the task in the bounded context (Area) -- without training them about "bounded contexts". :-)