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: