Dem schwarzen Loch technischer Schulden entkommen

//TODO (War nicht ernst gemeint!) Aber mal im Ernst: Ist es nicht qualvoll für dich, wenn du das siehst? Für uns auch! 

Dan Radigan Dan Radigan

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

Agile technische Schulden | Atlassian Agile Coach

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. 

Reduzieren technischer Schulden mithilfe agiler Methoden

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- oder Master Branch der Codebasis sollte immer zur Auslieferung bereit sein. Das ist die oberste Priorität. Neue Features beginnen also mit einem Aufgaben-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 Master gemergt werden. Da das Qualitätsniveau immer konstant (und auf einem hohen Niveau) ist, bleiben technische Schulden unter Kontrolle.

For many organizations this is a huge cultural change. With agile, the focus away from schedules and towards high-quality, demonstrable software. The product owner is empowered to focus the team on the most valuable work first, reducing the scope of the release instead of compromising on quality.

Denn wir sollten nicht vergessen: Je länger Bugs verweilen, umso schwieriger sind sie zu beheben. 

Eindämmen der Schulden deines Teams

Wenn du mit älterem Code arbeitest, hast du mit ziemlicher Sicherheit einige technische Schulden geerbt. Die folgenden Themen helfen dir, vorhandene Schulden einzudämmen und deinem Team zu ermöglichen, sich auf spannendere Dinge wie die Entwicklung neuer Features zu konzentrieren. 

Schulden definieren

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. 

Pro Tip:

Priorisiere technische Schulden bei der Sprintplanung genauso wie normale Feature-Arbeiten. Verstecke sie nicht in einem separaten Backlog oder einem Issue Tracker. 

Vorsicht bei Test-Sprints und -aufgaben

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.

Bugs wegautomatisieren

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.

Wo fängst du an?

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 – und dein Schwerpunkt sollte darauf liegen, dass sie nicht außer Kontrolle geraten. 

Up Next
Testen