The "active process" for artifacts that your team members are working
with (streams, work items, etc.) will always be driven by the current
iteration. If you aren't configuring your process differently for each
iteration, this won't matter for you.

Jared Burns
Jazz Process Team


ghu wrote:

We use Eclipse Way process and have a project area containg many team
areas which work together to ship a single product.

Therefore at any time, we can only have one iteration set as current
on a given dev. line, and which can only be done at project area,
this is causing confusion and confilction among team areas. Some
teams want to move to next or previous iteration, while others wnat
to stay at the current one. They can't change it and others don't
want it to be changed.

The first mistry is that what is this current iteration about. What
are the conseguences if some teams work on iterations other than the
conrrent one, while others work on it? What kind of trouble we are
going to have? I don't see issues to creat work items against any of
them, current ot not.

Alternatively, we'll have to create different dev. lines to each team
which want to work on a different iteration, which sounds messy to
me?

What are the other options? Please help.

I would decide based on the delivery schedule. If you have concurrent
work being delivered on different schedules, then it makes sense to have
different development lines.

For example, RTC 2.0 development and RTC 1.0.1.1 maintenance are on
different concurrent release schedules so we have separate development
lines for them.

But if your teams are delivering serial releases at the same time, then
it probably makes sense to use a single development line. It really just
depends on whether or not your teams are working in lock step.

For example, after RTC 1.0 was released, our teams worked on RTC 1.0.1
before we started on RTC 2.0. So we represented these releases as
iterations in a single development line.

Hope that helps,
Jared Burns
Jazz Process Team


ghu wrote:

Thanks, Jared,
That is helpful.
Would you mind to share your view on comparing using multi-iterations
under same dev. line for different teams with using multi-dev. lines
for different teams so each can have their own current iteration?

Jazz dev. teams are now into handling both new dev. and maintaining
old releases con-currently. Would you mind give real examples to show
how you guys handle it: multi-iterations or multi dev. lines?

jburnswrote:
The "active process" for artifacts that your team members
are working
with (streams, work items, etc.) will always be driven by the
current
iteration. If you aren't configuring your process differently for
each
iteration, this won't matter for you.

Jared Burns
Jazz Process Team


ghu wrote:
We use Eclipse Way process and have a project area containg many
team
areas which work together to ship a single product.

Therefore at any time, we can only have one iteration set as
current
on a given dev. line, and which can only be done at project area,
this is causing confusion and confilction among team areas. Some
teams want to move to next or previous iteration, while others wnat
to stay at the current one. They can't change it and others don't
want it to be changed.

The first mistry is that what is this current iteration about. What
are the conseguences if some teams work on iterations other than
the
conrrent one, while others work on it? What kind of trouble we are
going to have? I don't see issues to creat work items against any
of
them, current ot not.

Alternatively, we'll have to create different dev. lines to each
team
which want to work on a different iteration, which sounds messy to
me?

What are the other options? Please help.

Jared,

We are working on a current release and fix pack for a previous release concurrently. As such, we have two different dev. lines ("Main Development" and "Fix Pack Development") with current iterations marked under each. We have team areas that inherit "Main Development" as the development line. The problem we are running into is that we want an additional deliver precondition for the iteration in Fix Pack Development line, and though we have specified it in the project area specification, it is not taking effect.

I tried to customize the team area's process specification for that iteration, but it is not showing up there (likely because the team area's inherited development line is "Main Development").

What do you recommend we do here? Do we need different team areas for the two different development lines? Note that the members and their roles in the team areas remain consistent irrespective of the release, so we wanted to use the same team areas across releases (i.e. from a team organization standpoint, it is the same breakdown irrespective of release). Is this possible?

I would greatly appreciate any help. Thanks!

I would decide based on the delivery schedule. If you have concurrent
work being delivered on different schedules, then it makes sense to have
different development lines.

For example, RTC 2.0 development and RTC 1.0.1.1 maintenance are on
different concurrent release schedules so we have separate development
lines for them.

But if your teams are delivering serial releases at the same time, then
it probably makes sense to use a single development line. It really just
depends on whether or not your teams are working in lock step.

For example, after RTC 1.0 was released, our teams worked on RTC 1.0.1
before we started on RTC 2.0. So we represented these releases as
iterations in a single development line.

Hope that helps,
Jared Burns
Jazz Process Team


ghu wrote:

Thanks, Jared,
That is helpful.
Would you mind to share your view on comparing using multi-iterations
under same dev. line for different teams with using multi-dev. lines
for different teams so each can have their own current iteration?

Jazz dev. teams are now into handling both new dev. and maintaining
old releases con-currently. Would you mind give real examples to show
how you guys handle it: multi-iterations or multi dev. lines?

jburnswrote:
The "active process" for artifacts that your team members
are working
with (streams, work items, etc.) will always be driven by the
current
iteration. If you aren't configuring your process differently for
each
iteration, this won't matter for you.

Jared Burns
Jazz Process Team


ghu wrote:
We use Eclipse Way process and have a project area containg many
team
areas which work together to ship a single product.

Therefore at any time, we can only have one iteration set as
current
on a given dev. line, and which can only be done at project area,
this is causing confusion and confilction among team areas. Some
teams want to move to next or previous iteration, while others wnat
to stay at the current one. They can't change it and others don't
want it to be changed.

The first mistry is that what is this current iteration about. What
are the conseguences if some teams work on iterations other than
the
conrrent one, while others work on it? What kind of trouble we are
going to have? I don't see issues to creat work items against any
of
them, current ot not.

Alternatively, we'll have to create different dev. lines to each
team
which want to work on a different iteration, which sounds messy to
me?

What are the other options? Please help.