RTC as a front end to the business for request submission
I think I know the answer to this, but I'll ask anyway:
We would like to replace our current method of having the business submit enhancements and defects thru BMC Remedy and let them submit them directly into RTC. However, it appears that there are a few major limitations: - We can restrict what attributes a user can modify, but that is only apparant when the user tries to save the record and gets an error. - In some RTC projects we would like to restrict certain roles from seeing the project plans, while still allowing them to submit.There does not seem any way to do this. - More generally, is there a way to suppress, based on role, the top level RTC menu items - i.e. Plans, Build, Source Control, Reports etc? - I wonder if one way around this is to create a "Triage" project with skinnied down work item attributes and then allow authorized users to move the work item into the appropriate RTC development project? Interested in hearing any feedback from anyone who has had to design RTC architecture to accomodate stakeholder usage.... |
12 answers
Ralph Schoon (63.1k●3●36●46)
| answered Aug 28 '10, 4:23 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Hi Tony,
today, Team Concert is stronger in allowing collaboration than restricting it... One way to implement what you are requesting would be to create a project where your business people can submit work items. These work items can be used by the developers. They could create a stub work item or child task in their project. They could also attach change sets to the work items in the business people's project. There are several options to use what RTC provides today. Having said that, in 3.0 there will be some enhancements - I'd like to encourage you however to create a work item for the issue with permissions to see plans, etc. as well as that the permission check is after doing changes. Thanks, Ralph I think I know the answer to this, but I'll ask anyway: |
|
It is not my preference that things be hidden from the business. That comes from the CIO. Assuming I can ignore that concept for the moment are you suggesting that these change requests submitted by the biz live in a seperate RTC project and that development projects link to them?
If that is so, how does the business see the status of their requests? I assume work items in other projects cannot roll up to these 'business plan items'. The status of the plan items in the business project would have to be manually maintained. I'm probably missing another Rational tool which manages business change requests, which after triage and prioritization, gets them over to RTC as something actionable..... |
Geoffrey Clemm (30.1k●3●30●35)
| answered Aug 28 '10, 9:52 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Yes, if you want to restrict read access for a certain set of users,
create a separate project area for those users. But instead of moving a work item to the development project (which would make it disappear from view of the submitter, which would not be a good thing), a developer should create a separate "task" work item, which is where they would do their work on the request, and link that task work item to the request work item. So rather than scheduling the "request" for an iteration, you would indicate that a particular request was to be worked on by linking it to a task, and then that task would be scheduled for an iteration. There are a variety of advantages for making this split anyway, including making it clear when information such as "priority" reflects the submitters priority, or the developers (schedule) priority. Note that this (having separate records for requests and tasks) is the primary model when using the ClearQuest Bridge. You create requests in ClearQuest, and create tasks to work on those requests in RTC. Cheers, Geoff On 8/28/2010 9:23 AM, adefarlo wrote: I think I know the answer to this, but I'll ask anyway: |
|
Thanks Geoff,
A minor variation on your suggestion. Between the request and the development task is another plan-item - what we call the deliverable. i.e a change request can be decomposed in team deliverables, and those deliverables then break down into tasks. I think this will work - based on the change request teams then define plan items in their individual RTC plans. Of course the only limitation is that task estimates, which roll up to the deliverable level, do not roll up to the request level, which would be a nice to have, showing the total estimated work for the change request across all deliverables. Maybe there is a way to do this. If so, do tell. |
|
Actually, it seems like equating our change requests as an epic might work, since the epic seems to roll up stories points from stories (our deliverables) underneath it. I'll try a test, hoping that if the epic lives in a different project, it will still roll story points from stories living in different projects....
|
|
Geoffrey Clemm (30.1k●3●30●35)
| answered Aug 29 '10, 10:47 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
You can make a story in one project area a child of an epoch in another
project area (as long as both project areas are in the same repository), but story points do not roll up across project boundaries. Note sure why that is ... perhaps the planning team could explain? Cheers, Geoff On 8/29/2010 4:37 PM, adefarlo wrote: Actually, it seems like equating our change requests as an epic might |
|
Yes, I confirmed that there is no rolloup of story points or hours if the epic is in a different RTC project. Would be awesome if it could, particularly if it is just a matter of changing the process configuration source somehow, and not submitting an enhancement request. I guess some custom code might be able to do this as well.
Thanks for your help.... |
Yes, I confirmed that there is no rolloup of story points or hours if the epic is in a different RTC project. Would be awesome if it could, particularly if it is just a matter of changing the process configuration source somehow, and not submitting an enhancement request. I guess some custom code might be able to do this as well. Hi Tony Just so you know, I am aware of two different customers who use ClearQuest and RTC to do more or less what you describe - and has been suggested, CQ is the "business" interface, RTC is the development interface of choice. regards anthony |
Hello all,
I am in a similar circumstance. We use ClearQuest as a development tool, as well as other things from a "helpdesk"-type tool, a generic request system, etc. RTC seems to have a lot of development (software/hardware) type templates, and we want to begin to move away from ClearQuest, so we are trying to figure out how this would go. |
|
I don't see why I would want to maintain both CQ and RTC. RTC has most, if not all of the functionality of CQ, but of course adds more.
I'm designing the RTC architecture to support the full change management spectrum: help desk, change requests, defects etc etc. Not running into any big issues so far. Very pleased with how flexible the architecture is. The only issue, for non-development related RTC projects, is that RTC includes the concepts of timelines. This adds resource management and planning capability to areas that may not have had them in the past. So not only do you introduce new tooling, but new business concepts in some cases. Hello all, |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.