Technische Schulden aufgedeckt: agile Strategien für einen schuldenfreien Entwicklungszyklus

Herkömmliche Softwareprogramme basieren auf einem phasenbasierten Entwicklungsansatz: Feature-Entwicklung, Alpha, Beta und Golden Master (GM).

Jedes Release beginnt mit einer Phase, in der neue Features entwickelt und (idealerweise) restliche Probleme aus dem letzten Release behoben werden (was ehrlich gesagt nur selten der Fall ist). Der Entwicklungszyklus erreicht "Alpha", wenn alle Features implementiert und zum Testen bereit sind. Beta wird erreicht, wenn genügend Bugs behoben wurden, um ein Kundenfeedback zu ermöglichen. Leider tauchen neue Bugs auf, während das Team noch damit beschäftigt ist, genügend Bugs zu beheben, um Beta zu erreichen. Das ist ein klassisches Beispiel für einen Teufelskreis: Du behebst einen Bug und zwei weitere tauchen auf. Wenn keine Bugs mehr offen sind, erreicht das Release den Golden-Master-Meilenstein. Der Status "Keine offenen Bugs" wird normalerweise erreicht, indem einige bekannte Probleme behoben und der Rest (die meisten?) auf das nächste Release verschoben werden.

Eine ständige Aufschiebung von Bugs, die behoben werden müssen, ist eine gefährliche Art, Software zu entwickeln. Wenn die Zahl der Bugs wächst, wird es immer beängstigender – eine fiese Spirale technischer Schulden entsteht. Um das Ganze noch zu verschlimmern, entgleist auch die Zeitplanung, da ein Programmieren um die Bugs herum die Entwicklung verlangsamt. In der Zwischenzeit sterben Kunden tausend Tode aufgrund von nicht behobenen Fehlern. Und einige Kunden werden abwandern.

Es muss einen besseren Weg geben.

Bei agilen Methoden ist Qualität im iterativen Entwicklungsansatz verankert, sodass das Team von Release zu Release eine konsistente Grundqualität halten kann. Wenn ein Feature die Erwartungen nicht erfüllt, wird es nicht ausgeliefert. Schwer zu glauben? Nun, es gibt einen Trick: das Definieren oder erneute Definieren dessen, was "Erledigt" bedeutet.

Für herkömmliche Teams bedeutet "Erledigt" gut genug, um die QS-Phase zu beginnen. Das Problem an dieser Definition ist, dass sich Bugs oft in einer frühen Phase des Release-Zyklus einschleichen – und das auch weiterhin tun. Bis also das QS-Team den Code in die Finger bekommt, ist das Produkt bereits mit zahlreichen Fehlern belastet. Agile Teams definieren "Erledigt" dagegen als bereit für den Release, was bedeutet, dass Entwickler erst zur nächsten Story oder zum nächsten Feature übergehen, wenn das aktuelle Element quasi in der Hand des Kunden ist. Um die Dinge zu beschleunigen, nutzen sie Techniken wie Feature Branching Workflows, automatisierte Tests und Continuous Integration während des gesamten Entwicklungszyklus.

Der Haupt-Branch der Codebasis sollte immer zur Auslieferung bereit sein. Das ist die oberste Priorität. Neue Features beginnen also mit einem Task-Branch, der den Code für das Feature selbst und die automatisierten Tests enthält. Wenn das Feature abgeschlossen ist und die automatisierten Tests bestanden hat, kann der Branch in den Haupt-Branch gemergt werden. Da das Qualitätsniveau immer konstant (und auf einem hohen Niveau) ist, bleiben technische Schulden unter Kontrolle.

Für viele Unternehmen bedeutet das eine enorme kulturelle Änderung. Bei Agile liegt der Fokus nicht auf Zeitabläufen, sondern auf einer hochwertigen, vorführbaren Software. Der Produktinhaber kann das Team zuerst auf die wertvollsten Arbeiten lenken und dabei den Umfang des Release reduzieren, statt die Qualität zu verringern.

Eines sollten wir nicht vergessen: Je länger Bugs bestehen bleiben, umso schwieriger sind sie zu beheben.

Wenn du mit älterem Code arbeitest, hast du mit ziemlicher Sicherheit einige technische Schulden geerbt. Die folgenden Themen helfen dir, die vorhandenen Schulden im Zaum zu halten, damit sich dein Team auf Spannenderes wie die Entwicklung neuer Features konzentrieren kann.

Manchmal sind sich Entwickler und Produktmanager nicht einig, was technische Schulden sind. Diesen Streit können wir hier begraben:

Dazu zählen auch alle technischen Abkürzungen, die eingeschlagen wurden, um Liefertermine einzuhalten!

Auf der Entwicklerseite besteht die Versuchung, architekturbezogene Arbeiten als technische Schulden zu bezeichnen. Das kann je nach Beschaffenheit der Änderung der Fall sein oder auch nicht (z. B. das Ersetzen einer Abkürzung durch die "echte" Lösung im Vergleich zum Aufteilen einer monolithischen Codebasis in Mikroservices). Andererseits ist es für das Produktmanagement oft dringlicher, neue Features zu entwickeln, statt Bugs oder eine langsame Performance zu beheben. Um zu vermeiden, dass eine Seite einfach erschöpft der Meinung der anderen Seite nachgibt, müssen alle den Unterschied zwischen technischen Schulden, gewünschten architekturbezogenen Änderungen in der Codebasis und neuen Features verstehen. Für die Priorisierung des Backlogs und die Weiterentwicklung der Codebasis ist eine klare Kommunikation zwischen der Entwicklung und dem Produktmanagement unerlässlich.

Widerstehe der Versuchung, die Definition von "Erledigt" zu gefährden, indem du eine separate Testaufgabe zur ursprünglichen User Story hinzufügst. Diese wird oft aufgeschoben und führt zu weiteren technischen Schulden. Wenn das Testen nicht als Teil der ursprünglichen Story oder Fehlerbehebung erfolgt, ist die ursprüngliche Story oder Fehlerbehebung nicht erledigt. Behalte eine strenge Definition von "Erledigt" in deinem Programm bei und stelle sicher, dass diese vollständige automatisierte Tests umfasst. Nichts untergräbt die Agilität des Teams mehr als manuelle Tests und eine Codebasis voller Bugs.

Wenn jemand einen Bug in der Software entdeckt, nimm dir die Zeit, einen automatisierten Test hinzuzufügen, der diesen demonstriert. Nachdem der Bug behoben ist, führe den Test erneut durch, um sicherzugehen, dass er bestanden wird. Dies ist der Kern der testgesteuerten Entwicklung und eine altehrwürdige Methode zur Aufrechterhaltung der Qualität in der agilen Entwicklung.

Es ist nicht leicht, die Haltung des Teams (und der Stakeholder des Teams) im Umgang mit technischen Schulden zu ändern. Das Unternehmen muss manchmal die Entwicklungszeit verkürzen, um ein Produkt schneller auf den Markt zu bringen. Behalten wir das im Hinterkopf, während wir einige Aufgaben für das Eindämmen technischer Schulden wiederholen:

• Informiere den Product Owner über die wahren Kosten technischer Schulden. Stelle sicher, dass die Story-Point-Werte für geplante Storys, für die eine Auflösung vorhandener technischer Schulden erforderlich ist, präzise sind.
• Modularisiere deine Architektur und verfolge eine kompromisslose Haltung in Bezug auf technische Schulden in neuen Komponenten oder Bibliotheken in der Anwendung. Wenn das Team und das Unternehmen die Agilität in diesen neuen Komponenten sehen, werden sie diese Verfahren selbstverständlich auch auf andere Teile des Codes ausweiten wollen.
• Schreibe automatisierte Tests! Es gibt nichts, was Bugs besser verhindert, als automatisierte Tests und Continuous Integration. Wenn ein neuer Bug gefunden wird, schreibe einen neuen Test, um ihn zu reproduzieren, und behebe dann das Problem. Wenn dieser Bug jemals noch einmal auftaucht, wird der automatisierte Test ihn vor den Kunden erwischen.

Denke daran, dass technische Schulden für alle Softwareteams Realität sind. Niemand kann sie vollkommen vermeiden. Stattdessen sollte dein Schwerpunkt darauf liegen, dass sie nicht außer Kontrolle geraten.