© DrHitch/Shutterstock.com
Shortcuts
Technische Schulden

2 Strategien für die Softwareentwicklung

In der Softwareentwicklung gibt es zwei wesentliche Erfolgsfaktoren: Flexibilität hinsichtlich neuer Anforderungen - was sehr häufig gleichbedeutend mit Veränderbarkeit ist - und Behandelbarkeit von Unsicherheit im Softwareprojektmanagement. Ohne Kenntnis oder Kontrolle werden diese Erfolgsfaktoren zu Risiken. Das Management technischer Schulden nimmt sich dieser Risiken an.

Shortcut Autorenteam


Im vorigen Kapitel [1] habe ich erklärt, was technische Schulden sind und ein Modell beschrieben, mit dem sie sich systematisch hinsichtlich Ursachen, Eigenschaften und Auswirkungen beschreiben lassen. Typisiert werden technische Schulden anhand der Phase des Softwarelebenszyklus, in der sie entstehen, der konkreten messbaren Ausprägung und weiterer Attribute. Jeder Typ einer technischen Schuld wird in einem individuellen Steckbrief beschrieben. Ein erweiterbarer hierarchischer Katalog enthält alle bekannten Steckbriefe und dient als Orientierung bei der Dokumentation technischer Schulden. Zusätzlich zu dieser Beschreibung habe ich einen abstrakten Workflow vorgestellt, mit dem sich technische Schulden kontinuierlich managen lassen (Abb. 2.1).Das Ziel des Managements technischer Schulden und somit dieses Workflows liegt in der Sicherstellung der Erfolgsfaktoren Veränderbarkeit und Behandelbarkeit von Unsicherheit. Der Workflow soll zu geeigneten Zeitpunkten für einen belastbaren und eindeutigen Überblick über vorhandene technische Schulden sorgen. Nach der Bewertung kann somit dem Business eine Entscheidungsgrundlage zur Priorisierung vorgelegt werden, um grünes Licht für geschäftskritische softwaretechnische Maßnahmen (z. B. Refactorings) zu erhalten. Dazu ist es erforderlich, das Management technischer Schulden als Querschnittsfunktion im Softwarelebenszyklus zu installieren.Abbildung 2.1 schildert die drei Schritte des Managements technischer Schulden, die in dieser Reihenfolge kontinuierlich ausgeführt und im Folgenden abstrakt beschrieben werden. Während der Implementierungsphase, die meist den Fokus auf Vervollständigung und Erweiterung von Features legt, werden ermittelte technische Schulden in einem Technical Backlog gesammelt. Um die Einführung möglichst reibungsarm, also zeiteffizient zu gestalten, wird der Dokumentationsaufwand an dieser Stelle auf ein nötiges Minimum an erforderlichen Informationen beschränkt. Auf Basis des Katalogs und der Steckbriefe erfolgt dies standardisiert, systematisch und nach Möglichkeit teilautomatisiert.Während eines begrenzten und eigens dazu bereitgestellten Zeitraums werden die in Schritt 1 im Technical Backlog dokumentierten technischen Schulden gepflegt und bewertet. Die Pflege bezeichnet dabei die Verfeinerung von und Ergänzung um Informationen, die für eine aussagekräftige Bewertung erforderlich sind. In Schritt 3 erfolgt auf Basis der Bewertung die Einplanung von Tilgungsmaßnahmen für die bewerteten techn...

Shortcuts
Technische Schulden

2 Strategien für die Softwareentwicklung

In der Softwareentwicklung gibt es zwei wesentliche Erfolgsfaktoren: Flexibilität hinsichtlich neuer Anforderungen - was sehr häufig gleichbedeutend mit Veränderbarkeit ist - und Behandelbarkeit von Unsicherheit im Softwareprojektmanagement. Ohne Kenntnis oder Kontrolle werden diese Erfolgsfaktoren zu Risiken. Das Management technischer Schulden nimmt sich dieser Risiken an.

Shortcut Autorenteam


Im vorigen Kapitel [1] habe ich erklärt, was technische Schulden sind und ein Modell beschrieben, mit dem sie sich systematisch hinsichtlich Ursachen, Eigenschaften und Auswirkungen beschreiben lassen. Typisiert werden technische Schulden anhand der Phase des Softwarelebenszyklus, in der sie entstehen, der konkreten messbaren Ausprägung und weiterer Attribute. Jeder Typ einer technischen Schuld wird in einem individuellen Steckbrief beschrieben. Ein erweiterbarer hierarchischer Katalog enthält alle bekannten Steckbriefe und dient als Orientierung bei der Dokumentation technischer Schulden. Zusätzlich zu dieser Beschreibung habe ich einen abstrakten Workflow vorgestellt, mit dem sich technische Schulden kontinuierlich managen lassen (Abb. 2.1).Das Ziel des Managements technischer Schulden und somit dieses Workflows liegt in der Sicherstellung der Erfolgsfaktoren Veränderbarkeit und Behandelbarkeit von Unsicherheit. Der Workflow soll zu geeigneten Zeitpunkten für einen belastbaren und eindeutigen Überblick über vorhandene technische Schulden sorgen. Nach der Bewertung kann somit dem Business eine Entscheidungsgrundlage zur Priorisierung vorgelegt werden, um grünes Licht für geschäftskritische softwaretechnische Maßnahmen (z. B. Refactorings) zu erhalten. Dazu ist es erforderlich, das Management technischer Schulden als Querschnittsfunktion im Softwarelebenszyklus zu installieren.Abbildung 2.1 schildert die drei Schritte des Managements technischer Schulden, die in dieser Reihenfolge kontinuierlich ausgeführt und im Folgenden abstrakt beschrieben werden. Während der Implementierungsphase, die meist den Fokus auf Vervollständigung und Erweiterung von Features legt, werden ermittelte technische Schulden in einem Technical Backlog gesammelt. Um die Einführung möglichst reibungsarm, also zeiteffizient zu gestalten, wird der Dokumentationsaufwand an dieser Stelle auf ein nötiges Minimum an erforderlichen Informationen beschränkt. Auf Basis des Katalogs und der Steckbriefe erfolgt dies standardisiert, systematisch und nach Möglichkeit teilautomatisiert.Während eines begrenzten und eigens dazu bereitgestellten Zeitraums werden die in Schritt 1 im Technical Backlog dokumentierten technischen Schulden gepflegt und bewertet. Die Pflege bezeichnet dabei die Verfeinerung von und Ergänzung um Informationen, die für eine aussagekräftige Bewertung erforderlich sind. In Schritt 3 erfolgt auf Basis der Bewertung die Einplanung von Tilgungsmaßnahmen für die bewerteten techn...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang