Wie bessere Developer Experience die Produktivität steigert

erstellt von Veit Schiele zuletzt geändert 2021-09-15T14:55:48+02:00

Laut State of DevOps 2021 ist in 78 Prozent der Unternehmen die Umsetzung von DevOps auf mittlerem Niveau ins Stocken geraten. Dieser Anteil ist 4 Jahren fast gleich geblieben.

Die Entwicklung von DevOps steckt auf mittlerer Ebene fest

Die überwiegende Mehrheit der Unternehmen steckt in der Entwicklung von DevOps auf mittlerer Ebene fest. In der Studie wurde die mittlere Ebene in drei Kategorien unterteilt um das Phänomen genauer zu untersuchen.

Wenig überraschend ist, dass Unternehmen, die in der DevOps-Umsetzung schon weit vorangeschritten sind, auch die meisten Abläufe automatisiert haben. In diesen Unternehmen ist auch der Top-Down-Zuspruch für den Bottom-Up-Wandel am größten (→ Top-down und Bottom-up):

Die am höchsten entwickelten Unternehmen profitieren von der Top-Down-Unterstützung der Bottom-Up-Transformation.

Weniger als 2 Prozent der Angestellten hochentwickelter Unternehmen berichten von Widerstand gegen DevOps auf Führungsebene und auch bei den mittel entwickelten Unternehmen sind es nur 3 Prozent. In ihnen geben jedoch nur 30 Prozent an, dass DevOps aktiv gefördert wird, verglichen mit 60 Prozent der hochentwickelten Unternehmen.

Eine Definition von DevOps lässt die Gründe erahnen, weswegen viele Unternehmen bei der Umsetzung steckenbleiben:

»DevOps ist die Philosophie der Vereinheitlichung von Entwicklung und Betrieb auf den Ebenen Kultur, Praxis und Tools, um eine schnellere und häufigere Bereitstellung von Änderungen in der Produktion zu erreichen.«

– Rob England: Define DevOps: What is DevOps?, 2014

Die Studie zeigt, dass DevOps-Tools zwar umfassend bereitgestellt werden, die praktische Umsetzung automatisierter Abläufe jedoch stockt und dem kulturellen Wandel Widerstand entgegenschlägt.

DevOps-Kultur

Ein wesentlicher Aspekt von DevOps-Kultur ist die gemeinsame Verantwortung für das System. Leicht verliert ein Entwicklungsteam das Interesse an Betrieb und Wartung, wenn es einem anderen Team zum Betrieb übergeben wird. Wenn jedoch das Entwicklungsteam die Verantwortung für den Betrieb eines Systems über die gesamte Lebensdauer teilt, kann es die Probleme des Betriebspersonals besser nachvollziehen und auch Wege zur Vereinfachung von Bereitstellung und Wartung finden, z.B. durch die Automatisierung von Bereitstellungen (→ Release, → Deploy, ) und verbessertes Monitoring (→ Metriken, → Incident Management, → Statusseite). Wenn umgekehrt das Betriebsteam die Verantwortung für ein System teilt, arbeiten sie enger mit dem Entwicklungsteam zusammen, das dann auch die betrieblichen Anforderungen besser versteht.

Um eine Kultur der geteilten Verantwortung zu unterstützen sind organisatorische Veränderungen erforderlich. Entwicklung und Betrieb sollten keine Silos sein. Für den Betrieb Verantwortliche sollten frühzeitig in das Entwicklungsteam eingebunden werden. Die Zusammenarbeit zwischen Entwicklung und Betrieb hilft bei der Zusammenarbeit. Übergaben und Freigaben entmutigen hingegen, behindern eine gemeinsame Verantwortung und fördern Schuldzuweisungen.

Die Schnittstelle zwischen Entwicklung und Betrieb kippt.

DevOps-Änderung

Um effektiv zusammenarbeiten zu können, müssen Entwicklungs- und Betriebsteam in der Lage sein, Entscheidungen zu treffen und Änderungen vorzunehmen. Dazu gehört Vertrauen in diese autonomen Teams, den nur dann wird sich ihr Umgang mit Risiken ändern und ein Umfeld geschaffen, das frei von Versagensängsten ist.

Um die Zusammenarbeit von Entwicklungsteam und Betriebspersonal zu fürdern und das System selbst kontinuierlich zu verbessern, ist Feedback essentiell. Dabei kann die Art des Feedbacks die Dauer und die Häufigkeit sehr unterschiedlich sein:

  • Das Überprüfen der eigenen Code-Änderungen sollte sehr häufig erfolgen und daher nur wenige Sekunden benötigen
  • Ob sich eine Komponente in alle anderen integrieren lässt, kann jedoch mehrere Stunden dauern und wird daher deutlich seltener ausgeführt werden.
  • Auch die Überprüfung von nicht-funktionale Anforderungen wie Zeitverhalten, Ressourcenverbrauch, Wartbarkeit etc. kann auch schon mal einen ganzen Tag dauern.
  • Die Antwort des Teams auf eine technische Frage sollte nicht erst nach Stunden oder gar Wochen erfolgen.
  • Die Zeit, bis neue Team-Mitglieder produktiv werden, kann Wochen oder auch Monate dauern.
  • Ein neuer Service sollte innerhalb weniger Tage produktiv werden können.
  • Fehler in Produktivsystemen zu finden ist jedoch häufig erst nach einem oder mehreren Tagen erfolgreich.
  • Eine erste Bestätigung durch die Zielgruppe, dass eine produktive Änderung angenommen wird, sollte nach wenigen Wochen möglich sein.

Dabei dürfte sich von selbst erklären, dass Feedbackschleifen häufiger durchgeführt werden wenn sie kürzer sind. Frühe und häufige Validierung wird auch die spätere Analyse und Nacharbeit reduzieren. Auch einfach zu interpretierende Feedback-Schleifen reduzieren die Aufwände erheblich.

Etsy erfasst nicht nur, ob die Verfügbarkeit und die Fehlerrate von Komponenten den eigenen Ansprüchen genügt, sondern auch in welchem Umfang eine Funktionsänderung von der Zielgruppe angenommen wird: sollte eine Änderung sich als wertlos herausstellen wird sie wieder entfernt, wodurch die technische Schulden reduziert werden können.

Developer Experience

Developer Experience (DX), die Konzepte aus der UX-Optimierung auf Erfahrungen in Entwicklungsteams anwendet, kann hier eine gute Ergänzung sein um die kulturelle Ebene besser aus Sicht des Entwicklungsteams zu erfassen. In Developer Experience: Concept and Definition unterscheiden Fabian Fagerholm und Jürgen Münch die folgenden drei Aspekte:

Aspekt Beschreibung Themen
Wahrnehmung Wie nehmen die Entwicklungsteams die Entwicklungsinfrastruktur wahr?
  • Plattform
  • Techniken
  • Prozess
  • Fähigkeit
  • Verfahren
Emotion Wie fühlen sich die Mitglieder des Entwicklungsteams bei ihrer Arbeit?
  • Respekt
  • Soziales
  • Team
  • Bindung
  • Zugehörigkeit
Motivation Wie sehen die Mitglieder des Entwicklungsteams den Wert ihres Beitrags?
  • Pläne
  • Ziele
  • Ausrichtungen
  • Absichten
  • Motivation
  • Engagement

So könnte der Tag für Mitglieder des Entwicklungsteams in einer wenig effektiven Umgebung aussehen:

  1. Der Tag beginnt mit einer Reihe von Problemen in der Produktion.
    1. Da es keine aggregierten Auswertungen gibt, wird der Fehler in verschiedenen Log-Dateien und Monitoring-Services gesucht.
    2. Schließlich wird das Problem im Auslagern des Arbeitsspeichers in eine Swap-Datei vermutet und das Betriebsteam um mehr Arbeitsspeicher gebeten.
  2. Nun ist endlich Zeit zu schauen, ob es Rückmeldungen vom QA-Team gab zu der neu implementierten Funktion.
  3. Dann ist auch schon das erste von mehreren Statusmeetings.
  4. Endlich könnte mit dem Entwickeln begonnen werden, wenn nur schon der Zugang zur erforderlichen API bereitgestellt worden wäre. Stattdessen werden nun Telefonate mit dem Team geführt, das die Zugänge für die API bereitstellt um nicht erst nach mehreren Tagen mit der Arbeit beginnen zu können.

Wir könnten noch viele weitere Blockaden aufzählen; letztendlich beenden die Mitglieder des Entwicklungsteams ihren Arbeitstag frustriert und demotiviert. Alles dauert länger als es sollte, und der Tag besteht aus nicht enden wollenden Hindernisse und Bürokratie. Die Mitglieder des Entwicklungsteams fühlen sich nicht nur ineffektiv und unproduktiv. Wenn sie diese Arbeitsweise irgendwann akzeptieren, breitet sich bei ihnen erlernte Hilflosigkeit aus.

In einer solchen Umgebung versuchen Unternehmen meist, die Produktivität zu messen und die leistungsschwächsten Team-Mitglieder zu erkennen indem sie die Anzahl der Code-Änderungen und erfolgreich bearbeiteten Tickets messen. In solchen Unternehmen werden meiner Erfahrung nach die besten Fachkräfte gehen; es gibt keinen Grund für sie, in einer ineffektiven Umgebung zu verharren, wenn innovative digitale Unternehmen nach starken technischen Talenten suchen.

Der Arbeitstag in einer hocheffektiven Arbeitsumgebung könnte hingegen so aussehen:

  1. Der Tag beginnt mit dem Blick auf das Projektmanagement-Tool des Teams, z.B. ein sog. Kanban-Board. Anschließend gibt es ein kurzes Standup-Meeting nach sich jedes Team-Mitglied im Klaren ist, woran es heute arbeiten wird.
  2. Das Team-Mitglied stellt fest, dass die Entwicklungsumgebung automatisch aktuelle Bibliotheken erhalten hat, die auch bereits in die Produktion übernommen wurden da alle CI/CD-Pipelines grün waren.
  3. Als nächstes werden die Änderungen in die eigene Entwicklungsumgebung übernommen und mit den ersten inkrementellen Code-Änderungen begonnen, die durch Komponententests schnell validiert werden können.
  4. Beim nächsten Feature wird der Zugang zur API eines Dienstes benötigt, der von einem anderen Team verantwortet wird. Der Zugang kann über ein zentrales Service-Portal beantragt werden, sich ergebende Fragen werden schnell in einem Chat-Raum beantwortet.
  5. Nun kann störungsfrei mehrere Stunden intensiv an dem neuen Feature gearbeitet werden.
  6. Nachdem das Feature implementiert und alle Komponententests bestanden wurden, wird in automatisierten Tests überprüft, ob sich die Komponente auch weiterhin in alle anderen Komponenten integriert.
  7. Sind alle Continuous-Integration-Pipelines grün, werden die Änderungen schrittweise für die vorgesehenen Zielgruppen in der Produktion freigegeben und dabei die Betriebskennzahlen überwacht.

Jedes Mitglied eines solchen Entwicklungsteams kann an einem Tag schrittweise Fortschritte machen und zufrieden mit dem Erreichten den Arbeitstag beenden. In einem solchen Arbeitsumfeld können die Arbeitsziele einfach und effizient erreicht werden und es gibt wenig Reibungsverluste. Die meiste Zeit verbringen die Team-Mitglieder damit, wertvolles zu schaffen. Produktiv zu sein motiviert die Mitglieder des Entwicklungsteams. Ohne Reibung haben sie Zeit, kreativ zu denken und sich einzusetzen. Hier konzentrieren sich die Unternehmen darauf, ein effektives technisches Umfeld bereitzustellen.

Meldet euch

Wir beraten euch gerne und erstellen ein passgenaues Angebot für eine gelingende DevOps-Transformation.

Portrait Veit Schiele
Veit Schiele
Telefon: +49 30 22430082

Ich rufe euch auch gerne zurück!

Jetzt anfragen