Best practice use of work item State and Resolution fields
We use a multi-step development workflow process that moves work items through various stages of Development, Quality Assurance, and Production deployment with accommodation for build requests, software deployments, and defect fixes in between. I am envisioning all these stages as "States" in RTC. However, a coworker envisions breaking these up between State and Resolutions. What is RTC's intent of how State and Resolution should be used? Why does it matter? I assume if we follow RTC's intent and best practices we'll be better served in the long run. Are these best practices documented anywhere? |
One answer
Hello Michael,
this is more a generic agile question to, rather that a RTC specific one.
I guess it all depends on your business constraints:
- resolutions might not be visible for all states
- resolutions items might differ depending on state
You may want to refer to https://jazz.net/library/article/1002,
Hope it helps.
Eric.
Comments Thanks. I found the developerworks (2nd) link to be very useful for this question. (http://www.ibm.com/developerworks/rational/library/custom-work-item-rational-team-concert/) The other link for Changing RTC Process Configuration - Best Practices will come in handy as we configure the work items more. I also found the following link that helped give some definition to state and resolution. https://jazz.net/library/article/42/
After reading these, it seems the resolution field is really intended to help document a work item that is in some sort of closed state. Does this mean it probably doesn't make sense to use the resolution field for Open or In-progress types of States?
Well - I would think that "resolution" attribute is self-explanatory, and only valid when [OSLC] status is resolved.
Which means: resolved state possibly requires a resolution.
On the other hand, a resolution has no real meaning in [OSLC] open state.
What do you think?
Eric.
|