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.
There are a lot of best practices in the CM trade. You might be hard-pressed to pick the best ones out. But that's exactly what we'll try to do in this month's article. You may see a few that you're quite familiar with. There may be a few that are hotly contested issues. I'll bet there's more than a few that you haven't fully considered before. Of the dozens of CM/ALM best practices we use ourselves, I've tried to pick the top ten. It was a difficult task, so I'll start by mentioning the 10 runner-ups.
20. Organize Shared Code into Separate Products
When you're producing software that is shared by different products, issues such as development ownership, timing of releases, etc. are typically difficult to manage because the different products utilizing the shared code have different sets of requirements, and possibly differing processes. Often the shared code starts out as part of one product's
development but business logic dictates that it be shared in multiple products.
The best practice in this situation is to partition the shared code into one (or more) separate products. That product has as its customers, the other product teams. Control of releases, frequency, features, etc. really have to be managed as a full product is
managed. Different customers will want to move to new releases of the shared product at different times. Some will want the new features, some won't want the risk. The shared code may need to branch into different release streams to support the various customers.
19. Use Change Promotion instead of Promotion Branches
Branches are often used to track changes. This strategy works, but it is generally used because of insufficient tool and process technology. Promotion branches help ensure changes are promoted through the promotion levels dictated by the process. However, they assume a pessimistic strategy which caters to the worst case rather than the most usual case. As a result, there is a lot of merging, labelling, etc. that is unnecessary. Roll-backs are also difficult. As well, it's quite difficult to adjust the change process to support additional promotion levels, because of the cost of each promotion level in terms of merging/labelling, and because of the administrative issues involved with the insertion of new promotion branches among the existing ones.
Ideally, you should use technology where promotion is simply a status change on the change object (assuming there is one). With the appropriate processes and technology, merge operations should only be required when changes don't flow through the change promotion process in the same sequence from level to level. So generally, the configuration management is reduced to simply change management - promoting/rollback the change status. The technology should allow you to view configurations at each promotion level based on the change status alone. So although this is a best practice, it is highly dependent upon the proper technology.
18a. Separate Customer Requests from Engineering Problems/Features
Customers want to raise problems, ask for new features, or simply specify how
they believe the tool should operate, without reference to whether it is a feature request or a problem report. Some customers will ask for the same features as other customers, perhaps with a different twist or priority. Customers want to know the status of their requests, many of which can be dealt with directly by the technical support team
without involving the engineering team. Some are data configuration issues, others non-problems. The customer just wants the majority of requests addressed successfully.
The engineering team doesn't care about how many customers report a problem or request a feature - they just want their marching orders: a list of problems to be fixed
and a list