Wie bessere Developer-Experience die Produktivität steigert

Veit Schiele

13. Oktober 2021

10–12 Minuten

Laut State of DevOps 2021 ist die DevOps-Implementierung in 78 Prozent der Unternehmen auf einem mittleren Niveau festgefahren. Dieser Prozentsatz ist seit 4 Jahren fast gleich geblieben.

Die überwiegende Mehrheit der Unternehmen befindet sich in der DevOps-Entwicklung auf mittlerem Niveau. In der Studie wurde das mittlere Niveau in drei Kategorien unterteilt, um das Phänomen genauer zu untersuchen.

Es überrascht nicht, dass die Unternehmen, die bei der DevOps-Implementierung bereits weit fortgeschritten sind, auch die meisten Prozesse automatisiert haben. Diese Unternehmen haben auch die meiste Top-down-Unterstützung für den Bottom-up-Wandel (→ Top-Down- und Bottom-Up-Design):

Weniger als 2 Prozent der Mitarbeitenden in hochentwickelten Unternehmen berichten über Widerstand gegen DevOps auf der Führungsebene, und auch in Unternehmen mit mittlerem Entwicklungsstand sind es nur 3 Prozent. Allerdings geben nur 30 Prozent an, dass DevOps aktiv gefördert wird, verglichen mit 60 Prozent der hoch entwickelten Unternehmen.

Eine Definition von DevOps deutet auf die Gründe hin, warum viele Unternehmen in der Umsetzung stecken bleiben:

DevOps ist die Philosophie der Vereinheitlichung von Entwicklung und Betrieb auf den Ebenen von 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

Ein wichtiger Aspekt der DevOps-Kultur ist die gemeinsame Verantwortung für das System. Ein Entwicklungsteam kann leicht das Interesse an Betrieb und Wartung verlieren, wenn es die Verantwortung an ein anderes Team abgibt. Wenn das Entwicklungsteam jedoch die Verantwortung für den Betrieb eines Systems während seines gesamten Lebenszyklus teilt, kann es die Probleme des Betriebsteams besser verstehen und auch Wege finden, die Bereitstellung und Wartung zu vereinfachen, z.B. durch die Automatisierung von Bereitstellungen (→ Release, → Deploy) und die Verbesserung der Überwachung (→ Metriken, → Incident Management, → Statusseite, ). Umgekehrt arbeitet das Betriebsteam, wenn es die Verantwortung für ein System teilt, enger mit dem Entwicklungsteam zusammen, das dann ein besseres Verständnis der betrieblichen Anforderungen hat.

DevOps-Veränderungen

Organisatorische Änderungen sind erforderlich, um eine Kultur der gemeinsamen Verantwortung zu fördern. Entwicklung und Betrieb sollten keine Silos sein. Die für den Betrieb Verantwortlichen sollten frühzeitig in das Entwicklungsteam eingebunden werden. Die Zusammenarbeit zwischen Entwicklung und Betrieb hilft bei der Kooperation. Übergaben und Freigaben hingegen sind entmutigend, behindern die gemeinsame Verantwortung und fördern Schuldzuweisungen.

Um effektiv zusammenzuarbeiten, müssen die Entwicklungs- und Betriebsteams in der Lage sein, Entscheidungen zu treffen und Änderungen vorzunehmen. Dies setzt Vertrauen in diese autonomen Teams voraus, denn nur dann wird sich ihre Herangehensweise an Risiken ändern und ein Umfeld entstehen, das frei von Versagensängsten ist.

Feedback ist unerlässlich, um die Zusammenarbeit zwischen dem Entwicklungsteam und dem Betriebspersonal zu fördern und das System selbst kontinuierlich zu verbessern. Die Art des Feedbacks kann in Dauer und Häufigkeit sehr unterschiedlich sein:

• Die Überprüfung der eigenen Codeänderungen sollte sehr häufig erfolgen und daher nur wenige Sekunden dauern.

• Die Prüfung, ob eine Komponente mit allen anderen integriert werden kann, kann hingegen mehrere Stunden dauern und wird daher viel seltener durchgeführt.

• Die Prüfung nichtfunktionaler Anforderungen wie Zeitplanung, Ressourcenverbrauch, Wartbarkeit usw. kann auch einen ganzen Tag in Anspruch nehmen.

• Die Antwort des Teams auf eine technische Frage sollte nicht Stunden oder gar Wochen dauern.

• Die Zeit, bis neue Teammitglieder produktiv werden, kann Wochen oder sogar Monate dauern.

• Bis ein neuer Dienst produktiv werden kann, sollte innerhalb weniger Tage möglich sein.

• Das Auffinden von Fehlern in produktiven Systemen gelingt jedoch oft erst nach einem oder mehreren Tagen.

• Eine erste Bestätigung durch die Zielgruppe, dass eine Änderung in der Produktion akzeptiert wird, sollte nach einigen Wochen möglich sein.

Es sollte selbsterklärend sein, dass Feedbackschleifen häufiger durchgeführt werden, wenn sie kürzer sind. Eine frühzeitige und häufige Validierung reduziert auch die spätere Analyse und Nacharbeit. Einfach zu interpretierende Feedback-Schleifen reduzieren den Aufwand ebenfalls erheblich.

Etsy erfasst nicht nur, ob die Verfügbarkeit und Fehlerquote von Komponenten den eigenen Anforderungen entspricht, sondern auch, inwieweit eine funktionale Änderung von der Zielgruppe akzeptiert wird: Stellt sich eine Änderung als wertlos heraus, wird sie wieder entfernt und so die technische Schuld reduziert.

Developer Experience

Developer Experience (DX), das Konzepte aus der UX-Optimierung auf Erfahrungen in Entwicklungsteams anwendet, kann hier eine gute Ergänzung sein, um die kulturelle Ebene aus Sicht des Entwicklungsteams besser 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 weniger effizienten Umgebung aussehen:

1. Der Tag beginnt mit einer Reihe von Problemen in der Produktion.

   1. Da es keine aggregierten Auswertungen gibt, wird in verschiedenen Protokolldateien und Überwachungsdiensten nach dem Fehler gesucht.

   2. Schließlich wird vermutet, dass das Problem im Auslagern von Speicher in eine Auslagerungsdatei liegt, und das Betriebsteam wird um mehr Speicher gebeten.

2. Nun ist es endlich an der Zeit zu sehen, ob es ein Feedback des QA-Teams zu der neu implementierten Funktion gab.

3. Dann ist auch schon das erste von mehreren Statusmeetings.

4. Endlich könnte die Entwicklung beginnen, wenn nur der Zugriff auf die notwendige API schon gegeben wäre. Stattdessen werden jetzt Telefonate mit dem Team geführt, das den Zugang zur API bereitstellt, so dass wir erst in einigen Tagen mit der Arbeit beginnen können.

Wir könnten noch viele weitere Blockaden aufzählen; am Ende 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 Hindernissen und Bürokratie. Die Mitglieder des Entwicklungsteams fühlen sich nicht nur ineffektiv und unproduktiv. Wenn sie sich schließlich mit dieser Arbeitsweise abfinden, macht sich bei ihnen erlernte Hilflosigkeit breit.

In einem solchen Umfeld versuchen die Unternehmen in der Regel, die Produktivität zu messen und die leistungsschwächsten Teammitglieder zu ermitteln, indem sie die Anzahl der Codeänderungen und der erfolgreich bearbeiteten Tickets messen. Meiner Erfahrung nach werden in solchen Unternehmen die besten Fachleute gehen; es gibt keinen Grund für sie, in einem ineffektiven Umfeld zu bleiben, wenn innovative digitale Unternehmen nach starken technischen Talenten suchen.

Der Arbeitstag in einem hocheffektiven Arbeitsumfeld könnte dagegen so aussehen:

1. Der Tag beginnt mit einem Blick auf das Projektmanagement-Tool des Teams, z.B. ein sogenanntes Kanban-Board, dann gibt es ein kurzes Standup-Meeting, nachdem jedem Teammitglied klar ist, woran es heute arbeiten wird.

2. Das Teammitglied stellt fest, dass die Entwicklungsumgebung automatisch aktuelle Bibliotheken erhalten hat, die auch schon in die Produktion übertragen wurden, da alle CI/CD-Pipelines grün waren.

3. Als Nächstes werden die Änderungen auf die eigene Entwicklungsumgebung angewendet und die ersten inkrementellen Codeänderungen gestartet, die durch Unit-Tests schnell validiert werden können.

4. Das nächste Feature erfordert den Zugriff auf die API eines Dienstes, für den ein anderes Team zuständig ist. Der Zugang kann über ein zentrales Serviceportal beantragt werden, und auftretende Fragen werden schnell in einem Chatroom beantwortet.

5. Nun kann mehrere Stunden lang ohne Unterbrechung intensiv an dem neuen Feature gearbeitet werden.

6. Nachdem die Funktion implementiert wurde und alle Komponententests bestanden sind, wird durch automatisierte Tests geprüft, ob die Komponente weiterhin mit allen anderen Komponenten integriert werden kann.

7. Sobald alle Pipelines für die kontinuierliche Integration grünes Licht geben, werden die Änderungen schrittweise für die vorgesehenen Zielgruppen in der Produktion freigegeben, wobei die Betriebskennzahlen überwacht werden.

Jedes Mitglied eines solchen Entwicklungsteams kann an einem Tag schrittweise Fortschritte machen und den Arbeitstag zufrieden mit dem Erreichten beenden. In einer solchen Arbeitsumgebung können die Arbeitsziele leicht und effizient erreicht werden, und es gibt wenig Reibungsverluste. Die Teammitglieder verbringen den größten Teil ihrer Zeit damit, etwas Wertvolles zu schaffen. Produktiv zu sein, motiviert die Mitglieder des Entwicklungsteams. Ohne Reibungsverluste haben sie Zeit, kreativ zu denken und sich einzubringen. Hier konzentrieren sich Unternehmen auf die Bereitstellung eines effektiven technischen Umfelds.

Kontaktiert uns

Wir beantworten gerne eure Fragen und erstellen ein maßgeschneidertes Angebot für die DevOps-Transformation.

Veit Schiele

Mail

Phone