We produce diagrams, verbose documents and lists-of-stuff till the cows come home but matrices are an all too rare; almost mythical, beast. Their power though is more real than the healing and purification properties of true Unicorn horns despite what some may say.
Here’s an example.
The diagram below shows a contrived and simplified matrix of the relationship between user stories and components. In many cases such a matrix may cross hundreds of stories and dozens of components.
Crucially we can see for a particular story which components are impacted. This provides much needed assurance to the architect that we have the needed coverage and allows us to easily see where functionality has no current solution. In this case “US4: Audit Logging”.
Adding some prioritisation (col C) allows us to see if this is going to be an immediate issue or not. In this case the product owner has (foolishly) decided auditing isn’t important...
Developers can use the matrix to see which components need implementation for a story and see what other requirements are impacted by the components they’re about to develop.
Now, it may well be that we’ll proceed and accept any technical debt associated with high-priority requirements to deliver them faster. It may also be that the lower priority requirements never get delivered, so no-problem. But it may instead be that the next story in the backlog has some particular nuanced requirement which makes things rather hairy, and is best to consider up-front rather than walk into a pit if we do it things another way. It’s a balancing game with pros and cons - the matrix provides visibility to aid the assessment which all parties can use.
And there's more (in true infomercial style)... We can also see that the “Access Gateway”, “Article Management” and “Database” components appear to cover many stories. This may be fine if the functionality they provide is consistent across requirements - for example the “Access Gateway” may simply be doing authentication and authorisation consistently - but in other cases it suggests some decomposition and refinement is needed - for example we may wish to consider breaking out “Articles” and “Comments” into two separate components which have more clearly defined responsibilities. Regardless, it helps to see that some components are going to be critical to a lot of requirements and may need more care and attention than others.
So where does this particular matrix come from? We could be accused of the near cardinal sin today of following a waterfall mentality with the need for a big up-front design phase. Not so. It’s more akin to a medical triage.
We have a backlog. We need to review the backlog and sketch out the core components required to support this. We don’t need to dig into each component in great detail - just enough to provide assurances that we have what’s needed for the priority requirements and that the requirements have enough detail to support this (basically some high level grooming). Low priority or simple requirements we may skim over (patient will live (or die)), higher priority or complex ones we assess till we can build the assurances we need (patient needs treatment).
When new requirement arise we can also quickly assess these against the matrix to see where the impact we will be.
This is just one of many useful matrices. Story-to-story can help identify requirement dependencies. Likewise for component-to-component. Mappings from logical components to infrastructure helps build a view of the required environment and can; when taken to the physical level, be used for automatic identification of things like firewall rules. You can even connect matrices together to allow for identification of which requirements are fulfilled by which servers - e.g. physical-node to logical-node to component to requirement maps - or use them for problem analysis to work out what’s broken - e.g. "this function isn’t working, which components could this relate to". Their value of course is only as good as the quality of data they hold though so such capabilities are often not realised.
Like Unicorns, matrices can be magical. Fortunately for us; and - I hate to break this to you - unlike Unicorns, matrices are real (despite what some may say!).
No comments:
Post a Comment