Design – Build – Run: Applied Practices and Principles for Production-Ready Software Development

3.7. Change Control Mobilization

That things are going to change is a fact and part of the nature of software development. New ideas and new ways of thinking will constantly come about. When users are testing, they'll often identify areas where improvements can be made. It's vital to a project that an appropriate change-control process is in place and that everyone understands and adheres to it.

I've discussed the differences between defects and changes. Changes follow a very similar workflow to defects, although changes usually involve financial discussions. I mentioned in Chapter 1 that it depends on the methodology but changes are often considered "a change to the signed-off requirements" and as such have more impact on budgets and timescales. When there are changes in "scope," these need to be impacted and estimated accordingly.

It is important that everyone understand and follow the change-control process. It is all too easy during development to start changing things without going through the proper channels. The change-control process is there to ensure that all changes go through the relevant process and are either approved or rejected. When approved, the changes can be scheduled into the development lifecycle and released accordingly.

Where possible, tools can and should be used to assist in the impact and estimating of changes in the same way that tools are used to impact defects. It is rare that a change will require a completely new application or architecture stack, ...