It's all about the answers!

Ask a question

Hi, rschoon


Ming Xia (211710) | asked May 20 '09, 8:56 p.m.
Hi, rschoon,
For what you said that "Rationale behing this is you could have finer grained iteration structures underneath an iteration that are used for process behavior specification rather than for planning. "

I tried to input "Planned for " with different iterations, say M1 for work item A and M2 for work item B. And I changed the permission of M1 and M2, say in M1, people can modify the owner of work item and M2 can not allow the modification.

However, no matter which iterations a work item planned for, it just follows the current iteration process. If the current iteration is M1, all work items can change the owner. If the current iteration is M2, all work items cannot even those planned for M1.

Would you please advise further?

One answer



permanent link
Ralph Schoon (63.3k33646) | answered May 25 '09, 12:50 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Hello cheval,

You can do something like

R1(rel)
M1(rel)
develop (current iteration)
endgame
M2(rel)
......

you can plan work items for R1, M1, M2. You can't for develop, endgame since
no release is sheduled. However develop can be set as the current (ly in
process) iteration.

In the Project Area you can customize the process for an iteration (see the
reflectd iteration structure at the lower end of the tree) like M1, M2 or
developi. Rules applied to an iteration are only active while that iteration
is active. A team that works on a development line (or timeline) gets the
rules from the project area, team areas the team is nested within and the
current iteration rules in the current iteration of the timeline the team
is working for.

For example: in the endgame iteration a operational behavior rule culd specify
that all roles need a workitem associated to change sets in order to deliver.
In addition it would be possible to specify that a role e.g. "newbie" would
in addition require a review of the changes prior to delivering.

The filed against does not change the behavior of the work item. The current
iteration however can change the behavior of the process.

I believe some of these topics are covered in the material in https://jazz.net/learn/,
especially the tutorial, the workshop https://jazz.net/learn/LearnItem.jsp?href=content/docs/workshop/index.html
, http://jazz.net/blog/index.php/2009/05/19/watch-and-learn-initial-steps-in-rational-team-concert/
and also http://jazz.net/learn/LearnItem.jsp?href=content/docs/rtc1.0-capabilities/index.html
..

However I can see that one can get lost in all this material - happened to
me too 8-)

Hope that helps,

Ralph

Hi, rschoon,
For what you said that "Rationale behing this is you could have
finer grained iteration structures underneath an iteration that are
used for process behavior specification rather than for planning.
"
I tried to input "Planned for " with different iterations,
say M1 for work item A and M2 for work item B. And I changed the
permission of M1 and M2, say in M1, people can modify the owner of
work item and M2 can not allow the modification.
However, no matter which iterations a work item planned for, it just
follows the current iteration process. If the current iteration is M1,
all work items can change the owner. If the current iteration is M2,
all work items cannot even those planned for M1.

Would you please advise further?

Your answer


Register or to post 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.