Why is a development line required?

The Process model currently assumes that all projects run on some kind
of schedule. A development line defines a schedule. Project areas can
have multiple schedules going concurrently, which would be represented
by creating multiple dev lines.

Jared Burns
Jazz Process Team


theju wrote:

A newbie question:

Why is a development line required? Isn't possible just to have
streams? Each team area will have a team stream and developers will
have their repository workspaces who will deliver to the team stream.
What will a development line do here? Can someone shed some light on
this?

Thanks!

Thanks for the reply! I was refering to the Help and now things are clear. Development line is more like a sub-project (with iterations, teams attached to it) and not like a main branch which I earlier thought.

Thanks!

The Process model currently assumes that all projects run on some kind
of schedule. A development line defines a schedule. Project areas can
have multiple schedules going concurrently, which would be represented
by creating multiple dev lines.

Jared Burns
Jazz Process Team


theju wrote:

A newbie question:

Why is a development line required? Isn't possible just to have
streams? Each team area will have a team stream and developers will
have their repository workspaces who will deliver to the team stream.
What will a development line do here? Can someone shed some light on
this?

Thanks!

What confuses me about development lines is their relationship to teams. Some parts of RTC imply that teams do work on multiple lines (see e.g. the apportioning of work activity time in a user's profile across multiple lines in each of multiple teams), whereas other parts effectively prevent this (e.g. iteration plans).

In practice, we have teams who work on multiple development lines. You could argue that a team working on 2 lines is 2 teams, but splitting the team implies some additional overheads which may not be worthwhile for a few small work items on a separate development line.

When creating a team in RTC, you have to affiliate it to a development line, but the wording implies this is only for process customisation hierarchy purposes. Where it all falls down is in creating iteration plans, burndown charts etc, where you can only see these for iterations in the development line to which the team has a primary affiliation. I want to be able to see how a team is getting on with its work on the other development lines, but there seems to be no easy way of doing so.

Anyone got any suggestions, or plans for addressing this concern in future releases?

This is something I would like to see fixed as well. Our team supports multiple "development lines" and is frustrated by the difficulty in trying to show that in Jazz.

Its one of the big hurdles holding us back from putting everything into Jazz.