There are many configuration management tools available to organizations, so one of the first questions asked usually will be, "Which tool should we use?"
"Getting too hung up on tool selection--or, put another way, starting to evaluate tools before understanding what an organization needs--can be a problem," Steve Berczuk says. "Tools should support your workflow. Like many things, it's easy to get hung up on features without thinking about how they will be used. Teams should select tools based more on a use case analysis approach than a feature analysis approach."
Berczuk notes that this may be an across-the-board problem, as many organizations develop their software based on lists of features, rather than the actual problems the software will need to solve.
Another prominent issue an organization encounters when contemplating tool choice is cost, Berczuk says. "On the one hand, your [software configuration management] system is a key component to your application development process, so it doesn't pay to be too parsimonious when selecting tools. On the other hand, there are open source tools that can work quite well, so there is no reason to work without version control or with an inadequate tool."
Not all development teams are created equal, of course, but Berczuk says one thing holds true whether you have a small group of people meeting in the same room or a large team distributed across time zones: "It really all comes down to a team's having shared goals." Tool support helps keep track of changes in large teams, he says, but "a group of people in the same room may not always communicate effectively either." Practices such as unit testing keep everyone on the same page and ensure that code remains in working order.
Berczuk recommends that all requirements documents and other development artifacts be accessible from a single repository, but suggests that an organization should be mindful of why it is archiving the process documents in the first place.
"In most cases what you care about is what the customer wants now, and it's not worth a lot of overhead to have a detailed process for tracking the change history for things like requirements," he says. "If the change control process is lightweight, there is probably no reason not to [incorporate it into the CM process]. In some cases you might have regulatory or other requirements, so that the management of changing requirements has a business goal. In those cases, add them to the CM process."
When in doubt, Berczuk recommends the following:
- If it helps you build the product (this includes things needed for any required documentation), put it in the CM system.
- If you are not sure what the need for the item is, but tracking changes is easy, why not add it?
- If the reason for adding an item to a CM system is unclear and the process takes excessive time or effort, you might consider skipping it.
"Tests can be the best documentation of what a system is supposed to do," Berczuk says, "so there is a lot of value in keeping tests in your CM system."
