It's all about the answers!

Ask a question

Team areas vs. project areas


Patrick LoPresti (8859) | asked Feb 10 '12, 12:27 p.m.
I am a developer at a company planning a RTC roll-out. I have spent some time reading the documentation on my own, and I have a question about "team areas" and "project areas".

First, here is what I understand so far; please correct me if I am wrong. Team areas and project areas form a collection of hierarchies (trees). Every team area has a parent that is either another team area or a project area. Project areas have no parent. That is, each hierarchy has a project area at its root, and each project area forms the root of a hierarchy of team areas.

My question is this: In an operational sense, what can I do with a project area that I cannot do with a team area, and vice-versa? Put another way: Purely in terms of functionality, why would I want to create two project areas instead of two team areas, or vice-versa?

Do project areas provide some sort of isolation (e.g. access control) that team areas do not? Can project areas contain some sort of object (e.g. schedules) that team areas cannot? Are any objects more easily shared between sibling team areas than between project areas?

It is possible that my questions are not even well-formed because I am misusing the terms. If so, please help me to correct that, too.

Thanks!

Accepted answer


permanent link
Millard Ellingsworth (2.5k12431) | answered Feb 10 '12, 9:27 p.m.
FORUM ADMINISTRATOR / JAZZ DEVELOPER
I am a developer at a company planning a RTC roll-out. I have spent some time reading the documentation on my own, and I have a question about "team areas" and "project areas".

First, here is what I understand so far; please correct me if I am wrong. Team areas and project areas form a collection of hierarchies (trees). Every team area has a parent that is either another team area or a project area. Project areas have no parent. That is, each hierarchy has a project area at its root, and each project area forms the root of a hierarchy of team areas.

My question is this: In an operational sense, what can I do with a project area that I cannot do with a team area, and vice-versa? Put another way: Purely in terms of functionality, why would I want to create two project areas instead of two team areas, or vice-versa?

Do project areas provide some sort of isolation (e.g. access control) that team areas do not? Can project areas contain some sort of object (e.g. schedules) that team areas cannot? Are any objects more easily shared between sibling team areas than between project areas?

It is possible that my questions are not even well-formed because I am misusing the terms. If so, please help me to correct that, too.

Thanks!


Your basic understanding is spot on, no need to correct. And thank you for choosing RTC.

Only Project Areas can have Timelines. A top-level Team Area can be assigned to a time line (all subteams of it are automatically and only on that same time line). This makes it possible for a Project Area to essentially have multiple "projects" if you define "project" as a Team working within a Timeline to accomplish something. For example, if you have separate teams responsible for new development and sustaining work, you could have a Timeline for new development and one for maintenance. They could have different iteration configurations and even different process and operational behaviors defined. Perhaps your new dev Timeline uses short iterations and your maintenance Timeline uses longer dev-test-release milestones and all source code deliveries to the maintenance stream require a code review approval.

While sharing between Project Areas can be done, everything within a Project Area is implicitly shared -- you actually have to do things to keep sharing from happening. So one reason you might use 2 Project Areas is if you want to only share some specific artifacts as it would be easier to enable that sharing between Project Areas than to disable all other sharing within one. In the example above, because the new dev and sustaining teams will likely share lots of information (and push defects back and forth), a single Project Area is likely a better choice.

There are specific options for access control at the Project Area level that don't exist in the same way for Teams. That said, access control and permissions can be a pretty twisted topic, so if you have some specific questions, let's look at those rather than discuss it generally.
Patrick LoPresti selected this answer as the correct answer

4 other answers



permanent link
Anthony Randolph (4113) | answered Feb 13 '12, 1:16 p.m.
Just has an extra "." on the end - here is the link -
https://jazz.net/library/article/137

Thanks - huangqf

The link appears to be broken. @huangqf do you have the right link?

You might be interested in this article: https://jazz.net/library/article/137. (Maybe you have already read this article.:)) This article will give you a basic concept about Project Area, Team Area and Process.

permanent link
Saurabh Malhotra (15231617) | answered Feb 13 '12, 8:24 a.m.
The link appears to be broken. @huangqf do you have the right link?

You might be interested in this article: https://jazz.net/library/article/137. (Maybe you have already read this article.:)) This article will give you a basic concept about Project Area, Team Area and Process.

permanent link
Qiong Feng Huang (76911610) | answered Feb 12 '12, 11:42 p.m.
JAZZ DEVELOPER
You might be interested in this article: https://jazz.net/library/article/137. (Maybe you have already read this article.:)) This article will give you a basic concept about Project Area, Team Area and Process.

permanent link
Geoffrey Clemm (30.1k33035) | answered Feb 11 '12, 2:38 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
One way to understand the differences between team areas and project
areas is to open a team area and a project area in the editor, and
observe the differences.

Since a team area is functionally a subset of a project area, everything
you can do/specify in a team area, you can do/specify in a project area.
So the differences between a project area and a team area are the
additional things you can do with a project area that you cannot do with
a team area.

One thing you will see is that the project area Overview page has a
Timelines section, where you define the timelines and iterations used by
all the child team areas. (This is the difference that Millard points
out below).

In addition, a project area has additional tabs: Access Control, Work
Item Categories, and Releases. So those are all things you can only
define in a project area, and they apply to all of the team areas in the
project area.

Another thing you'll notice is that two of the tabs in the project area
are called Process Configuration and Process Configuration Source, while
those in the team area are called Process Customization and Process
Customization Source. That is because a team area "customizes" the
process that it inherits from its parent team/process area. If you look
at a Process Configuration tab and a Process Customization tab, the
Project Configuration section is information that is true for every team
area (and cannot be customized), while the Team Configuration section is
the behavior that can be customized in child team areas.

Cheers,
Geoff




On 2/10/2012 9:38 PM, millarde wrote:
patlwrote:
I am a developer at a company planning a RTC roll-out. I have spent
some time reading the documentation on my own, and I have a question
about "team areas" and "project areas".

First, here is what I understand so far; please correct me if I am
wrong. Team areas and project areas form a collection of hierarchies
(trees). Every team area has a parent that is either another team
area or a project area. Project areas have no parent. That is, each
hierarchy has a project area at its root, and each project area forms
the root of a hierarchy of team areas.

My question is this: In an operational sense, what can I do with a
project area that I cannot do with a team area, and vice-versa? Put
another way: Purely in terms of functionality, why would I want to
create two project areas instead of two team areas, or vice-versa?

Do project areas provide some sort of isolation (e.g. access
control) that team areas do not? Can project areas contain some sort
of object (e.g. schedules) that team areas cannot? Are any objects
more easily shared between sibling team areas than between project
areas?

It is possible that my questions are not even well-formed because I
am misusing the terms. If so, please help me to correct that, too.

Thanks!

Your basic understanding is spot on, no need to correct. And thank you
for choosing RTC.

Only Project Areas can have Timelines. A top-level Team Area can be
assigned to a time line (all subteams of it are automatically and
only on that same time line). This makes it possible for a Project
Area to essentially have multiple "projects" if you define
"project" as a Team working within a Timeline to accomplish
something. For example, if you have separate teams responsible for new
development and sustaining work, you could have a Timeline for new
development and one for maintenance. They could have different
iteration configurations and even different process and operational
behaviors defined. Perhaps your new dev Timeline uses short
iterations and your maintenance Timeline uses longer dev-test-release
milestones and all source code deliveries to the maintenance stream
require a code review approval.

While sharing between Project Areas can be done, everything within a
Project Area is implicitly shared -- you actually have to do things
to keep sharing from happening. So one reason you might use 2 Project
Areas is if you want to only share some specific artifacts as it would
be easier to enable that sharing between Project Areas than to disable
all other sharing within one. In the example above, because the new
dev and sustaining teams will likely share lots of information (and
push defects back and forth), a single Project Area is likely a
better choice.

There are specific options for access control at the Project Area
level that don't exist in the same way for Teams. That said, access
control and permissions can be a pretty twisted topic, so if you have
some specific questions, let's look at those rather than discuss it
generally.

Your answer


Register or to post your answer.