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! |
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 |
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. |
Jared Burns (4.5k●2●9)
| answered Feb 25 '09, 10:23 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
On Wed, 18 Feb 2009 00:27:54 +0000, jcagle wrote:
Ryan Manwillerwrote: 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 |
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.