Comments (3)
  • Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

1 Govind_Baliga commented Permalink

The one thing that really works well for us is keeping track of change request (defects and RFEs) using Rational ClearQuest. Armed with business priorities, description,
use case scenarios, release/build information, it becomes easy to measure quality of a given release. With clear documentation in place, the engineering team can easily address
a defect/RFE and testers can then proceed with validation once a change request is marked resolved for a particular build/release. Additionally, conducting regular Change
Control Board (CCB) meetings during a release cycle helps the team focus on the identified change requests with appropriate business priorities.

To learn more information and best practices on Rational ClearQuest, visit

2 archwho commented Permalink

There is always a designated adult for such things . :-)

3 thartric commented Permalink

Great points Govind. Thanks for bringing them up.

Rational ClearQuest (CQ) is key to managing the long lists of requirements and bug fixes. I can't believe I didn't mention CQ!
Regarding Change Control Board meetings, in the "old days" when you had a small team all located in the same building we'd do hallway mtgs. Near the end of a release cycle, we'd prepare a white board with the "top 10" defects and start the day with a short team mtg in the hall (we'd make folks stand so it would be focused and short). The daily defects would get reported on or assigned. Near the end of the day we'd do the same thing. Now that most organizations have developers possibly spread throughout several locations, the "hallway mtg" CCB concept moves online and over the phone but still a very effective way to manage change control.