One dev line per Team Area restriction, Why?
One answer
On Thu, 09 Apr 2009 09:58:09 +0000, jaguerrero wrote:
In RTC 2.0, we've renamed development line to timeline, so I'm going to
use that term.
Ultimately, we have this restriction because of the fact that your
process can be configured to behave differently at different points in
time. By putting each team area in the context of exactly one timeline,
we have a sane answer for the question "what process applies now?" If one
team area could work in multiple timelines, there would be multiple
"nows" which would be unmanageable.
For example, imagine your team was in both a "2.0 release" timeline and a
"1.0.1 maintenance" timeline. If your "2.0 release" timeline says that
anyone can freely deliver change sets and your "1.0.1 maintenance"
timeline says that change sets require approvals, what should happen when
someone tries to deliver a change to your team?
--
Jared Burns
Jazz Process Team
Hi all,
I wonder how important is this restriction (no multiple dev line per
team are are permitted) and what are the reasons for that restriction.
Thanks in advance
Cheers
Andrs
In RTC 2.0, we've renamed development line to timeline, so I'm going to
use that term.
Ultimately, we have this restriction because of the fact that your
process can be configured to behave differently at different points in
time. By putting each team area in the context of exactly one timeline,
we have a sane answer for the question "what process applies now?" If one
team area could work in multiple timelines, there would be multiple
"nows" which would be unmanageable.
For example, imagine your team was in both a "2.0 release" timeline and a
"1.0.1 maintenance" timeline. If your "2.0 release" timeline says that
anyone can freely deliver change sets and your "1.0.1 maintenance"
timeline says that change sets require approvals, what should happen when
someone tries to deliver a change to your team?
--
Jared Burns
Jazz Process Team