if you can think of more):
1. Are software builds performed regularly?
2. If so, are the builds successful? If not, your problem may not be an SCM problem, but a project management issue.
3. Are defects tracked from identification, fix, test, closure, build, and verification?
4. If branching techniques are practiced, are merges done often?
5. Is parallel development practiced?
6. Are codeline policies prepared, communicated, and used?
7. Are there sufficient smoke testing, unit testing, and integration testing?
8. Are there current, defined, and well-documented CM processes in place?
9. If not, why not? (The answers to this question may be a significant part of the problem domain.)
10. If so, have they been in place long enough to prove that they work? (That is, has the team used these processes for a sufficient period and do those processes work?
11. If not, then consider using the processes for 12 months. (9 months may be sufficient in some working environments.) This should be sufficient time to sort through most issues.
12. Is everyone agreeable to the CM processes currently in place? That is, are more changes needed to the CM processes to improve the way things are currently done?
13. If so, then collaborate the proposed changes with all affected parties, make all appropriate changes, and allow for sufficient usage time (see step 10).
14. If not, then the current CM process must be working - and automation should be considered only if the current processes are beginning to hinder or otherwise create bottlenecks.
Only upon reaching step 14 should the organization consider automating CM processes. Automating does not necessarily make things function more efficiently - especially if the automation creates problems in other activities such as defect resolution, and tracking builds, changes, baselines, and other things. Be smart when considering automating CM processes by determining the exact needs of the software team. Form a group consisting of key developers, network and system administrators, librarians, build-meisters, release engineers, SQA engineers, object modelers, designers, testers, source code checkers, the SCM group, software managers, DBAs, technical writers, and others as appropriate to discuss CM issues. Determine each person's or function's needs, then document these needs along with known constraints, complaints, and problems into a requirement document. This document will serve as the basis of need for a SCM tool.
What must you have? What can the group live without? What is the budget or how much is the organization willing to invest in a solution that protects the integrity of their product(s)? Are there plans to increase the software development group? Will the solution be required to support the enterprise or the organization at multiple locations? Can Web-based applications, legacy applications, and shrink-wrap components be supported by the same SCM solution?
All these questions and more must be asked and answers known before a SCM solution is identified as vendors will need to know these things to ensure their solution is right for you. And only after you and your software team has accomplished sufficient due diligence, will you really know the answer, "When it is appropriate to automate SCM?"
- Steve P. Berczuk, Brad Appleton, Software Configuration Management Patterns: Effective Teamwork, Practical Integration , Addison Wesley, 2002, ISBN 0201741172
- Anne Mette Jonassen Hass, Configuration Management Principles and Practice , Addison Wesley, 2003, ISBN 0321117662
- Dick Carlson, Making SCM Agile , CM Crossroads, April 2003
Dick Carlson is a consultant with 20+ years of software engineering experience that focused on software development training and mentoring, development and implementation of software lifecycle methodologies, software configuration management, software quality assurance,