Bewertung technischer Schulden für Engineering-Teams

Bewerten Sie, wo technische Schulden Ihr Team bremsen und ob Sie sie abbauen.

Testen Sie diesen Gesundheitscheck live

Was misst eine Bewertung technischer Schulden?

Ward Cunningham prägte die Metapher der technischen Schulden in seinem Erfahrungsbericht auf der OOPSLA 1992. Darin schrieb er: „Code zum ersten Mal auszuliefern ist, als würde man Schulden aufnehmen.“ Ein paar Schulden können Sie schneller machen. Problematisch wird es, wenn sie nicht zurückgezahlt werden und jede Stunde, die Sie damit verbringen, nicht ganz richtigen Code zu umgehen, zu Zinsen wird. Code-Scanner messen den Code. Diese Bewertung misst, womit das Team im Alltag lebt: ob Sie die Schulden sehen, wie stark sie die Auslieferung bremsen, wie gesund sich Code und Systeme anfühlen und ob Sie sie abbauen. Alle bewerten jede Aussage für sich, anschließend nehmen Sie die niedrigsten Werte mit in eine Retrospektive und einigen sich darauf, was zuerst behoben wird.

Abmessungen

Sichtbarkeit

Ob das Team weiß, wo seine Schulden liegen, und sie als echte Arbeit behandelt.

  • Bekannte Hotspots

    Wir wissen, welche Teile unseres Systems die meisten Schulden tragen.

  • Zusammen mit anderer Arbeit erfasst

    Schulden werden im selben Backlog erfasst wie Features und Bugs.

  • Bekannte Kosten

    Wir können erklären, was uns unsere größten Schulden an Zeit oder Risiko kosten.

Auswirkungen auf die Auslieferung

Wie stark Schulden die Arbeit bremsen, die das Team ausliefern möchte.

  • Feature-Tempo

    Schulden bremsen die Features, an denen wir arbeiten, nur selten aus.

  • Sichere Änderungen

    Eine Änderung an einem Teil unseres Systems macht selten einen anderen, unabhängigen Teil kaputt.

  • Schnelle, zuverlässige Builds

    Unsere Builds und Tests sind schnell und zuverlässig.

Zustand von Code und Systemen

Wie leicht sich heute mit Code, Systemen und Abhängigkeiten arbeiten lässt.

  • Leicht änderbar

    Der Großteil unseres Codes ist leicht zu verstehen und zu ändern.

  • Aktuelle Abhängigkeiten

    Unsere Abhängigkeiten und Plattformen sind einigermaßen aktuell.

  • Tests ermöglichen Refactoring

    Unsere Tests geben uns die Sicherheit, Refactorings vorzunehmen.

Schuldenabbau

Ob das Team stetige, abgestimmte Fortschritte beim Abbau von Schulden macht.

  • Fest eingeplante Zeit

    Wir planen regelmäßig Zeit für den Abbau von Schulden ein.

  • Bewusste Schulden dokumentiert

    Wenn wir bewusst Schulden aufnehmen, dokumentieren wir sie zusammen mit einem Plan zur Rückzahlung.

  • Gemeinsame Prioritäten

    Produkt und Engineering sind sich einig, wie die Zeit zwischen Features und Schulden aufgeteilt wird.

Wann sollte dieser Gesundheitscheck durchgeführt werden?

  • Wenn Features länger dauern, als sie sollten, und das Team immer wieder auf die Codebasis verweist.
  • Vor der Quartals- oder Roadmap-Planung, um festzulegen, wie viel Zeit in den Abbau von Schulden fließt.
  • Nach einem großen Kraftakt oder einer harten Deadline, um die genommenen Abkürzungen festzuhalten, bevor sie in Vergessenheit geraten.

Tipps und Tricks

  • Lesen Sie zuerst die Gruppe mit den niedrigsten Werten. Geringe Sichtbarkeit bedeutet, dass Sie vor allem anderen eine Liste Ihrer Schulden brauchen. Hohe Sichtbarkeit bei geringem Abbau deutet auf ein Planungsproblem hin, nicht auf ein Codeproblem.
  • Beziehen Sie Ihre Produktmanagerin oder Ihren Produktmanager in die Diskussion ein, auch wenn nur Entwickler bewerten. Wie die Zeit zwischen Features und Schulden aufgeteilt wird, ist eine gemeinsame Entscheidung.
  • Kombinieren Sie die Werte mit Daten, die Sie bereits haben, etwa Build-Zeiten, die Anzahl instabiler Tests oder Ursachen von Incidents. Die Bewertung zeigt, wo es wehtut; die Daten zeigen, wie sehr.
  • Führen Sie sie zusammen mit der Selbstbewertung der DORA-Metriken, der DevOps-Reifegradbewertung oder dem Reifegradmodell für Engineering Excellence durch, um zu sehen, wie Schulden mit Auslieferung und Engineering-Praxis zusammenhängen.
  • Wiederholen Sie die Bewertung jedes Quartal. Steigende Werte bei den Aussagen zum Schuldenabbau sind das früheste Zeichen dafür, dass Ihr Plan funktioniert.

Häufig gestellte Fragen

Wie misst man technische Schulden?
Es gibt keine einzelne Kennzahl. Teams kombinieren Code-Metriken wie Komplexität, Churn und Testabdeckung mit Signalen aus der Auslieferung, etwa Build-Zeiten, fehlgeschlagenen Änderungen und der Dauer von Features. Eine Teambewertung wie diese ergänzt, was Tools übersehen: wo die Schulden die Menschen tatsächlich ausbremsen. Verfolgen Sie dieselben Messgrößen über die Zeit, statt einer perfekten Zahl hinterherzujagen.
Welche vier Arten technischer Schulden gibt es?
Die bekannteste Einteilung ist Martin Fowlers Technical Debt Quadrant. Er ordnet Schulden anhand zweier Fragen ein: Wurden sie bewusst oder unbeabsichtigt aufgenommen, und war die Entscheidung umsichtig oder leichtsinnig? Umsichtige, bewusste Schulden sind ein bekannter Kompromiss mit einem Plan zur Rückzahlung, während leichtsinnige Schulden sich meist unbemerkt anhäufen.
Wie viel Zeit sollten wir in technische Schulden investieren?
Eine Standardantwort gibt es nicht. Manche Teams reservieren einen festen Anteil jedes Sprints, manche planen regelmäßige Aufräumarbeiten ein, und andere beheben Schulden in dem Code, den sie ohnehin gerade ändern. Legen Sie einen Umfang fest, machen Sie ihn in der Planung sichtbar und führen Sie diese Bewertung jedes Quartal durch, um zu prüfen, ob er ausreicht.
Wie erklärt man technische Schulden gegenüber Produktmanagern?
Sprechen Sie über die Zinsen, nicht über den Code. Zeigen Sie, wie Schulden bestimmte Features verlangsamen, Incidents verursachen oder Schätzungen unzuverlässiger machen, und was ihre Behebung freisetzen würde. Es hilft, diese Bewertung gemeinsam mit dem Produktmanagement durchzuführen, denn so sehen beide Seiten dieselben Werte und können sich darauf einigen, was zuerst behoben wird.
Was ist ein Beispiel für technische Schulden?
Ein Team kopiert ein Modul, um eine Deadline zu halten, und plant, die Kopien später zusammenzuführen. Monate später muss jede Korrektur doppelt vorgenommen werden, und die Kopien haben sich auseinanderentwickelt. Weitere häufige Beispiele sind veraltete Abhängigkeiten, fehlende Tests für kritischen Code und ein langsamer Build, um den alle herumarbeiten.
Wer hat den Begriff technische Schulden geprägt?
Ward Cunningham führte die Metapher 1992 in einem Erfahrungsbericht auf der OOPSLA über das Portfoliomanagementsystem WyCash ein. Er schrieb, Code zum ersten Mal auszuliefern sei, als würde man Schulden aufnehmen, und die Gefahr entstehe, wenn die Schulden nicht zurückgezahlt werden. TeamRetro steht in keiner Verbindung zu Ward Cunningham.

Based on Ward Cunningham, 'The WyCash Portfolio Management System,' OOPSLA '92 Experience Report (1992).

Verwandte Gesundheitsuntersuchungen