I have been tasked with creating the RTC Project Areas within our organization. I was hoping for some input on best practices. Considering creating one PA for each application or one PA per line of business/product. Our biggest concern is maintenance costs moving forward. Thoughts?

Hi Karla...

This is a difficult question and I think there isn't a single answer. Most probably, it depends.

I believe you must consider how you will manage the WI', plans, the need of share code, etc.

I'm very interested on this topic too. I hope our colleagues can help us.

Thanks for your thoughts! fingers crossed we hear from a few more, Luiz!

Hi Karla,

As Luiz said you haven't a single answer to your question. Particulary, when defining a RTC model I like to keep the following in mind:

1. Keep the context together - Always define project areas following clear rules that put together things that belong to the same context. Avoid scenarios where you have you information spread over many project areas.
2. Keep simple - It is very important keep the Work Items simple. Not only the web interface, but how and when you link them.
3. Use plans to plan - Use the RTC features to do what it were design to. RTC is a very flexible tool (what is good), but with "great powers comes great responsabilities". So, it is important to ask yourself if you are not "overusing" some feature.
4. Be agile - Split your definitions in small blocks and create the model iteratively. Collect feedback soon as possible.

I hope that this helps.

Att.

This is a bit of a gray area, but here are some conditions to consider:

Kenny Smith

Principal Consultant

IBM Champion 

www.strongback.us

Can I add more question(s) here on this topic?    

Our organization has a waterfall and "sort of " agile process.    We have multiple projects that span multiple releases, as well as some (defects and quick projects) that are in one release.     30% of the projects for a variety of reasons (some valid, such as client change, some not valid such as changing priorities) that cause a project or code slated for a release to be moved to another release.

We are new to RTC - we were 95% of the way switching from DIM and GIT to RTC then we hit this perceived obstacle.   HOW HAVE OTHERS ADDRESSED THIS?     We will have code from multiple teams slated for a release - so we move the code from our workspace to DEV via RTC.  Then from DEV to QA and QA to PROD.  Once we move code from the workspace to DEV, we find we need to either pull back code (client changes their mind) or keep code in DEV for the ~next~ release due to necessary integration with other teams or need to re-add code to fix what broke in DEV (it worked fine in the personal workspace).    How do companies deal with this?  What are best practices?    We are on HOLD until we can figure our some solutions to our challenges. 

First, I'd like to second Kenny's recommendation as far as how I recommend our product teams organize.  Although Project Areas are one way to delineate access to artifacts, I usually prefer to look at them as more of a methodology context.  That is, if you need to work in an Agile way vs. Waterfall, you'll need two different project areas to define the differences between the two methods.  Other than that, if you can split up by team areas and possibly with different timelines/streams/etc per product, then I suggest you stay within the same project area (or a project area hierarchy that "inherits"/overrides the process from a common master project area with each product/program living in their own "child" project area).

As far as Thomas's stream hierarchy question.  If you're doing development in parallel for multiple releases, I would recommend having a different Dev stream for each release (may even want to have separate stream hierarchies Dev/QA/Prod for each release).  You don't have to think of streams as a single tree trunk, they are relatively lightweight configuration objects and, in my experience, it's quite ok to have dozens of them owned by a project/team area.  If you look at jazz.net (i.e the product development dashboards hosted there which you can access after logging in with your jazz.net credentials), you'll see that that's how the IBM teams that develop the CLM products organize their code, and who better to learn from than the inventors of the technology?

Alex Akilov
Systems Programmer IV
Black Knight Financial Services

Continuing my previous post.  Another approach is to have the lower level stream be a dumping ground for all releases but use the higher level streams as a way to target a specific release.  That is, you can deliver any change to Dev but if you want your changes slated for the upcoming release, you "promote" them to the integration/prod stream for that release once it's been approved by the customer.  if it's meant to go to a future release, you can promote them to the integration stream for the next release and so on.

Alex Akilov
Systems Programmer IV
Black Knight Financial Services

sorry,

i can not figure out your problem,

if you can do this in a version control tool as Git, you can do it always in a software configuration management tool as RTC.

you need the right understanding of components as small containers of your data and streams as flows where you deliver all (or just) the data you want to have in this stream. And yes, you might have more than one stream, if you have more than one content to deliver.

that's life if supporting different variants

Multiple Stream Development
basic
https://jazz.net/library/article/40

Managing parallel development with Rational Team Concert
lot of info
https://www.ibm.com/developerworks/rational/library/parallel-development-rational-team-concert/

Hi Karla,

we have actually gone what may be a different direction entirely - with over 500 development teams, we have created one giant project area with multiple teams.  The PA is organized by teams, and each team may have one or more projects listed to track against in the Project attribute (yes, we created a custom attribute called Project for the appropriate work items).  We've been working this way since 2009.  I am sure there may be issues that we could run into with this configuration, but we haven't come across any yet.  In fact, we did originally have one other PA when we thought we wanted to branch out by major business division, but it actually caused many issues for reporting when the programs split up the work across multiple teams across multiple divisions.. so, we have been slowly migrating teams back to the singular PA.  This also enables us to limit the number of SCM and Build licenses we have to use for integrating with GitHub and Jenkins.   Hope that helps, thanks!