Process spec not applied to the right current iteration
I am a little confused as to how the process specifications are enforced. We have the following situation:
- We have two streams representing two different releases of our product.
- Both streams are owned by the same team area.
- We have two separate development lines, one for the current release and one for fix packs of a previous release. Two iterations, one under each, are marked as current iterations.
- For the iteration representing fix pack work, we would like to specify a precondition for work item approval before any changes can be delivered.
- We added the precondition in the process specification for that iteration and the development line, but neither is working, as it seems to use the other current iteration.
- Note that we are associating changesets with work items that are planned for the fix pack iteration. We would have expected the Planned For field to be used when determining the process spec to apply. This doesn't seem to be happening.
How can we resolve this problem? I expect that this is a likely scenario that will affect other teams developing for multiple releases. Thanks!
- We have two streams representing two different releases of our product.
- Both streams are owned by the same team area.
- We have two separate development lines, one for the current release and one for fix packs of a previous release. Two iterations, one under each, are marked as current iterations.
- For the iteration representing fix pack work, we would like to specify a precondition for work item approval before any changes can be delivered.
- We added the precondition in the process specification for that iteration and the development line, but neither is working, as it seems to use the other current iteration.
- Note that we are associating changesets with work items that are planned for the fix pack iteration. We would have expected the Planned For field to be used when determining the process spec to apply. This doesn't seem to be happening.
How can we resolve this problem? I expect that this is a likely scenario that will affect other teams developing for multiple releases. Thanks!
3 answers
I think the problem may be here: "Both streams are owned by the same team
area"
The process runtime is eventually going from the team to the development
line. Since the same team is used in both cases, its the same development
line, thus the same current iteration.
You need to have a team for each development line. For example a "2.0 team"
and a "1.0 maintenance team". These are associated with the appropriate
development line. And the streams are associated with the appropriate team.
This may seem awkward at first, but you may realize it makes sense because
these are two functionally different teams with potentially different
members (but not necessarily different).
---
Ryan Manwiller
Jazz Team
area"
The process runtime is eventually going from the team to the development
line. Since the same team is used in both cases, its the same development
line, thus the same current iteration.
You need to have a team for each development line. For example a "2.0 team"
and a "1.0 maintenance team". These are associated with the appropriate
development line. And the streams are associated with the appropriate team.
This may seem awkward at first, but you may realize it makes sense because
these are two functionally different teams with potentially different
members (but not necessarily different).
---
Ryan Manwiller
Jazz Team
I think the problem may be here: "Both streams are owned by the same team area
Is there any alternative to defining separate teams for each development line? Our project will have 15-20 teams, and 3 development lines active at once. Each team member is responsible for the same components in each dev line, so duplicating all these teams 3 times seems like a lot of unnecessary complexity.
Is this behavior any different in 2.0?
Also, when opening a work item the default team is chosen unless the Planned For field is set. Has there been any thought to merging the Releases list used for the Found In field with the releases defined in the Process Iterations? That is, eliminate the Releases list and populate Found In choices from the Process Iterations. That would allow the correct team to be assigned if the user provided a value for the Found In field (which they typically do) without having to provide a choice for the Planned For field (which they typically don't).
Thanks.
On Wed, 18 Feb 2009 00:27:54 +0000, jcagle wrote:
Ryan is right about the cause of this problem.
To answer your question, there is no alternative to recreating the team
structure for your secondary development lines. Each development line has
its own hierarchy of teams and role assignments, since organizations
won't necessarily have the same people working on each dev line.
We are currently having very active discussions about the future of
development lines, team areas, and project areas. While we don't expect
to make radical changes for 2.0, we do expect to deliver progress toward
a more easily digestible model.
I can't really answer your question about releases, but I think the
support has evolved toward today's decoupled approach based on our
experience with a more tightly coupled approach in the past...
--
Jared Burns
Jazz Process Team
Ryan Manwillerwrote:
I think the problem may be here: "Both streams are owned by the same
team area
Is there any alternative to defining separate teams for each development
line? Our project will have 15-20 teams, and 3 development lines active
at once. Each team member is responsible for the same components in
each dev line, so duplicating all these teams 3 times seems like a lot
of unnecessary complexity.
Is this behavior any different in 2.0?
Also, when opening a work item the default team is chosen unless the
Planned For field is set. Has there been any thought to merging the
Releases list used for the Found In field with the releases defined in
the Process Iterations? That is, eliminate the Releases list and
populate Found In choices from the Process Iterations. That would allow
the correct team to be assigned if the user provided a value for the
Found In field (which they typically do) without having to provide a
choice for the Planned For field (which they typically don't).
Thanks.
Ryan is right about the cause of this problem.
To answer your question, there is no alternative to recreating the team
structure for your secondary development lines. Each development line has
its own hierarchy of teams and role assignments, since organizations
won't necessarily have the same people working on each dev line.
We are currently having very active discussions about the future of
development lines, team areas, and project areas. While we don't expect
to make radical changes for 2.0, we do expect to deliver progress toward
a more easily digestible model.
I can't really answer your question about releases, but I think the
support has evolved toward today's decoupled approach based on our
experience with a more tightly coupled approach in the past...
--
Jared Burns
Jazz Process Team