5 Min. Lesezeit
Im zweiten Kapitel dieser Reihe – DevOps für den Erfolg – beleuchten wir die entscheidenden ersten Schritte einer DevOps-Transformationsreise. Die ersten Schritte auf jedem Transformationsweg sind oft die schwierigsten. Bei DevOps ist die Identifizierung der richtigen ersten Schritte – solcher, die sowohl wirkungsvoll als auch umsetzbar sind –, der Schlüssel zu spürbaren Fortschritten.
Viele Organisationen machen den Fehler, Best Practices blind anzuwenden, ohne ihre spezifischen Rahmenbedingungen zu berücksichtigen. Dies führt häufig zu Frustration und Ermüdung durch Misserfolge. Stattdessen ist ein strategischerer Ansatz erforderlich: einer, der Engpässe identifiziert und diese systematisch beseitigt.
Wie ermittelt man die ersten Schritte?
Ein starkes Prinzip zur Bestimmung des Startpunkts stammt aus der Forschung, die vor 30 Jahren in Das Ziel: Ein Prozess der kontinuierlichen Verbesserung von Eliyahu M. Goldratt veröffentlicht wurde. Die Idee ist einfach: Identifizieren Sie den primären Engpass – also den begrenzten Faktor, der die Leistung des Systems einschränkt. In unserem Fall wurde dies deutlich, als wir sahen, dass sich die Arbeit beim Entwicklungsteam stete. Aufgaben wurden begonnen, aber nicht fertiggestellt, und der Rückstand wuchs kontinuierlich an.
Um die Ursachen zu ergründen, führten wir ausführliche Sitzungen mit Entwicklungsteams, Tech Leads und Produktmanagern durch. Diese Gespräche brachten mehrere zentrale Probleme zutage:
- Teams übernahmen neue Aufgaben, bevor sie bestehende abgeschlossen hatten.
- Es gab keine klaren Kriterien für den Abschluss von Aufgaben – was Entwickler als „erledigt“ ansahen, wich oft von den Erwartungen der Beteiligten ab.
- Vor der Freigabe der Arbeit gab es keine objektiven Qualitätsmessungen, was zu Fehlern und Nacharbeiten führte.
- Häufige Umbesetzungen störten die Stabilität des Teams und führten zu Ineffizienzen.
Aufbau stabiler Teams
Eine der ersten Korrekturmaßnahmen bestand darin, Teams im Hinblick auf Konsistenz und Fokus neu zu strukturieren. Anstatt Personengruppen als Ad-hoc-Taskforces zu behandeln, bildeten wir stabile, langfristige Teams mit klar definierten Verantwortlichkeiten.
Die Zusammenstellung mancher Teams, wie etwa der Entwicklungsteams, gestaltete sich relativ unkompliziert. Die Organisation von Support-Teams – wie Infrastruktur, Projektmanagement, Produktmanagement und Business Analysis – erwies sich jedoch als schwieriger. Wir durchliefen mehrere Iterationen, um die richtigen Kombinationen zu finden.
Gemäß dem Prinzip des „Team-First“-Gedankens, das in Team Topologies von Matthew Skelton und Manuel Pais beschrieben wird, haben wir:
- Kleine, autonome Teams (4–7 Mitglieder) gebildet, um tiefes Fachwissen und Eigenverantwortung zu fördern.
- Abhängigkeiten zwischen Teams beseitigt, indem sichergestellt wurde, dass Personen vollständig einem einzigen Team zugeordnet sind.
- Teamstrukturen kontinuierlich angepasst, insbesondere für Supportfunktionen wie Infrastruktur und Produktmanagement, um den Arbeitsfluss zu optimieren.
Einsatz von Tools für Transparenz und Management
Sobald die Teams strukturiert waren, wechselten wir zu Azure DevOps für das Backlog- und Arbeitsmanagement. Eine einheitliche Plattform ermöglichte:
- Bessere Transparenz bei der Arbeit, damit Teams den Fortschritt nachvollziehbar verfolgen können.
- Einheitliche Definitionen von „erledigt“, um die Erwartungen fachbereichsübergreifend abzustimmen.
- Verbessertes Backlog-Management, wodurch Aufwandsausweitungen und Priorisierungskonflikte reduziert werden.
Durchsetzung objektiver Qualitätsmetriken
Um dem Problem unklarer Qualitätskriterien vor dem Markieren von Aufgaben als „bereit für den Test“ zu begegnen, haben wir ein statisches Code-Analysetool integriert, das objektive Einblicke bietet in:
- Code-Abdeckung
- Sicherheitslücken
- Code-Anomalien (Code Smells)
Wir haben zudem unsere Definition von „erledigt“ erweitert, sodass Qualitätsprüfungen nun ein obligatorischer Schritt sind, bevor Arbeitselemente als abgeschlossen markiert werden.
Verwaltung der laufenden Arbeiten (WIP)
Eine der wirkungsvollsten Änderungen war die Überwachung und Begrenzung von Work in Progress (WIP). Ein hoher WIP wies auf Engpässe hin, sodass wir Bereiche, in denen die Arbeit ins Stocken geriet, proaktiv angehen konnten.
Dieser systematische Ansatz, der auf The Goal und Team Topologies basiert, schuf das Fundament für kontinuierliche Verbesserungen, reduzierte Abhängigkeiten und steigerte die Verantwortlichkeit.
Auf unserem Weg der DevOps-Transformation war eine der wichtigsten Erkenntnisse, dass nach den ersten Verbesserungen der primäre Engpass für den Arbeitsfluss auf das Software-Design überging – genauer gesagt auf die Testbarkeit unseres Codes. Nachdem wir anfängliche Engpässe durch die Verbesserung der Teamstruktur, die Definition einer „Definition of Done“ und die Implementierung von Code-Analysen behoben hatten, stellten wir fest, dass sich die Arbeit während der Testphase stapelte. Von Scrum-Teams entwickelter Code wartete häufig in einer Warteschlange auf Tests durch die QA-Mitglieder innerhalb derselben Scrum-Teams.
Beseitigung des nächsten Engpasses: Die Testlücke
Nachdem die ersten Engpässe behoben waren, trat ein neues Problem auf: Verzögerungen beim Testen. Während die Entwicklungsaufgaben effizient vorankamen, wurden Tests zum Hindernis und verhinderten schnellere Releases. Bei der Untersuchung identifizierten wir wesentliche Herausforderungen, die den Prozess verlangsamten:
- Abhängigkeit von manuellen Tests: Die meisten Tests wurden manuell durchgeführt, was zu langsamen Feedbackschleifen und verzögerter Fehlererkennung führte.
- UI-Abhängigkeit beim Testen: Da UI-Komponenten in der Regel zuletzt fertiggestellt wurden, konnten Tests erst spät im Entwicklungszyklus beginnen.
- Mangel an proaktiver Automatisierung: Automatisierte Tests, wie Selenium-basierte UI-Tests, wurden erst nach den manuellen Tests geschrieben, was ihre Wirksamkeit bei der Validierung in frühen Phasen einschränkte.
Umstellung auf testzentrierte Ansätze
Um diesen Engpass zu beseitigen, haben wir Unit-Tests und API-Tests gegenüber UI-Tests priorisiert. Diese Umstellung erforderlich grundlegende Änderungen in der Entwicklungshaltung und im Software-Design:
Verbesserungen beim API-Testen
Um das Testen von APIs effizient zu gestalten:
- Gut definierte APIs: APIs mussten einfach, gut dokumentiert und früh in der Entwicklungsphase verfügbar sein, damit Tester proaktiv Testfälle erstellen konnten.
- Vermeidung von Datenbanken als Integrationspunkt:
- Die Nutzung von Datenbanken als Integrationspunkt zwischen Teams schuf Abhängigkeiten, die das Testen verlangsamten.
- Die Erstellung von Testfällen erforderte das Einrichten von Datenbanken mit komplexen Daten, was den Vorbereitungsaufwand erhöhte und die Möglichkeiten zur Testung verschiedener Szenarien einschränkte.
- Durch den Wechsel zur API-basierten Integration (hauptsächlich REST über HTTP und neuerdings GraphQL) haben wir die durch Datenbankabhängigkeiten verursachten Verzögerungen und Komplexitäten deutlich reduziert.
Dieser Schritt ermöglichte schnellere Fortschritte bei der Automatisierung von Testfällen für APIs, was zeigte, dass die Fokussierung auf API-First-Designs sowohl die Testbarkeit als auch die Effizienz verbesserte.
Stärkung der Unit-Testing-Praktiken
Das Testen von Programmeinheiten stellte eine größere Herausforderung dar:
- Schnelle Fortschritte, dann reines Scheinkonstrukt: Anfangs erreichten wir eine hohe Code-Abdeckung, aber Code-Reviews zeigten, dass viele dieser Tests oberflächlich waren und nur geschrieben wurden, um die Ziele bei der Abdeckung zu erfüllen. Diese Tests prüften weder sinnvolle Funktionen noch deckten sie Fehlerszenarien ab oder validierten Grenzfälle.
- Umdenken einleiten: Entwickler mussten den Wert von Unit-Tests verstehen – nicht nur zur Verbesserung der Code-Qualität, sondern auch zur Beschleunigung der Entwicklung durch das frühzeitige Erkennen von Problemen.
Herausforderungen beim Schreiben testbaren Codes
Das größte Hindernis für effektive Unit-Tests war die mangelnde Testbarkeit der Codebasis selbst. Zu den Hauptproblemen gehörten:
- Große, monolithische Funktionen.
- Eng gekoppelte Komponenten.
- Mangelhafte Trennung von Funktionsbereichen.
- Unzureichende Abstraktion.
Diese Probleme erschwerten es, einzelne Einheiten effektiv zu isolieren und zu testen. Um dem entgegenzuwirken, haben wir Folgendes getan:
- Bereitgestellte Richtlinien: Wir haben Best Practices zu folgenden Themen geteilt:
- Auswahl von Funktionen für das Unit-Testing.
- Die Refarktorisierung von Code zur Verbesserung der Testbarkeit.
- Entwurf und Einsatz von Mocks zur Erleichterung von Tests.
- Fokus auf schrittweise Verbesserungen: Entwickler wurden ermutigt, kleine, sinnvolle Änderungen vorzunehmen, um die Testbarkeit im Laufe der Zeit zu verbessern.
Fortschritte, Herausforderungen und der Weg nach vorn
Bei älteren Produkten gestaltete sich die Verbesserung der Testbarkeit aufgrund architektonischer Einschränkungen weiterhin als langwieriger Prozess. Diese Maßnahmen dienten jedoch nicht nur der Optimierung der bestehenden Codebasis – sie waren eine Investition in die Zukunft:
- Die Entwickler entwickelten bessere Gewohnheiten und verankerten die Testbarkeit fest in neuen Codebasen.
- Teams wurden eigenständiger, wodurch die Abhängigkeit von externen QA-Aktivitäten verringert wurde.
- Das Unternehmen vermied es, vergangene Fehler zu wiederholen, und stellte sicher, dass zukünftige Produkte einfacher zu warten und weiterzuentwickeln sind.
Die wichtigste Erkenntnis? Bei DevOps geht es nicht darum, Tools oder Checklisten einzuführen. Es geht darum, den Arbeitsfluss kontinuierlich zu verbessern – einen Engpass nach dem anderen.
Im nächsten Kapitel dieser Reihe widmen wir uns dem Thema „Design für Testbarkeit“. Wir gehen genauer darauf ein, wie eine verbesserte Softwarearchitektur Testengpässe beseitigen kann, um schnellere Feedbackschleifen und eine höhere Softwarequalität zu ermöglichen – zunächst in den Teamstrukturen, dann im Workflow-Management und schließlich bei der Testbarkeit legen wir den Grundstein für eine nachhaltige DevOps-Transformation.
