Agile SCM and Requirements

• up" functionality into higher level components. Laura Wingerd has a nice analogy : "it is easier to organise a coach load of 40 adults, each of whom has responsibility for their own packing and turns up at the appropriate time, than a car load of 4 children for whom you have to do all the packing yourself".  Thus we aren't necessarily reducing the number of items to track, but we are reducing the degree of granularity at which tracking is necessary. This is not feasible without also adhering to sound principles of modularity (factored-ness) and coupling and cohesion and encapsulation. 

• Reduce No of Changes in progress - see below.
• Reducing Number of Changes in Progress (Cognitive Overload) This relates to:  

1. working in smaller (consistent) chunks and integrating more frequently.
2. consistent configurations (such that a codeline increases in value over time and doesn't regress)
3. reducing WIP (work in progress, or inventory in lean terminology)
4. Keep mainline buildable and with known status
5. Use unit testing and other testing frameworks to ensure quality and state

A traditional method for marking status in a code line is to use labels to label a set of files and particular revisions of those files. This can then indicate which requirement they implement and what state that implementation is at.

Labels vs Change Sets. In this diagram, there are a number of individual files in a codeline, each with their own revisions. The revisions are checked in change set by change set, and yet the user has chosen to use labels to record known configurations, rather than referring to specific change sets.

In the above example, using labels which "cut across" change sets means that there are many more things to keep track of, and it is very unclear what the status of the codeline at any particular change set is. If we can train our developers to check in logical and consistent change sets, then it is generally much easier to keep track of the status of the codeline. We hope that our codeline is increasing in value, change set by change set. Each change set follows standard OOD principles: coupling, cohesion and encapsulation.

Obviously in real life, mistakes are made, but simple practices such as checking in unit tests with any changed code, and ensuring that all unit tests for the whole system run successfully before you commit your change set, make this achievable.

For those occasions where you wish to commit a partial implementation of a feature, which might either destabilize the mainline, or not increase its value, then use of a Task Branch will allow you to make those changes and integrate them back to the mainline in a single consistent change set.

The Pros and Cons of Refactoring
Refactoring is a very useful set of techniques for restructuring an existing body of code, altering its internal structure without changing its external behavior. It is aimed at making the code more easily understandable and easier to modify (respond to change) without introducing errors and unintended side effects.

Refactoring will often reduce the number of code modules in a system, reducing redundancy, so that a change has to be made in fewer places (sometimes it will increase the number but only if there are other benefits such as use of a well known pattern or to make it more easily understandable). This has the benefit of reducing the number of CIs in the system.

The problem with refactoring from a change control perspective is that it is in itself a change to the system (which needs to be controlled and reported on).