SW-Qualität in PHP-Projekten | Testbasierte Entwicklung verkaufen [04]

Technische Schulden nehmen Software-Teams vorwiegend unter Zeitdruck auf. Gerade zum Projektende hin ist die Bereitschaft groß, schnell Funktionalität bereitzustellen, um das fachliche Projektziel zu erreichen. Hat sich das Software-Team nicht gemeinschaftlich auf ein bestimmtes Qualitätsniveau geeinigt, so fallen die Qualitätsansprüche unter dem Zeitdruck in sich zusammen.

 

Ein testbasiertes Vorgehen, vor allem das Erstellen von Unit-Tests, zwingt das Software- Team, sauberen Code zu entwickeln. Die entwickelten Klassen werden mit wenigen Abhängigkeiten definiert und mit klaren Verantwortlichkeiten versehen. Entsprechend werden alle Methoden möglichst kurz formuliert. Auch unter Zeitdruck wird das Software-Team ein Mindestmaß dieser Ansprüche realisieren.

 

Damit ist die testbasierte Entwicklung ein Weg, um die technischen Schulden des Projekts nicht zu hoch werden zu lassen. Wie bereits erwähnt, wurde der Begriff „technische Schulden“ von Ward Cunningham geprägt [Cunningham 1992]:

„Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite [...] The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation[...]“

Eine perfekte Software gibt es nicht. Eine Form technischer Schuld besteht immer. Und die Bemessungsgrundlage für technische Schulden kann sich genauso wie die Bemessungsgrundlage von interner und externer Qualität mit wechselnden Anforderungen ändern.

 

Unter Zeitdruck bewusst auf die testbasierte Entwicklung zu verzichten beziehungsweise den Umfang dieser Arbeiten zu reduzieren, heißt, bewusst technische Schulden aufzunehmen. Sind dem Team die Vorteile (zum Beispiel die wirtschaftlichen Kennzahlen der unter diesen Bedingungen erstellten Funktionen) bekannt, können die technischen Schulden gegen die wirtschaftliche Leistung verrechnet werden. Das Team kann bestimmen, ob sich eine Nachimplementierung rechnet – oder auch nicht. Es empfiehlt sich, technische Schulden gegenüber dem Auftraggeber beziehungsweise der Auftraggeberin zu benennen. Dies kann über eine Methode wie die Architecture Trade-Off Analysis Method (ATAM) (siehe Teil 5) oder durch eine monetäre Bewertung von Risikoszenarien (siehe Teil 6) erfolgen.

 

Genauso wie vielen die Betriebs- und Wartungskosten für Software nicht bewusst sind, ist diesen auch nicht klar, welche Einschränkungen und Risiken sich durch das Aufnehmen technischer Schulden ergeben. Technische Schulden sind zunächst eine abstrakte Metapher. Überführt das Software-Team technische Schulden in konkrete Risiken, werden diese nachvollziehbar für die Auftraggeber beziehungsweise die Auftraggeberin.

 

Während des Projektverlaufs sollte das Software-Team alle Risiken erfassen und das Wissen mit dem Auftraggeber beziehungsweise der Auftraggeberin teilen. Mit dieser Transparenz teilen sich die Projektparteien die Verantwortung für diese Risiken – und haben einen Ge- sprächsanlass zum Umgang mit diesen.

Die fachliche Dringlichkeit wird mit einem Wert von 1 bis 10 belegt. Je kleiner die Zahl ist, desto geringer ist die wirtschaftliche Bedeutung, das heißt, desto geringer ist der Beitrag zur Einlösung der Geschäftsziele. Die technischen Schulden werden ebenfalls mit einer Zahl von 1 bis 10 bewertet, wobei eine 10 für einen sehr hohen Aufwand zur Auflösung der technischen Schulden steht. Die Priorität ergibt sich durch Summierung dieser beiden Kennzahlen. Als Handlungsalternativen zum Umgang mit den Fällen empfehlen sich:

• Refactoring während des laufenden Projekts

• Beobachtung im Regelbetrieb

• Refactoring im Regelbetrieb