Best approach to handle multiple projects.

Another way of stating "interject the features at a later time", these separate projects will produce artifacts that may or may not be combined and delivered as workbench/framework/product. Its clear to me, that we could use one main project, but have sub-projects, but because each sub-project has its own set of processes, requirements, we don't want to confuse by only have one place to list them. Perhaps, you will tell me there is a way to hide the individual project requirements and expose to the main project as needed.

In order to have separate visibility for each project, you would have to have each project in its own project area (read access is controlled at the project area level).

In RTC-2.0, to combine features from different project areas in a single report, you cannot use the Agile Planning GUI (which only covers a single project area), but instead would need to use RTC reports to do so. Work is being done in RTC-3.0 to improve cross-project plan reporting (work item 99042)

Could you expand a bit on what you mean by "interject the features at a later time"?

Cheers,
Geoff

I have searched the existing threads for recommendation on project structure, but am still unsure of the best approach. Can you recommend the best approach for the following scenario?

I am looking at supporting several (integrated) projects. The features from each project will likely be integrated into productized plan at some point. Each product has its own process, requirements, team members, etc. Although, team members may be part of each project. I am looking for the best way to not have tightly shared visibility between each project, but do want to be able to interject the features at a later time.

You can customize the process to a significant extent in a team area, so
needing to customize the process for a team doesn't necessarily require
you to give a team its own project area (but for some process
customizations, such as adding a new work item type or state, you would
need a new project area).

If by "hide", you just mean that they appear in separate lists, then you
can do that in a nested team areas in a single project area. If by
"hide", you mean read permission is strictly enforced (i.e. other teams
cannot see your plans and requirements, even if they try to), then you
would need separate project areas.

Cheers,
Geoff

eburwell wrote:

Another way of stating "interject the features at a later
time", these separate projects will produce artifacts that may
or may not be combined and delivered as workbench/framework/product.
Its clear to me, that we could use one main project, but have
sub-projects, but because each sub-project has its own set of
processes, requirements, we don't want to confuse by only have one
place to list them. Perhaps, you will tell me there is a way to hide
the individual project requirements and expose to the main project as
needed.


geoffwrote:
In order to have separate visibility for each project, you would have
to have each project in its own project area (read access is
controlled at the project area level).
In RTC-2.0, to combine features from different project areas in a
single report, you cannot use the Agile Planning GUI (which only
covers a single project area), but instead would need to use RTC
reports to do so. Work is being done in RTC-3.0 to improve
cross-project plan reporting (work item 99042)
Could you expand a bit on what you mean by "interject the
features at a later time"?
Cheers,
Geoff

eburwellwrote:
I have searched the existing threads for recommendation on project
structure, but am still unsure of the best approach. Can you
recommend the best approach for the following scenario?
I am looking at supporting several (integrated) projects. The
features from each project will likely be integrated into productized
plan at some point. Each product has its own process, requirements,
team members, etc. Although, team members may be part of each
project. I am looking for the best way to not have tightly shared
visibility between each project, but do want to be able to interject
the features at a later time.

Hi,

two details to add with using different project areas.
Different project areas give the opportunity to hide/protect source code from being read. For instance check http://jazz.net/library/video/54 and http://jazz.net/blog/index.php/2009/05/21/patterns-for-read-protecting-source-code-2/ for a better impression.

However, assuming one has access to project areas containing the code it is possible to later bring code from other project areas over as an example if you need to use some framework produced by somebody else.

According to the articles above you could even decide to have some common project for common planning purposes (work item access) and other(s) containing the source code. So even a mix could be feasible in some cases.

I haven't tried that myself but I would consider read permission one of the most important considerations. The next consideration is simplicity: reduce maintenance. If the "projects" are small it would be a good idea to maintain rather team hierarchies in one project are, if the processes are not too different. E.g. if all share a common set of work item types you could stay in one project area.

If they shall be able to define completely different ways of working e.g. one SCRUM one Waterfall and different sets of work item types and -customization you would definitely go for different project areas.

Just my 2cents,

Ralph