Configuration guidance - base product with add-ons all devel

I have a group looking to move to RTC from another library system. I'm
struggling with how to set this up in RTC. There's a base product which
has multiple versions each of which will need to be maintained. Then,
there are several products that can be applied on top of the base
product. Theses are developed and released independently (of each other
and the base product). The "add-on" products have some common source
between them. The "add-on" products need to be maintained for each of
the base product versions.

My initial thought was to use a single project area, create several
teams, one for the base (and maybe subteams to further break this down)
and one for each "add-on" product. Create one or more components for the
base product, each "add-on" product, and a component for the piece
common to the add-ons.

There would be a main team stream for the base product, containing all
of the components of the base product. And a main team stream for each
of the "add-on" products, containing the associated component and
"add-on" common component. New release and maintenance streams would be
derived from these main team streams.

Does this seem like a reasonable approach? It seems like the "Project
Area" is oriented toward development of a single product, or pieces of a
product that will be released together, where we need something that
supports releasing the base product and each "add-on" independently. One
aspect that's not clear is how the iteration planning would come into
play here given the independent nature of the pieces involved.

Any thoughts on how we can best organize this are appreciated. We want
to start with one add-on product as a pilot, with the intent of moving
the other pieces in over time.

Thanks, Brian

In general:

If you need a very different process, create a new project area (it
probably would have been better to call it a "process area" instead of a
"project area", to avoid all of the different (incompatible) ways in
which people use the term "project".

If you have a distinct team (group of people working together), create a
new team area (in the project area that has the right process for that
team ... you can adjust the process in your team area if you need to).

If you have a distinct variant of a product/system, create a stream for
it (in the team area of the team that is responsible for that variant).

So what you describe is reasonable, but note that you don't need to have
a separate team area for each product/variant unless those
products/variants have different processes (the cost of an additional
team area is that you need to maintain the processes and role-maps for
each team area).

Cheers,
Geoff

Thanks Geoff. I suspect we will want the general process to be the same

Geoffrey Clemm wrote:
In general:

If you need a very different process, create a new project area (it
probably would have been better to call it a "process area" instead of
a "project area", to avoid all of the different (incompatible) ways in
which people use the term "project".

If you have a distinct team (group of people working together), create
a new team area (in the project area that has the right process for
that team ... you can adjust the process in your team area if you need
to).

If you have a distinct variant of a product/system, create a stream
for it (in the team area of the team that is responsible for that
variant).

So what you describe is reasonable, but note that you don't need to
have a separate team area for each product/variant unless those
products/variants have different processes (the cost of an additional
team area is that you need to maintain the processes and role-maps for
each team area).

Cheers,
Geoff

Thanks Geoff. I suspect we will want the general process to be the same
for each "product". I think the main differences for each will be who
will have permission to make changes, and the development schedule. The
former could be controlled with roles within a team area, right? And
it's not clear to me how the later would be done since it seems like the
process iterations (if they want to use the planning tools) are defined
at a "Project Area" level, not team level. Or is that what you mean by
your comment about project versus process area? Would it be a matter of
perhaps creating a separate development line for each "product" being
developed?

Regards, Brian

"Geoffrey" == Geoffrey Clemm <geoffrey> writes:

"Geoffrey" == Geoffrey Clemm <geoffrey> writes:

Geoffrey> The development schedule (iteration layout) is (currently)
Geoffrey> considered part of the process, and cannot be customized in a
Geoffrey> team area. There is a separate thread currently discussing
Geoffrey> whether that association is appropriate (i.e. whether the
Geoffrey> schedule should be definable on a per-team area). But
Geoffrey> currently, you cannot modify the schedule in a team area, so
Geoffrey> you would need to create separate project areas for each
Geoffrey> distinct schedule (iteration layout).

Ah, but you can create multiple development lines in the project area,
one per team area--and each development line can have its own iteration
schedules.
This works if you're just using the agile planning tool, does it also
make sense if you're using Jazz SCM?