Antwort.

Historie der Frage:

Ursprünglich haben IT-Teams technische Schulden nicht immer Beachtung geschenkt und sich auf die Veröffentlichung einer minimal funktionsfähigen Lösung konzentriert. Mit zunehmender Last und Anzahl der Änderungen in den Systemen entstand jedoch der Bedarf an Formalisierung und Berücksichtigung technischer Schulden zur Gewährleistung einer nachhaltigen Entwicklung.

Problem:

Technische Schulden behindern die agile Entwicklung neuer Funktionen. Nicht identifizierte oder nicht gemanagte Schulden führen zu höheren Kosten für die Wartung, dem Auftreten von "Patch"-Lösungen und einer Verkomplizierung der Architektur. Wichtig: Wie kann ein Systemanalytiker bestehende Schulden bei der Analyse neuer Anforderungen berücksichtigen und dokumentieren?

Lösung:

Der Systemanalytiker muss:

• Potenzielle technische Schulden bei der Analyse bestehender Prozesse identifizieren, Einschränkungen und Mängel in der Dokumentation festhalten
• Aufgaben zur Beseitigung/Vereinfachung/Refaktorisierung von Schulden in den Backlog aufnehmen
• Ein Gleichgewicht zwischen der Schaffung neuer Funktionalität und der Behebung technischer Probleme finden, während er den Dialog mit Architekten und dem Entwicklungsteam aufrechterhält

Schlüsselfunktionen:

• Frühe Identifizierung und Dokumentation technischer Einschränkungen
• Aufnahme von Aufgaben zur Beseitigung von Schulden in den Gesamtplan der Produktentwicklung
• Rückblickende Analyse jeder Änderung und deren Auswirkungen auf die Systemarchitektur

Fangfragen.

Sollte man alle technischen Schulden sofort beheben, sobald sie entdeckt werden?

Nicht immer. Es ist wichtig, die Priorität nach Auswirkungen auf das Geschäft und technische Risiken zu bewerten. Manchmal wird die Beseitigung von Schulden auf einen günstigeren Zeitpunkt verschoben.

Kann ein Systemanalytiker Entscheidungen über technische Schulden eigenständig treffen, ohne mit dem Entwicklungsteam zu interagieren?

Nein, der Analyst dokumentiert und verzeichnet die Schulden, aber die Entscheidung über die Art und den Zeitpunkt der Beseitigung wird gemeinsam mit dem Architekten und dem Team getroffen.

Sollte man einen Teil der technischen Schulden in der Dokumentation "verstecken", um die Genehmigung neuer Änderungen zu beschleunigen?

Nein, es sollte ein vollständiges und aktuelles Register der Schulden und Einschränkungen vorhanden sein — das schützt das Produkt und das Team vor zukünftigen Überraschungen.

Typische Fehler und Anti-Pattern

• Ignorieren oder Unterschätzen des Umfangs technischer Schulden
• Formalisierung der Schulden nur mündlich
• Fehlende Priorisierung von Schulden nach geschäftlichen Risiken

Beispiel aus dem Leben

Negativer Fall: Der Analyst ignorierte veraltete Module des Systems und implementierte eine neue Funktion über altertümlichem Code. Später war eine Nachbearbeitung erforderlich, die aufgrund der hohen technischen Schulden problematisch umzusetzen war. Vorteile:

• Schneller Start neuer Funktionalitäten Nachteile:
• Erhöhung der Zeit und Kosten für die Nachbearbeitung des Produktes, Verkomplizierung der Tests

Positiver Fall: Der Analyst stellte eine technische Beschreibung der „Engpässe“ zusammen, stimmte einen Plan zur Refaktorisierung ab und implementierte erst nach Minimierung der Schulden ein neues Modul. Vorteile:

• Konsequente Weiterentwicklung des Produkts
• Verringerung der Anzahl von Defekten Nachteile:
• Verzögerung beim Release.