I apply 100% of my effort into the bug detection, because of that I will not improve, and I repeat manually operations continuously because I need to be quick and I have no time to automate. Actually there's a lack of improvement goals.
If you ask for a bad quality metric, right now, everybody will point to the opened issues numbers, but in fact is something easily measurable and is easier to measure than the improvement in the process.
The improvement can be measured, is just more complex.
But that could be really useful is to be able to identify an indicator concern the level of "Continuos Maintenance" of the process. For instance:
- Number of issues detected in the release candidates
- Bugfixing time
- Issues distribution per phase
- Issues distribution per component
Those numbers measured in the time line and comparing with historical data can give us the clue. Ideally when you apply a model to a process you're looking for the predictability of it, but if it's 100% predictable...does it mean that is in "Continuos Maintenance" mode?, maybe we're not improving enough.
To summarize: if we've reach our full capacity, next step is improve that, and in the meanwhile maybe we decrease a bit the quality perceived, but without any internal investment we'll not be able to support changes... so keep some coins for the improvement
