RTC Defects for multiple streams?
Are there best practices for logging and managing defects in multiple streams?
We have a maintenance stream for v1.0 and a development stream for v1.1
We thought having less items to manage was better to track both streams in the same defect and to flag defects that are to be part of a maint. release we would use tags instead of creating a duplicate defect for each.
This prevents the problem of triaging many items twice, and having relevant defect info added to one but not the other copy, but may pose a problem when querying and when a fix for maint. is not done at the same time as a fix for the dev stream.
We figure all dev teams have struggled with the best way to handle this?
Are there any supporting documents or material that describe what Jazz RTC dev envisioned for this?
How are other teams handling this?
We have a maintenance stream for v1.0 and a development stream for v1.1
We thought having less items to manage was better to track both streams in the same defect and to flag defects that are to be part of a maint. release we would use tags instead of creating a duplicate defect for each.
This prevents the problem of triaging many items twice, and having relevant defect info added to one but not the other copy, but may pose a problem when querying and when a fix for maint. is not done at the same time as a fix for the dev stream.
We figure all dev teams have struggled with the best way to handle this?
Are there any supporting documents or material that describe what Jazz RTC dev envisioned for this?
How are other teams handling this?
5 answers
I did find an older post on the same subject, but still hope for some replies.
https://jazz.net/forums/viewtopic.php?t=2573
I hope the Jazz dev team can share their vision in this regard too.
Thanks for any information or contribution to this topic.
Steve
https://jazz.net/forums/viewtopic.php?t=2573
I hope the Jazz dev team can share their vision in this regard too.
Thanks for any information or contribution to this topic.
Steve
One approach is to create a "defect" workitem for the defect, and then
create a separate "task" workitem for each stream in which that defect
is to be fixed. The "defect" captures the problem, and the "tasks"
capture the work done in a particular stream to solve that problem.
You can look at the stories in the Rational Change Management category,
to see how we are planning on providing support for that scenario in the
context of a RTC/CQ integration scenario (where requests are created in
CQ, and tasks are created in RTC).
Cheers,
Geoff
hyde wrote:
create a separate "task" workitem for each stream in which that defect
is to be fixed. The "defect" captures the problem, and the "tasks"
capture the work done in a particular stream to solve that problem.
You can look at the stories in the Rational Change Management category,
to see how we are planning on providing support for that scenario in the
context of a RTC/CQ integration scenario (where requests are created in
CQ, and tasks are created in RTC).
Cheers,
Geoff
hyde wrote:
Are there best practices for logging and managing defects in multiple
streams?
We have a maintenance stream for v1.0 and a development stream for
v1.1
We thought having less items to manage was better to track both
streams in the same defect and to flag defects that are to be part of
a maint. release we would use tags instead of creating a duplicate
defect for each.
This prevents the problem of triaging many items twice, and having
relevant defect info added to one but not the other copy, but may
pose a problem when querying and when a fix for maint. is not done at
the same time as a fix for the dev stream.
We figure all dev teams have struggled with the best way to handle
this?
Are there any supporting documents or material that describe what Jazz
RTC dev envisioned for this?
How are other teams handling this?
hyde wrote:
In our team, we assign the defect to the earliest applicable milestone,
and port the changes (either by accepting and merging, or patching) into
more recent streams, noting in the work item if there is something
significant of how this work was completed in a particular branch.
As time goes on, and our release streams diverge further and further, I
could see us moving towards a structure along the lines of what Geoff
wrote.
Regards,
JohnC
SCM Server
We thought having less items to manage was better to track both
streams in the same defect and to flag defects that are to be part of
a maint. release we would use tags instead of creating a duplicate
defect for each.
In our team, we assign the defect to the earliest applicable milestone,
and port the changes (either by accepting and merging, or patching) into
more recent streams, noting in the work item if there is something
significant of how this work was completed in a particular branch.
As time goes on, and our release streams diverge further and further, I
could see us moving towards a structure along the lines of what Geoff
wrote.
Regards,
JohnC
SCM Server
Our initial goal is to keep it simple and i believe that less defects to manage is better (is this true?)
We are proposing the same approach as John's, but also using tags to flag when a defect is to be applied to maintenance too ( this seems to be along the lines we see RTC and RQM dev doing?)
Some possible exceptions /questions;
- what do we do when a defect fails validation in one of the streams it is supposed to be fixed in? How do you re-open it in one but not the other? if the iteration is not 'done' because a defect is not 'closed' in all streams, how can we report on this?
- how does one state /resolution in the defect accurately reflect all the streams' status?
Perhaps using approvals for this? We are still looking into how this could be set up.
We are proposing the same approach as John's, but also using tags to flag when a defect is to be applied to maintenance too ( this seems to be along the lines we see RTC and RQM dev doing?)
Some possible exceptions /questions;
- what do we do when a defect fails validation in one of the streams it is supposed to be fixed in? How do you re-open it in one but not the other? if the iteration is not 'done' because a defect is not 'closed' in all streams, how can we report on this?
- how does one state /resolution in the defect accurately reflect all the streams' status?
Perhaps using approvals for this? We are still looking into how this could be set up.
hyde wrote:
It depends. Managing multiple work items when each work item serves a
single purpose will in many cases be simpler than managing one work item
that serves multiple purposes.
If it is easy to get the changes from one stream to another, then it is
probably simplest to go with one work item. If propagating the changes
takes some effort, or if the changes don't work in one of the streams,
then it's probably best to use multiple work items.
Our initial goal is to keep it simple and i believe that less defects
to manage is better (is this true?)
It depends. Managing multiple work items when each work item serves a
single purpose will in many cases be simpler than managing one work item
that serves multiple purposes.
If it is easy to get the changes from one stream to another, then it is
probably simplest to go with one work item. If propagating the changes
takes some effort, or if the changes don't work in one of the streams,
then it's probably best to use multiple work items.