In our talks, ebook and webinar on Software Operability we say that Operability is a measure of how well a software system works in production and also that the system must work well for both end-users and the Operations team.
There are many ways to address the latter and possibly the simplest and yet hardest one is to include Ops people in user stories, for the same reasons we believe that It takes two to DevOps.
We need to include Ops people in user stories so that we are specifically considering their needs as we would for any other user’s.
Software in production should not need application restarts, servers reboots, load balancers hacks, or any other of the countless fixes and workarounds that many Operations teams have to put in place in order to make some of our systems work on a daily basis.
Talk about ‘operational features’, not ‘non-functional requirements’
Many organisations use terminology which is unhelpful and counter-productive towards Operability:
- ‘features’ or ‘business requirements’ for aspects related to what the end-user experiences
- ‘non-functional requirements’ for aspects of the software which are not visible to the end-user or relate to the (apparently) dark and murky world of IT Operations
It’s clear that the term ‘non-functional’ has been problematic for software development for some time: software guru Tom Gilb is sceptical about the term ‘non-functional requirements’, (preferring ‘quality requirements’ instead, see his Are non-functional requirements functional?) and Agile expert Rachel Davies is also sceptical of the term:
“Non-functional is probably a bad name because it sounds like these requirements are intangible, simply properties of a static system.”
Applying the term ‘non-functional’ to aspects of the software invisible to end-users but essential for the Operations team is to ignore the Operations team as a valid user group, which makes no sense given the amount of time spent by them working with (or often against) the software.
on a long enough timeline the operational cost of code dwarfs the cost of writing it. yet our profession usually optimizes for the latter.
— Dietrich (@d2fn) July 3, 2014
That is, from the viewpoint of the Operations team, the way in which a component logs messages or sends data to Graphite is the very essence of functionality.
A more effective terminology is:
- ‘end-user features’ instead of functional requirements
- ‘operational features’ instead of non-functional requirements
and we should treat these two groups as essentially equally valid candidates for user stories (experts like Mike Cohn have been advocating this for some time, see his Non-functional Requirements as User Stories).