to have. But in the case of a small business there is typically no time for this, and no money for consultants. Any customization has to be easy to do. It has to be done as an immediate answer to "I need to be able to do this now". If customization takes you out of the "now" zone, it no longer serves its purpose because it won't be done. If I want to insert a field in the CM repository but then find that I have to go and change all my forms, my reports and perhaps other things before I can make use of it, I'll live instead without the new field - or I'll look for someone who has already done the customization and posted it in the user group.
Now although these 10 items are critical for small business, they are still of great benefit, and even of larger benefit, to larger shops - it's just that they're not quite as essential becaues the larger shop has more resources - or at least that's been the traditional take on things.
Essetial CM Practices
Let's move on to more detailed CM Process. What are the essentials for small business? Below are 15 guidelines that you must follow to keep your small business advantage. If you stray, you'll have problems such with quality, traceability, accountability, and resources. It may look like a long list, but in fact, every bit of the process can be a part of a natural process, without overhead, and with huge payback.
- Track customer requests and spawn them into problem reports or features where applicable.
- Track all of your problems and prioritize them based on when you need them completed.
- Track the features you're working on - even if you don't have full official specifications. Make sure you identify and capture against each feature exactly those things that will affect the user documentation.
- Prioritize your features according to your development process - even if it's an ad hoc process. Make sure features are being addressed in the right order. Make sure that all simple (fast track) features are clearly tracked.
- Allow only engineering problems and features to authorize changes to your software product.
- Use a Change package for all files of each software change and cross reference it to all problems/features addressed.
- Keep Changes relatively short in time - use multiple Changes for a feature when necessary. Plan your change.
- Use a Branch per Development Stream (typically release) strategy. This leads to the most automated CM.
- Do peer reviews on ALL changes. Do them on-line if necessary. Even a one-on-one review is much better than none.
- Select files for integration into a new build by Change, not by file.
- Make sure that the Build definition is created in the repository Before the build is done.
- Perform regular automated (e.g. nightly) Builds from the CM repository. Only deliver builds built from the repository.
- Create an automated (or semi-automated) sanity test package to run against all builds as a First step.
- Automate whatever test cases you can.
- Track ownership (responsibility) and assignment (whose to-do list) for each data record.
When you look for CM Tools and Processes, keep this list of 15 guidelines on hand. You should be able to find tools that can automatically track the state of problems and features based on the state of related change packages, builds and testing. Similarly, change package status should advance automatically based on the state of builds and testing. You should not have to spend more than a few short hours customizing these relationships.
Make sure your tools