Neben einem schief gestapelten Turm aus alten Schichten zeigt ein gestrichelter Rahmen, wo sie bündig sitzen sollen, davor liegt das orange Spielbuch.

Report · 2.490 € netto

Tech-Debt-Audit Spielbuch

Operatives Audit-Verfahren für Mittelstand-Codebases. Inventur, Risiko-Matrix, Refactoring-Pfade, Test-Strategie nachgelagert. Das Spielbuch, mit dem Sie eine fremde oder lange ungepflegte Codebase in zwei Wochen sauber bewerten.

Worum es geht

Aus über 20 Jahren Entwicklung und Pflege von PHP-Anwendungen

Tech-Debt-Audits enden leicht als Tabelle mit 200 Zeilen „muss irgendwann mal“ und einem Refactoring-Trauma im Team. Das Spielbuch beschreibt einen anderen Weg: ein operatives Verfahren über zehn Arbeitstage, an dessen Ende eine Risiko-Matrix steht, eine Roadmap mit drei priorisierten Schritten und eine begründete Liste dessen, was Sie bewusst so lassen, weil die Sanierung teurer wäre als der Schaden.

Das Verfahren stützt sich auf über 20 Jahre Entwicklung und Pflege von PHP-Anwendungen seit 2004, auf Modernisierungen im laufenden Betrieb wie bei Cardeleine und auf die Fachliteratur von Cunningham, Fowler und Feathers. Pragmatisch, dokumentiert, mit Befehlen und Vorlagen, und ohne Abdeckungsquoten als Selbstzweck, die Mittelstands-Teams überfordern. Der durchgerechnete Beispielfall ist konstruiert, damit jede Zahl nachvollziehbar ist.

Inhaltsverzeichnis

Was im Spielbuch steht

Vorwort und Audit-Haltung

Warum Tech-Debt-Audits scheitern, welche Haltung das Verfahren voraussetzt, Begriffe und Grundlage.

Überblick

Zehn Tage, sechs Ergebnisse, wer mitmacht, was das Audit kostet und was vor Tag 1 vorbereitet sein muss.

Inventur-Phase

Tag eins bis fünf: Interviews, Plattform, Code und Hotspots aus der Git-Historie, Tests und Auslieferung, Betrieb und Daten. Mit den Befehlen und dem, was Sie in Ruhe lassen.

Risiko-Matrix

Jeder Befund auf vier Achsen: Eintrittswahrscheinlichkeit, Schaden, Sanierungsaufwand, Pflegefrequenz. Daraus Risiko, Priorität und vier Klassen, Befunde in Geld übersetzt.

Refactoring-Pfade

Welche Umbaumuster sich tragen, welche zwingend Test-Vorsorge brauchen, welche sich in bis zu fünf Personentagen umsetzen lassen, und die Fallen.

Test-Strategie nachgelagert

Tests folgen der Roadmap: Smoke-Tests, Charakterisierungstests, Gesamtvergleich. Schwellen, die das Team mitträgt, und ein Testplan je Schritt.

Entscheidungsreview

Tagesordnung für die zwei Stunden mit der Geschäftsführung, Trade-offs dokumentieren, Fragen, die gestellt werden sollten.

Übergabe-Verfahren

Wenn das Audit zur Wartungsübernahme führt: was dokumentiert sein muss, Ablauf der Übergabe, Prüfliste.

Ergebnisse vorstellen

Aufbau des Befundberichts und das Gesamturteil in drei Sätzen.

Durchgerechneter Beispielfall

Ein konstruierter Fall mit Inventur, Risiko-Matrix, Roadmap, Kosten und Entscheidung, damit jede Zahl nachvollziehbar ist. Keine anonymisierten Kundenfälle.

Vorlagen-Pack

Auftragsblatt, Befund, Risiko-Matrix, Roadmap, Entscheidungsvorlage, Entscheidungsprotokoll, Übergabeprotokoll, Plattformblatt, Tagesplan. Als Text zum Übernehmen, mit Beispiel-Eintrag.

Für wen

Für wen wir das geschrieben haben

Für Engineering-Leads, die eine fremde oder vernachlässigte Codebase übernommen haben und einen Plan brauchen. Für Geschäftsführer von Software-Häusern, die eine Wartungs-Übernahme kalkulieren müssen. Für CTOs, die ihrem Team eine Audit-Praxis geben wollen, statt jedes Quartal individuelle Migräne zu organisieren.

Nicht im Spielbuch: Versprechungen, dass nach zwei Wochen alles repariert ist. Eine Heilung gegen Legacy-Code. Eine Liste der zehn besten Analyse-Werkzeuge. Anonymisierte Kundenfälle. Sie bekommen ein Verfahren mit festem Ablauf, festen Ergebnissen, den Befehlen für die Inventur und einem vollständigen Vorlagen-Pack.

Aus dem Kapitel Risiko-Matrix

Die Achse Pflegefrequenz verhindert die teuerste Entscheidung im Audit: Code zu sanieren, den niemand mehr ändert.

Häufige Fragen

Fragen zu Tech-Debt-Audit Spielbuch

Für wen ist das Tech-Debt-Audit Spielbuch geeignet?

Das Spielbuch richtet sich an Engineering-Leads, Geschäftsführer von Software-Häusern und CTOs, die eine fremde oder vernachlässigte Codebase bewerten und einen klaren Plan für Wartung oder Übernahme brauchen. Wir haben es speziell für den Mittelstand entwickelt, um praxisnah und ohne übertriebene Testanforderungen zu arbeiten.

Wie lange dauert das Audit-Verfahren mit dem Spielbuch?

Das Verfahren ist auf zehn Arbeitstage ausgelegt, fünf für die Inventur und fünf für Bewertung, Roadmap und Entscheidung. Am Ende stehen eine Risiko-Matrix, eine Roadmap mit drei priorisierten Schritten und eine begründete Liste dessen, was bewusst so bleibt.

Was macht das Tech-Debt-Audit Spielbuch anders als herkömmliche Audits?

Statt einer Liste mit hunderten Einträgen liefert das Spielbuch ein Verfahren mit fester Dauer und festen Ergebnissen: Risiko-Matrix auf vier Achsen, Roadmap mit drei Schritten und eine begründete Liste dessen, was bleibt, wie es ist. Es stützt sich auf über 20 Jahre Entwicklung und Pflege von PHP-Anwendungen und verzichtet auf Abdeckungsquoten als Selbstzweck.

Welche Ergebnisse liefert das Audit am Ende?

Am Ende des Verfahrens stehen eine Risiko-Matrix, eine Roadmap mit drei priorisierten Refactoring-Schritten und eine ehrliche Aussage dazu, welche Bereiche besser unangetastet bleiben sollten, weil Pflege teurer wäre als der Nutzen. Wir geben damit eine klare Handlungsgrundlage für die weitere Wartung.

Wird das Spielbuch auch eine Liste der besten Analyse-Tools enthalten?

Nein, das Spielbuch verzichtet bewusst auf solche Listen. Werkzeuge kommen dort vor, wo ein Schritt der Inventur sie braucht, mit dem passenden Befehl, etwa für bekannte Sicherheitslücken, Hotspots aus der Git-Historie oder die statische Analyse mit Baseline.