In his CM: the Next Generation series, Joe Farah gives us a glimpse into the trends that CM experts will need to tackle and master based upon industry trends and future technology challenges.
Change requests are quite different from changes and should not be used as a change container. A change request might be implemented in several changes across several releases. Or multiple change requests might be addressed by a change. The originator, or requestor, of a change request communicates the request to the product team, which ensures that it has a proper understanding of the request. Once this handoff occurs and the product team accepts the change request, it is treated as a requirement. The originator will want to know when the request will be/has been implemented and when it will be delivered. The originator is responsible for closing the request (i.e., indicating that the implementation meets the criteria of the request).
Builds as the Key Reference Points
Where does the build come into play? It must be possible to take any build and identify which requests of a particular originator (or group of originators) have been met by that build. On the flip side, that leaves the set that is outstanding. If your CM traceability cannot give you this information, you need to improve your data and processes. Ideally, this information should be available at the click of a button (or at least a simple report request panel).
When this loop is closed, your builds are more than just a set of executables. They become the key reference points for communicating with your customers:
· What release is the customer running?
· What requests are still outstanding for that customer?
· What requests are addressed by the next release that weren't previously addressed?
· What problems have been fixed in the new release that were not fixed in the customer's current release?