Egal wie vorausschauend und umsichtig ihr die Architektur und das Design eurer Software plant, sicher musstet ihr auch schon nach einiger Zeit feststellen, dass einige Entscheidungen, die ihr getroffen habt, die Weiterentwicklung des Produktes behindern oder sogar gefährden.
Die Gründe hierfür können vielfältig sein: Rahmenbedingungen haben sich möglicherweise geändert, leistungsfähigere Technologien sind nun verfügbar oder aber die aus Zeitdruck als Kompromiss gewählte Lösung kommt immer mehr an ihre Grenzen. Diese Entwicklungslasten, allgemein auch als technische Schulden bekannt, summieren sich mit der Zeit und müssen daher irgendwann abgetragen werden, wenn man nicht mit der Produktentwicklung in einer Sackgasse enden möchte.
Doch wie lässt sich eine Schuldentilgung in den Prozess der agilen Softwareentwicklung integrieren? Repayment Stories können hier ein Weg sein, um kontinuierlich technische Schulden abzubauen und eine gleichbleibende Entwicklungsgeschwindigkeit zu sichern.
Damit der Schuldenabbau ebenbürtig zur funktionalen Weiterentwicklung des Produktes in die Releaseplanung einfließen kann, ist es naheliegend, die erforderlichen Arbeitspakete genau wie die fachlichen Anforderungen als Einträge im Backlog zu erfassen. Solche Repayment Stories lassen sich auf diese Weise einfach im Gesamtkontext der Produktentwicklung betrachten und priorisieren. Voraussetzung hierfür ist jedoch, dass für jede Repayment Story Business Value und Aufwand transparent sind. Aus diesem Grund hat es sich bewährt, die folgenden Aspekte für jede Repayment Stories zu erfassen:
Kosten
Die Aufwände für die Tilgung der Schuld sollten in der gleichen Maßeinheit wie die restlichen Backlog-Einträge – z. B. Story Points – angegeben werden, so dass diese möglichst einfach in die Sprint- und Releaseplanung einbezogen werden können. Am einfachsten geschieht dies im Zuge der Refinement-Meetings durch eine Planning-Poker-Schätzung des Entwicklerteams.
Verzinsung
Es gibt technische Schulden, die mit der Zeit weiter anwachsen. Nehmen wir beispielsweise eine Bibliothek, die nicht mehr weiterentwickelt wird und daher ausgetauscht werden muss. Solange neuer Code auf Basis dieser veralteten Komponente entwickelt wird, steigt der Aufwand für den Austausch der Bibliothek weiter an.
Geschäftsauswirkung
Ein Product Owner muss verstehen, welchen Einfluss eine technische Schuld auf sein Geschäftsmodell hat, um diese richtig beurteilen zu können. So kann beispielsweise die Entwicklungsgeschwindigkeit betroffen sein, weil Entwickler bei neuen Funktionen umständliche Workarounds implementieren müssen. Ein anderes Mal beschränkt die technische Schuld vielleicht die maximale Anzahl von Nutzern oder die Usability des Produktes. Wichtig ist dabei, die Auswirkungen möglichst konkret zu fassen und so gut es geht zu quantifizieren.
Risiken
Neben der Beeinträchtigung des Geschäftsmodells können Schulden auch Risiken für das Unternehmen mit sich bringen. Eine Bibliothek, die vom Hersteller nicht mehr weiterentwickelt wird, birgt beispielsweise die Gefahr, dass bekannte Sicherheitslücken nicht geschlossen und in der Folge durch Angreifer ausgenutzt werden. Wenn möglich, sollten Eintrittswahrscheinlichkeit und der mögliche Schaden benannt werden.
Endtermin
Es kann vorkommen, dass terminliche Vorgaben für die Schuldenbehebung existieren. Dazu gehören unter anderem gesetzliche Vorgaben, Projektmeilensteine und Supportfristen, die eingehalten werden müssen. Zusätzlich empfiehlt sich eine Risikobetrachtung für den Fall, dass der Termin nicht gehalten werden kann.
Komponenten
Für die Bewertung einer technischen Schuld kann es hilfreich sein, die betroffenen Komponenten in die Betrachtung einzubeziehen. Handelt es sich dabei um ein Kernmodul, das im aktuellen Entwicklungsfokus steht, ist der Benefit sicher höher einzuordnen, als wenn es sich um ein Randsystem handelt, das nicht mehr aktiv weiterentwickelt wird.
Dank der Repayment Stories hat der Product Owner nun die Schuldenlast seines Produktes immer im Blick und kann deren Abbau angemessen steuern und planen.
Für die notwendige Transparenz muss dabei das Entwicklerteam Sorge tragen, da das Management technischer Schulden in ihren Verantwortungsbereich fällt.
Hilfestellung hierzu und zu weiteren Aspekte der Architekturarbeit geben wir zum Beispiel in unserem Training “Software Architektur in agilen Teams”. Nehmt gern Kontakt mit uns auf oder schaut euch weiter in unserem Blog um.
Kommentare