and it doesn't really matter anyway - it's input to the product team. But it's critical to distinguish engineering problems from features as they are completely different processes. All this to say, track customer requests separately from engineering problems/features. That is not to say that you should use a separate repository. And of course the engineering records should be
traced back to the customer requests.
18b. Separate Problems/Issues/Defects from Activities/Features/Tasks
A related best practice that we touched on in the last paragraph is that problem fixing is a completely different process from feature development. One is a fix to the product because it didn't meet the requirements. No new requirement specification. And the specification for the change is the problem report itself. The first step is to ensure reproducibility. The problem has to be investigated for potentially all supported development streams. And so forth.
Feature development is completely different. The feature has to be designed and fully specified. New requirements are needed to put the case forward for the feature. User documentation has to be updated. A new set of test cases has to be established. Problems and Features (or more generally activities) are different beasts. Don't try to track them both as "tasks". If you have separate ALM tools to deal with those processes, that's perhaps a different matter. But in a fully integrated system, keep them separate.
17. Use Tags and Separate Variant Code into Separate Files
Avoid the temptation of using parallel branches to manage separate variants. Consider that if you have 3 variant options for language, 3 more for security level and 2 more for packaging, you'll have 18 branches already. Variant management must be addressed in the software engineering realm, not in the CM realm primarily.
The CM realm should allow you to tag files with the appropriate variant tags, and to
select files based on one or more specified variant tags. In some cases, the CM tool might go so far as to allow you to tag specific changes as "variant" changes, that can be "automatically" applied to your source code when that variant is selected.
But the bigger task of the CM manager is to make sure that the development
organization understands how to deal with variants. The preference is run-time configuration. Next to that is link/load time configuration (by selecting the files to load or to link together). Then comes compile-time variants, also known as conditional compilation. This is less appealing because you then need different variants of the same object file, making your build task more complex (often the entire build is replicated for each variant to get around this problem). But at all costs avoid the parallel branch approach.
16. A Problem Is Not a Problem Until It's In the CM Repository
This best practice will seem obvious to those who have always relied on good
processes. A problem is not a problem unless it is defined in the CM repository. That means that you don't have source code changes to fix problems that have not been identified in your problem tracking system (which should be part of your CM/ALM system). When you fail to abide by this rule, you get source changes in that have not been authorized. You get problems fixed that you don't know about and can't tell your
customers about. Your quality metrics get messed up. And so forth.
If you've always relied on your developers to just identify and fix bugs without reporting them, stop it. Force them to raise a problem report, but make it easy to link that problem report to their change so that they don't have duplicate data entry describing the change. If you don't know how many problems you've fixed, you'll never have any idea as to how many are still left to fix. Simply ignore problems (other than true emergencies, and other than getting the source to