Making SCM Agile

[article]

avoid schedule and cost overruns. Specifically:

    • Which of the SCM common features will bring value-added process to a small project?
    • Which documents should be produced and who will read them?
    • What mandates the need for SCM products?
    • Does senior management support SCM?
    • Does project management support SCM?
    • Is adequate funding available?
    • What measurements should be used to determine adequate CMM compliance?

What if the project team uses ad hoc methods to get things done?  Is product integrity still a major factor? What about quality? What safeguards and workflows can be used to support good SCM practices without slowing down development efforts?  If the software development group’s process capability is relatively immature and ad hoc, then product integrity and quality will suffer.  What are the alternatives to the process-heavy and document laden methodologies espoused on so many software projects? Are there more efficient ways for planning and implementing SCM?  Is there hope for the small software project?

As a former SCM practitioner for about 9 years who believed in defined processes, policies, procedures, and documentation, I realize now that the methods we used to “help” development teams actually got in their way. In spite of our good intentions, the SCM group was often a bottleneck. Our methods were arduous, slow, and error-prone, and were based on rigorous processes backed by extremely detailed procedures and verbose, out-of-date documentation. I typically supported teams of 20 to 50 developers, without the use of automated tools. Back then we worked long hours fixing problems that we had caused by “doing the right thing.”  Often, an SQA engineer worked with us to help locate and resolve problems. The software systems that were constructed were built on rigid and unforgiving timetables using a traditional waterfall approach, which meant that if there was even a minor hiccup encountered along the way, things came to a screeching halt and the customer held intense re-planning sessions with our senior management to resolve issues and negotiate funding and additional resources.

Today’s tools are very sophisticated and have the potential to bring tremendous value to software development efforts ¾ for a price. Unfortunately, some of these tools are affordable only to companies with sufficient capital to make such investments. And the tools, themselves, require experienced practitioners in their application and use. Also, keep in mind that SCM “best practices” touted by vendors require serious consideration before implementing because they may not fit well into your business domain and culture. Implement useful best practices that apply or work in your SCM domain. That is, establish and apply the processes that work “best” for you and your team. The entire list of best SCM practices that follows [3] may not apply to every domain, but should be considered as a guide to establish good overall SCM practices:

Workspaces (where developers build, test, and debug)

  • Don’t share workspaces

  • Don’t work outside of managed workspaces

  • Don’t use Jell-O views

  • Stay in sync with the codeline

  • Check in products often

 Codelines (the canonical sets of source files)

  • Give each codeline a policy

  • Give each codeline an owner

  • Establish a mainline

 Branches (variants of the codeline)

  • Branch only when necessary

  • Don’t “copy” when you really mean to “branch”

  • Branch on incompatible policy

  • Branch late

  • Branch instead of freeze

 Change Propagation (getting changes from one codeline to another)

  • Make original changes in the branch that has evolved the least since branching

  • Propagate early and often

  • Have the right person perform merges

 Builds (turning source files into software products)

  • Source + tools = product

  • Check in all original source

  • Segregate built objects from original source

  • Use common build tools

  • Build often

  • Keep build logs and build outputs

 Process (the rules for all of

About the author

TechWell Contributor's picture TechWell Contributor

The opinions and positions expressed within these guest posts are those of the author alone and do not represent those of the TechWell Community Sites. Guest authors represent that they have the right to distribute this content and that such content is not violating the legal rights of others. If you would like to contribute content to a TechWell Community Site, email editors@techwell.com.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

May 04
May 04
May 04
Jun 01