Process configuration
I'd like to describe our scenario, and get suggestions from folks as to the best way to "configure" this in RTC.
We are a small team of 5 developers, working a fairly standard project process. We are in our "development" and "exploration" phase for quite some time (say 6 months), and then we enter our "acceptance testing" phase later this year. When we enter our acceptance testing phase, I'd like to "lock down" things such that we need to have approval before code changes are delivered to our main stream (I know I can do this with the "requires approval" pre-condition). I don't want to have to do this during the "exploration" phase, since that's too process-heavy, and unnecessary. What would be the best way to do this? Should I have just one timeline in RTC, and when we enter our acceptance testing phase, turn that precondition on? Or should I define two different timelines, and define two different teams (with the same members), and enable that precondition only on the "acceptance testing" timeline? If the answer is #2 above, I think I've seen on other posts where people are advocating using the same team across multiple timelines concurrently, so I'd throw my vote on that as well :) Thanks in advance, Mike Johnson |
2 answers
Ralph Schoon (63.1k●3●36●46)
| answered Jan 19 '11, 12:09 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Hi Mike,
you can tiel like the "Required approval" not only to team areas, but also to iterations (therefore you can see the time line and its iterations in the process configuration). Another anchor point would be Iteration types. So you could set it up like this: Timeline --- Project ------ Iteration1 (FreeDev) ------ Iteration2 (FreeDev) ... ------ IterationN (Endgame) Iteration Type FreeDev has its rules and Endgame is more restricted (lock down). The rules would apply as soon as you set the rules to the iteration type and make the current iteration of that type. Alternatively tie the behavior to the iteration, then you have to do it if you create a new iteration. Additional considerations: The Iterations/Phases can be further split in sub iterations which can have types also. Same mechanism as above. If you have an iteration that is used for planning but within that iteration you want to change behavior for a period of time, you can also create additional sub iterations within the iteration that do not have the "A Release is planned..." checked in their properties. These would be invisible for planning but setting one as current would case special behavior defined for them to be activated. Ralph I'd like to describe our scenario, and get suggestions from folks as to the best way to "configure" this in RTC. |
|
Ralph,
Perfect! Exactly what I was looking for. And, of course, I was perusing the help a few minutes ago, and found the following, which is exactly as you describe. Guess I should have read a little more before posting my question... :) You can create iteration types and associate an iteration with an iteration type. For each iteration type, you can configure specific permissions and operation behavior. Those permissions and behavior settings apply to all iterations of the iteration type. For example, your organization might want to tighten requirements on deliveries towards the end of a release. To do this, you might create an iteration type with a name such as End Game, and configure the behavior for that iteration type to require team members to get approvals before delivering change sets. All iterations of the End Game iteration type would enforce that behavior. Thanks, Mike |
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.