Softwareentwicklungsschmutz

Technische Schulden

4. Erscheinungsformen

Die Kategorie „Erscheinungsform“ macht deutlich, wo Technische Schulden überall vorkommen können und wie sie aussehen:

Persönliche Schulden:
– Mangelnde Motivation der Akteure Neues zu lernen, auszuprobieren und sich an Neues anzupassen
– Fehlendes Arrangement, sich „zu kümmern“ und Verantwortung zu übernehmen
– Verbesserungswürdige Haltung gegenüber Kollegen und der Kommunikation mit ihnen

Organisatorische Schulden:
– Veraltete hierarchische Organisationsstrukturen (siehe Gesetz von Conway)
– Unzureichende Hardware
– Ungünstige räumliche Aufteilung von Teams
– Mangelnde Kommunikationsmöglichkeiten für verteilte Teams

Prozess-bezogenen Schulden:
– Anwendung von veralteten Vorgehensmodellen
– Falsch verstandene Anwendung neuer Vorgehensmodelle

Praktische Schulden:
– Nicht aus gemachten Fehlern lernen
– Den vorhandenen Wissensstand veralten lassen
– Entweder zu viele (Mangelnde Flexibilität) oder zu wenige (Wildwuchs) allgemein gültige Regeln

Werkzeug-bezogene Schulden:
– Zu großer Wildwuchs an eingesetzten Werkzeugen
– Fehlende, aber benötigte Software
– Veraltete Tools

Automationsbezogene Schulden:
– Kein Continuous Integration
– Kein automatischer Bau des Releasekandidaten
– Keine automatische Installation / kein automatisches Deployment
– Keine automatische Wiederherstellung nach einem Crash
– Keine „Deployment Pipeline“ (Werkzeugkette für die Auslieferung)

Test-bezogene Schulden:
– Unzureichende Testabdeckung der implementierten Funktionalität
– Unzureichende Integrations- und Systemtests
– Fehlende oder mangelnde Testumgebung
– Unzureichende Tests der nicht funktionalen Qualitätsmerkmale (z.B. Performance- und Last-tests)
– Unzureichende Oberflächen- / Usabiliy-Tests
– Ungetestete Wiederherstellungsroutinen

Kommunikationschulden:
– Mangelnde Informationsfluss von der Fachseite
– Unklare/lückenhafte Anforderungen vom Anforderungsmanagement
– Fehlende Abstimmung mit dem Betrieb

Produktions-bezogene Schulden:
– Mangelnde Analysierbarkeit (Logging, Protokollierung, Monitoring)
– Mangelnde Flexibilität ( Hartkodierung statt Konfiguration )
– Mangelnde Update-Fähigkeit in Produktion
– Zu starke Plattformabhängigkeit
– Zu starke Ressourcenverbrauch in Produktion

Architekturschulden:
– Mangelnde Berücksichtigung nicht-funktionaler Qualitätskriterien
– Fehlende Vorgaben für querschnittliche Konzepte
– Unzureichende Architektur-Dokumentation
– Schlechte Umsetzung der gut entworfenen Architekturvorgaben
– Verwendung ungünstiger Technologien

Implementierungsschulden:
– Code-Vervielfachungen (DRY)
– Zu komplexe Lösungen (KISS)
– Unverständliche Bezeichner von Variablen, Methoden, Klassen…
– Zu starke Verschachtelung von Bedingungen
und viele, viele mehr (siehe Implementierungsregeln)

Siehe auch Beyond Technical Debt.


[ < ]       [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ]       [ > ]

Zurück


Wir freuen uns über Kommentare zu dieser Seite:

Verfassen Sie einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

*