or COTS tools should be used. If possible, the same tools used for any larger teams should be leveraged, but this may not be practical. It may be sufficient to use tools such as Bugzilla or JIRA, but there could also be integrated DIET capability in the VC tools used. Since the DIET system will generally be used to generate metrics for both intra-team use and for comparison with other teams, the tool or tools will need to be capable of generating the required numbers and charts with little or no human intervention. If more than one of these tools are used, then it will be necessary to come up with a way of generating common metrics and charts, even if data analysis must external to the tools must be performed – and it will be up to the SCM group to make sure it is available and its use is “transparent” to Development and Quality.
In a similar fashion, VC tools must be able to meet the needs of both small and large teams. It is more important that the number of VC tools in use be kept to a minimum as they are typically configured to restrict undesirable behavior in addition to the normal task of versioning software changes. The same list of requirements as in the last article are applicable with the addition that they should be low overhead. Some VC tools initially acquired by Large Organizations for use with large teams and/or long duration projects often have a performance overhead that is unacceptable to small teams, especially if they are practicing any of the Agile methodologies.
Since Large Organizations typically do not object to paying for seat- or enterprise-licensing, COTS tools, with their inherent vendor support, are often selected. Tools such as AccuRev, ClearCase, CM+, Dimensions or Perforce are often selected as a part of a “solution package” by Management and can be tweaked to support multiple development methodologies. There are also FOSS tools such as subversion and git that can be used, but make sure the cost of dual maintenance and user training are acceptable.
If at all possible, use a “centralized” Build Management tool such as AnthillPro, BuildForge, CruiseControl, ElectricCloud or Hudson. If one is already present, use it. If not, the need to capture “how to build artifacts” knowledge for multiple teams, whether they be small ones or not, becomes essential. It is not uncommon that a small team will “finish” a product's development and then be reassigned to other teams or leave the organization. At some point it will be necessary to “update” the product and it will be difficult, if not impossible, to determine after the fact how to (re)build the product. Using a tool such as one of those listed above will allow both the process and the tool chains to be captured and resurrected as necessary.
Again, for all of these tools, the idea is to set up something that is low maintenance, integrates with other development tools/IDEs being used and will remain available throughout not only this product's development life, but others as well. There are other tools that can make small team development easier in the long run, tools that support Requirements Management, but for most small teams they are only worth it if they have a reasonable Return on Investment ( ROI) in terms of either schedule, quality or competitive advantage.
In general, the need to tailor existing SCM tools should be kept to a minimum and the solutions be implemented is such a way as to be reused in the future. Additional SCM