Qualitätsinvestitionen statt technischer Schulden
Seite 2: Qualitätsinvestition
Qualitätsinvestitionen: Die neue Metapher
Die Metapher der Qualitätsinvestition denkt die technischen Schulden weiter. Dies sind die Kosten, die zur Behebung von Qualitätsmängeln aufzubringen sind. Die Qualitätsinvestition ermöglicht es, aus diesen Kosten einen Nutzen abzuschätzen, was letztlich in einem Gewinn resultiert.
Die SQALE-Methode (Software Quality Assessment based on Lifecycle Expectations), ein Qualitätsmodell, formuliert zwei Kostenarten: Sanierungskosten (RC, engl. remediation cost) und Nichtsanierungskosten (NRC, engl. non-remediation costs). Erstere fallen an, wenn ein Qualitätsmangel behoben wird. Sie sind mit den technischen Schulden gleichzusetzen. Im Gegensatz dazu treten die Nichtsanierungskosten auf, wenn ein Qualitätsmangel nicht behoben wird – man also mit der schlechten Qualität weiterarbeitet. Bisherige Implementierungen wie das SQALE-Plug-in von SonarQube nutzen lediglich die Sanierungskosten. Dabei liegt der Schlüssel für einen ökonomisch sinnvollen Umgang mit der Qualität in beiden Kostenarten.
Räumt man den Code auf und behebt die Qualitätsmängel, werden die Sanierungskosten fällig. Allerdings spart sich das Team dann die Nichtsanierungskosten. Demnach lohnt es sich, nur dort die Qualität zu verbessern, wo die Nichtsanierungs- größer als die Sanierungskosten sind. Denn dann ergibt die Investition in die Qualität einen Gewinn. Das lässt sich mit dieser Formel einfach beschreiben:
Gewinn = NRC – RC
Immer wenn das Beheben eines Qualitätsmangels günstiger ist, als mit ihm zu leben, lohnt sich eine Investition in die Qualität. Wie erwähnt, gewinnt die Qualität erst an Bedeutung, wenn der Code geändert wird. Das heißt für die gezeigte Gewinnrechnung, dass die Nichtsanierungskosten nur auftreten, wenn der Code in Zukunft angefasst wird. Denn nur dann wird das Team durch die schlechtere Qualität langsamer. Also ist für die Investitionsbetrachtung neben den beiden Kostenarten zusätzlich die Änderungswahrscheinlichkeit des betrachteten Codes zu schätzen. Daher lässt sich die Metapher der Qualitätsinvestition mit drei Schätzungen umsetzen. Ein Beispiel mag das verdeutlichen.
Ein fiktives System besteht aus drei Komponenten – beispielsweise für die Verwaltung von Kunden, von Bestellungen und des Lagers. Die Kundenverwaltung ist sehr alt und wird nicht mehr weiterentwickelt. Für eine Qualitätsinvestition ist diese Komponente also mit einem Verlust behaftet, da die Nichtsanierungskosten mit einer Wahrscheinlichkeit von 0 Prozent eintreten.
Bei den Komponenten für Lager und Bestellungen sieht das jedoch anders aus. Es ist bekannt, dass in der nächsten Iteration umfangreiche Änderungen an dem Bestellprozess vorgenommen werden. Ebenso ist aufgrund der Erfahrung mit der Weiterentwicklung des Systems bekannt, dass Änderungen an dem Bestellsystem mit einer geringen Wahrscheinlichkeit Änderungen am Lagersystem bewirken. Daher ist für das Bestellsystem anzunehmen, dass größere Teile des Codes geändert werden, während beim Lagersystem zwar auch Änderungen vorgenommen werden, aber nicht im gleichen Umfang. Solche groben Schätzungen sind meistens ausreichend, und es ist auch einfacher, sich auf einen solchen Wert zu einigen. Die Erfahrung lehrt, dass feingranularere Schätzungen meist nur eine Präzision vortäuschen.
In einem weiteren Schritt sind die Qualitätsmängel in diesen beiden Komponenten zu schätzen. Da wäre zum Beispiel die unterirdische Testabdeckung im Bestell- oder die enge Kopplung von Klassen im Lagersystem. Für alle auffallenden Punkte werden jeweils Sanierungs- und Nichtsanierungskosten geschätzt. Letztlich ergeben sich die Nichtsanierungskosten als die Differenz zwischen einer Schätzung des Implementierungsaufwands mit und ohne die betrachtete Qualitätsinvestition. Dabei gilt es, die Änderungswahrscheinlichkeit in die Betrachtung mit einzubeziehen. Die Nichtsanierungskosten sind im Bestellsystem nicht nur besonders hoch, weil die Qualität dort so schlecht ist, sondern auch, weil umfangreiche Änderungen vorzunehmen sind:
- Bestellsystem: geringe Testabdeckung, RC: 3d, NRC: 5d
- Lagersystem:, enge Kopplung, RC: 2d, NRC: 2d
Es ergibt sich also für das Bestellsystem ein Gewinn von zwei Tagen (= 5d-3d), während beim Lagersystem kein Gewinn zu erwarten ist. Damit ist klar, dass derzeit eine Investition ins Bestellsystem sinnvoll ist, da das Verbessern der Testabdeckung nach Schätzungen des Teams einen Gewinn verspricht. Gleichzeitig ist die Investition in das Lagersystem ökonomisch nicht sinnvoll – wenn aber für die nächsten Iterationen auch Änderungen in dieser Komponente absehbar sind, könnte es dennoch sinnvoll sein, die Qualität hier zu verbessern. In so einem Fall kann der Planungshorizont für die Qualitätsinvestitionen größer sein als der für die Features, was die Abwägungen erschwert.
Ist der Gewinn ermittelt, lässt sich daraus der Return on Investment berechnen, eine Kenngröße aus der Finanzwelt, die angibt, wie viel Gewinn im Verhältnis zum Mitteleinsatz erwirtschaftet wird. Dafür ist der Gewinn durch die Sanierungskosten zu dividieren. Für die Qualitätsinvestition im Bestellsystem bei diesem Beispiel ist das ein ROI von rund 67 Prozent (=2d/3d). Mit dieser Zahl kann man dem Manager den Nutzen einer Investition in die Qualität vor Augen führen.
Die Metapher der Qualitätsinvestition ermöglicht eine andere Art der Diskussion mit dem Management. Statt eines Kostenwerts für die technischen Schulden lässt sich dem Manager mitteilen, dass das Aufräumen einer Komponente absehbar Zeit und Aufwand einspart. Für den Manager bedeutet das eine Win-Win-Situation: Budget wird eingespart, und die Entwickler sind zufrieden, da sie die Codequalität verbessern können. Ebenso kann der Manager abwägen, ob die Investition sinnvoll ist oder beispielsweise eine "Quick & Dirty"-Entwicklung ausreicht oder vielleicht sogar wegen des Time-to-Markets notwendig ist.
Letztlich ist die Qualitätsinvestition eine Abwägung unterschiedlicher Schätzungen, was ökonomisch am sinnvollsten ist. Es stellt sich jedoch die Frage, warum die Softwareentwickler den Gedanken einer Investition nicht schon viel mehr nutzen. Investitionsrechnungen sind keine neue Erfindung, und Software ist ein Asset, in das Geld investiert wurde. In diesem Zusammenhang davon zu sprechen, dass Schulden entstehen, mutet eigentlich seltsam an.
