For concurrent development lines, we duplicate the team areas. This way
we are very explicit about who is working on which development lines
since, for example, we generally assign only a subset of our team to
work on the maintenance line.

Jared Burns
Jazz Process Team


Pratik Shah wrote:

I am a little confused about team areas in RTC. Our product team is
divided into a hierarchy of sub-teams based on the part of the product
they own. The sub-teams have categories, new queries and certain
process customizations associated to them. What is the recommended
thing to do when we create a new development line? Do we move the
entire hierarchy to the new development line? Or do we just change the
development line associated to the team hierarchy? Is there a
difference between the two? And when ww change the development line
associated to a team, what are the repercussions? I read somewhere that
you can create new teams, but it doesn't make sense to replicate
everything we've done so far for all the teams for each development line.

And what about multiple simultaneous development lines? It looks like a
team area can only be associated to a single development line. So it
would seem that we have no choice but to duplicate team areas. Is that
what RTC does with its own development lines?

Pratik

We have a single "main" development line for sequential releases (1.0,
2.0, etc.) and then we spawn off separate development lines for the
maintenance of each release which goes on concurrent to the main
development. So for example, after 1.0 ships the main development line
would change to the 2.0 iteration and at the same time we would create a
"1.0 maintenance" development line.

Jared Burns
Jazz Process Team


Pratik Shah wrote:

Do you have a single "main" development line for all your releases, or a
separate development line for each of your major releases? I am wondering
if it would be better for us to continue using our development line from the
last release for the next release, and create a new development line just
for the maintenance stream.

"Jared Burns" <jared_burns> wrote in message
news:gk5l2j$3je$1@localhost.localdomain...
For concurrent development lines, we duplicate the team areas. This way we
are very explicit about who is working on which development lines since,
for example, we generally assign only a subset of our team to work on the
maintenance line.

Jared Burns
Jazz Process Team


Pratik Shah wrote:
I am a little confused about team areas in RTC. Our product team is
divided into a hierarchy of sub-teams based on the part of the product
they own. The sub-teams have categories, new queries and certain process
customizations associated to them. What is the recommended thing to do
when we create a new development line? Do we move the entire hierarchy
to the new development line? Or do we just change the development line
associated to the team hierarchy? Is there a difference between the two?
And when ww change the development line associated to a team, what are
the repercussions? I read somewhere that you can create new teams, but
it doesn't make sense to replicate everything we've done so far for all
the teams for each development line.
And what about multiple simultaneous development lines? It looks like a
team area can only be associated to a single development line. So it
would seem that we have no choice but to duplicate team areas. Is that
what RTC does with its own development lines?
Pratik

As far as the Process runtime is concerned, moving the team area from
one dev line to another only matters if you have custom process
configured for a particular development line/iteration. If you have
iteration-specific process configured, moving a team from one dev line
to another just means that the team's "active process" will change to
whatever process is configured for the current iteration of the new dev
line.

Moving the team has similar repurcussions. If your team area is
inheriting any process configuration from its parent, this configuration
will not affect your team any longer after the move. Also (and this is
probably the only thing you need to look for), if your parent team are
*declares* any roles, these role assignments will no longer have any
meaning after you move your team unless you fix up your team to declare
roles with the same ID.

As for "work done earlier", I believe workitems will continue to work
fine (I just tested and things behaved well). Just make sure you set up
your work item category to be associated with your team in the new
development line.

Jared Burns
Jazz Process Team


Pratik Shah wrote:

Thanks, Jared. We've already created a separate development line for our
next release. So, what's the best way to consolidate it now? I am guessing
it's easier to just associate the current team structure to the new
development line (rather than removing the new development line, and somehow
moving the milestones defined in there to the original dev line). Do you
know what would be the repercussions of changing the development line of a
team? Also, what about moving the team (we'd have to do it since we are
part of a larger team that we don't have control over)? How does that
affect the work done earlier?

Pratik

"Jared Burns" <jared_burns> wrote in message
news:gk5u53$7es$1@localhost.localdomain...
We have a single "main" development line for sequential releases (1.0,
2.0, etc.) and then we spawn off separate development lines for the
maintenance of each release which goes on concurrent to the main
development. So for example, after 1.0 ships the main development line
would change to the 2.0 iteration and at the same time we would create a
"1.0 maintenance" development line.

Jared Burns
Jazz Process Team


Pratik Shah wrote:
Do you have a single "main" development line for all your releases, or a
separate development line for each of your major releases? I am
wondering if it would be better for us to continue using our development
line from the last release for the next release, and create a new
development line just for the maintenance stream.

"Jared Burns" <jared_burns> wrote in message
news:gk5l2j$3je$1@localhost.localdomain...
For concurrent development lines, we duplicate the team areas. This way
we are very explicit about who is working on which development lines
since, for example, we generally assign only a subset of our team to
work on the maintenance line.

Jared Burns
Jazz Process Team


Pratik Shah wrote:
I am a little confused about team areas in RTC. Our product team is
divided into a hierarchy of sub-teams based on the part of the product
they own. The sub-teams have categories, new queries and certain
process customizations associated to them. What is the recommended
thing to do when we create a new development line? Do we move the
entire hierarchy to the new development line? Or do we just change the
development line associated to the team hierarchy? Is there a
difference between the two? And when ww change the development line
associated to a team, what are the repercussions? I read somewhere
that you can create new teams, but it doesn't make sense to replicate
everything we've done so far for all the teams for each development
line.
And what about multiple simultaneous development lines? It looks like
a team area can only be associated to a single development line. So it
would seem that we have no choice but to duplicate team areas. Is that
what RTC does with its own development lines?
Pratik