Team Area Development Line
I'm trying to understand why a team area must specify a Development Line.
This doesn't make a lot of sense to us as the same team works on maintenance lines as well as developments concurrently. We don't just drop everything we're doing for the next release to work on a maintenance release.
Could someone enlighten me as to why we have to specify just one development line?
This doesn't make a lot of sense to us as the same team works on maintenance lines as well as developments concurrently. We don't just drop everything we're doing for the next release to work on a maintenance release.
Could someone enlighten me as to why we have to specify just one development line?
2 answers
Team areas are currently associated with a single development line. All
artifacts owned by or associated with the team area are therefore bound
to a single development line making the process rules that apply to
these artifacts unambiguous.
The same could have been achieved by not just associating artifacts with
a team area but by making the association specific for a development line.
The current approach has the disadvantage of the overhead of additional
team areas for additional development lines. It has the advantage of
making explicit which teams and who of the team members contribute to
the efforts in a development line.
Kai
Jazz Process Component
gcastro wrote:
artifacts owned by or associated with the team area are therefore bound
to a single development line making the process rules that apply to
these artifacts unambiguous.
The same could have been achieved by not just associating artifacts with
a team area but by making the association specific for a development line.
The current approach has the disadvantage of the overhead of additional
team areas for additional development lines. It has the advantage of
making explicit which teams and who of the team members contribute to
the efforts in a development line.
Kai
Jazz Process Component
gcastro wrote:
I'm trying to understand why a team area must specify a Development
Line.
This doesn't make a lot of sense to us as the same team works on
maintenance lines as well as developments concurrently. We don't
just drop everything we're doing for the next release to work on a
maintenance release.
Could someone enlighten me as to why we have to specify just one
development line?
Ouch, that wouldn't scale at all for us. I believe the VM would end up with 8-10 concurrent development lines so replicating our team structure 10 times would turn Jazz into a nightmare.
Since the teams are the same for all dev lines this would just make it harder to use and rather confusing.
Since the teams are the same for all dev lines this would just make it harder to use and rather confusing.
Team areas are currently associated with a single development line. All
artifacts owned by or associated with the team area are therefore bound
to a single development line making the process rules that apply to
these artifacts unambiguous.
The same could have been achieved by not just associating artifacts with
a team area but by making the association specific for a development line.
The current approach has the disadvantage of the overhead of additional
team areas for additional development lines. It has the advantage of
making explicit which teams and who of the team members contribute to
the efforts in a development line.
Kai
Jazz Process Component