At the start of our last article on the applicability of some principles of martial arts we talked about the importance of requirements when deciding on a martial art, so it seems fitting this month to look at the implications of requirements for agile SCM.
The process of eliciting requirements (the phrase "requirements gathering" rather brings to mind wandering around an alpine meadow with a basket under your arm plucking one juicy requirement after another while singing along with Julie Andrews!) is a specialist area with many of its own techniques and practices.
Configuration Management and Requirements
From a configuration management point of view, what is important about the requirements (and analysis) phases?
- Change Control - tracking and verifying changes to the requirements themselves for the purposes of reporting on status. Also change control for the whole development in terms of controlling changes to requirements and code.
- Baselining of Requirements - see below.
- Traceability and Auditability - linking code and other changes to the requirements for them, becoming increasingly more important in a Sarbanes Oxley (and related corporate governance regulations) world. Also verifying that the changes that have been implemented are valid and necessary (no back doors introduced!).
Requirements and Change
From an agile standpoint we are going to take an iterative development approach as a given. Note also, that the very process of releasing an interation means that we have a complete working system, thus ensuring that issues around system integration, or build and installation/release are not allowed to fester in a neglected corner, coming back to bite us at the most inopportune moment.
A recent discussion in the blogosphere ( How Two Hours Can Waste Two Weeks with responses You Call This Agile? shows an informative level of discussion taking place helping refine the thinking needed to apply agile methods and not get blind-sided by pure theory.
In classical configuration management, the purpose of a "functional configuration audit" is to ensure that the "baselined" software version correctly+completely+consistently satisfies the corresponding "baselined" requirements
In the above diagram, tests (test cases and executable tests) are also baselined, and refer to the appropriate baselined requirements which they are testing.
In some agile methods, automated unit and higher level tests provide a level of "executable requirements spec" which minimizes intermediate artifacts, and makes things easier to maintain and keep consistent (satisfying lean development principles).
Reducing Complexity During Development
At an even higher level, we are thus talking about communication and collaboration with our customers, management and others. From an agile point of view we wish to make this as easy as possible and with minimal extra effort. This will also satisfy the "Lean" principles are of minimizing intermediate artifacts and minimizing redundancy and dependency, and non-essential artifacts. This will start enabling us to achieve trustworthy transparency.
How can we make it easier to track what is going on during development and to be able to control and communicate (report on) the status of all our configuration items?
The easiest way to do this is to reduce the number of items we need to track. This includes not only the CIs in our system, but also to reduce the number of changes to those CIs in any given iteration. At first glance this may seem just not to be possible - we can't unilaterally just reduce the number of CIs in the system!
But there are of course very standard ways of making information easier to grasp by grouping it, and compartmentalizing it.
- Component based development (when done well) can reduce the complexity of the development problem by "chunking