Using RTC without teams?

Simo Suurla

(68●15●24) Jun 19 '13, 3:39 a.m.

We have small projects only about 20 members per each and we don't need separate project members into teams. Is there any reason why we should use at least one team with all same members as is in project? Or can we just use only project without creating teams at all if we don't need more than one team?

Is there like some reporting or source control aspect what we are missing if we don't use teams in one team projects. I know that in RRC and RQM there is no required to using teams.

0 votes

2 answers

7,348 views

0 votes

2 answers

Permanent link

Ralph Schoon

FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER (64.6k●3●36●49) Jun 19 '13, 3:56 a.m.

Hi Simo,

some of the reports require at least one team area. You can work without having a team area, but these reports would miss required parameters. Some of the burnup and burndown reports are examples I have come across.

You can use a project area for each of your projects. You can do it without a team area, but I would suggest to create a central team area for your team members in this case.

Another approach (if you can live with the same process for all teams) would be to have only one project area. You can create a team area for each of your small projects. This would reduce administrative overhead compared to create project areas for each project.

These two are the pattern that I have used.

0 votes

Comments

Ralph Schoon

FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Jun 19 '13, 3:58 a.m.

I should have mentioned that it is good to have separate team areas for the projects if you use just one project area, because this would allow you to also separate concerns in planning per project. If you don't all the work items of all projects would be presented on one plan, even if you have separate categories for each project.

frederick carter

Jun 19 '13, 11:18 a.m.

stuffing projects into one project area and managing the project by using team areas does improve upon the administration and even reporting for the projects. But at some point , isn't there a limit to how many team areas (projects) you can stuff into one project area before performance degradation hits? and when it does hit what are the options available for improving upon that poor or unacceptable performance ? I know of one organization that brought me in to consult on their CLM practices , ad this is teh route they took. one project area is servicing over 200 projects using team areas for each one. The performance is terrible and as a result not many new users or new pm's are using the implementation. I notice also it is well ver 30k in # workitems already. how would you address the problems of this type of deployment ? any literature or postings or content that deal with these issues and how to address them ?

Ralph Schoon

FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Jun 20 '13, 2:47 a.m.

There is no one-size-fits-all approach and there probably never will be. I am not aware of limits for the number of team areas you can have, but obviously at some point you will have issues with usability. For example, general search for work items on work items page, too many categories etc. I don't think the performance should suffer, as all work items are stored in the same DB anyway. So 30K work items are 30K work items even if they are distributed across project areas. I don't know the DB layer so I don't know if I am missing something here. With respect to performance I would suggest JazzMon and monitor the system to understand where the limitations are. It is easy enough to split the teams across several project areas using process sharing. So it would make sense to have more than one project area and distribute the teams across those instead of keeping all in one.

Permanent link

Shubjit Naik

(1.5k●1●6●13) Jun 19 '13, 3:59 a.m.

Extract from help on this topic which answers your question

"Team areas are optional. A simple project with a small number of users might not need separate team areas. Instead, all work is done in the context of the project area."

Here is the Link

0 votes

Comments

Geoffrey Clemm

FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Jun 19 '13, 10:32 a.m.

The key phrase here is "simple project". In particular, if you don't need any of the features described in Ralph's answer, then you don't have to create a team area. So one approach is to just use the project area as your team area initially, and then when you encounter the need to have a team area, create one and move the team members from the project area down to the team area.

frederick carter

Jun 19 '13, 11:19 a.m.

Geoffrey, please see my comment above ? any ideas?

Geoffrey Clemm

FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Jun 19 '13, 1:51 p.m.

You will probably want to start a separate question on your performance/scalability issues, since it is unlikely to be caused by using team areas vs. project areas. In particular, you'll want to identify specifically which operations are performing poorly. A performance problem that might be associated with using team areas instead of project areas is that some lists in the GUI can be against every object in the project area (independent of team area boundaries) such as streams and build engines. But there usually are filters you can apply (such as "only show me objects of that kind in team areas I belong to").

1 vote

Your answer

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers

Answers and Comments

Question details

rational-team-concert

× 43,075

usage

× 12,144

teams

× 8

Question asked: Jun 19 '13, 3:39 a.m.

Question was seen: 7,348 times

Last updated: Jun 20 '13, 2:47 a.m.

Using RTC without teams?

2 answers

7,348 views

0 votes

2 answers

Comments

Comments

Your answer

Follow this question

Question details

Related questions