Wir freuen uns, diesen Artikel erneut zu veröffentlichen von David Shackelford Der Artikel wurde ursprünglich veröffentlicht auf DevOps.com .

Da sich das Entwicklungs- und Geschäftstempo weiter steigert, benötigen Teams eine agile und kollaborative Arbeitsumgebung, um erfolgreich zu sein. Die Umstellung auf ein DevOps-Modell ist ein entscheidender Teil der Erfolgsaussichten Ihrer Entwicklungsteams, doch für viele Unternehmen kann die Umstellung eine Herausforderung sein.

Worum geht es? – Warum Sie ein DevOps-Modell brauchen

DevOps ist eine Bewegung in der Softwarewelt, die sich auf die Zusammenarbeit zwischen Entwicklern und Betrieb, Kundenempathie und Infrastrukturautomatisierung konzentriert. In traditionellen Modellen schreiben Entwickler Code und übergeben ihn dann an Betriebsteams, um ihn in einer Produktionsumgebung bereitzustellen und auszuführen. Dies führt häufig zu einem Mangel an Verantwortung zwischen den beiden Teams („Auf meiner lokalen Box hat es funktioniert!“) sowie zu einem langsameren Entwicklungstempo. In einem DevOps-Modell hingegen arbeiten die beiden Teams eng zusammen und verfolgen gemeinsame, kundenorientierte Ziele – Entwickler übernehmen die Verantwortung für ihren Code, auch wenn dieser in der Produktion ist, und Betriebsteams erstellen Tools und Prozesse, mit denen Entwickler Code schneller und einfacher schreiben, testen und ausliefern können.

Durch das Durchbrechen der traditionellen Grenzen zwischen Entwickler und Betrieb erfolgt die Entwicklung schneller und mit mehr Kundenempathie, was letztlich zu einer besseren Kundenerfahrung und einem zufriedeneren Team führt. Anstatt das andere Team als Tor oder Hindernis zu betrachten, sehen sich Entwickler und Betrieb, wenn es richtig gemacht wird, als Teamkollegen, die zusammenarbeiten, um dem Kunden und dem Unternehmen einen Mehrwert zu bieten.

Leider ist es nicht einfach, DevOps-Kultur und -Praktiken in Ihrem Unternehmen einzuführen. Große Veränderungen an seit langem etablierten Silos können Widerstand hervorrufen, und Unternehmensleiter haben oft Angst vor den Kosten, die mit Veränderungen verbunden sind. Um diese Bedenken und Zögern auszuräumen, haben wir einige Tipps für den Übergang zu einem DevOps-Modell zusammengestellt.

Beginnen Sie mit der Zusammenarbeit – was funktioniert und was nicht?

Im Mittelpunkt von DevOps steht die verbesserte Zusammenarbeit zwischen Ihren Betriebs- und Entwicklungsteams. Sie beginnen jedoch wahrscheinlich nicht im luftleeren Raum – sehen Sie sich die besten Beispiele für die heutige Zusammenarbeit Ihrer Betriebs- und Softwareentwicklungsteams an und sprechen Sie darüber. Gibt es bestimmte Entwicklungs-/Betriebsgruppen, die bereits eng zusammenarbeiten, eine gute Kommunikation fördern oder gemeinsame Planungen durchführen? Wenn Sie sich auf das konzentrieren, was bereits funktioniert und wie Sie es verbessern können, anstatt auf das, was nicht funktioniert, bleiben die Dinge positiv und haben eine höhere Erfolgsaussichten.

Sie könnten eine Gruppen-Brainstorming-Sitzung zur Diskussion einberufen oder Einzelgespräche mit einzelnen Teammitgliedern führen, je nachdem, welches Format Ihrer Meinung nach den Leuten hilft, sich leichter zu öffnen. Dies Artikel hebt Möglichkeiten zur Zusammenarbeit über den gesamten Lebenszyklus der Anwendungsbereitstellung hervor und könnte einen nützlichen Rahmen zum Stellen von Fragen und Erkennen von Möglichkeiten bieten.

Neben dem Stand der Zusammenarbeit sollten Sie auch nach Prozesserfolgen und -störungen bei der Bereitstellung und Wartung von Anwendungen, Diensten und Infrastruktur suchen. Identifizieren Sie die größten Verbesserungsmöglichkeiten – dauern Ihre Builds und Tests Stunden? Konkurrieren Ihre 20 Entwicklungsteams alle um dieselben drei Staging-Umgebungen? Wenn Sie die Auswirkungen dieser Schwachstellen quantifizieren können, können Sie den Übergang gegenüber Geschäftspartnern rechtfertigen, die möglicherweise nicht so viel praktische Erfahrung mit den Schwachstellen Ihrer Teams haben.

Es ist auch wichtig, ein Verständnis für die unterschiedlichen Perspektiven zu entwickeln, die Betriebs- und Entwicklungsteams haben können. Wenn Ihre Organisation traditionell sehr isoliert war, kann es eine neue Denkweise sein, bei der Planung und Priorisierung an die Ziele anderer Teams zu denken. Das Teilen der Ziele jedes Teams und wie Erfolg für sie aussieht, kann helfen, dieses Verständnis und diese Empathie aufzubauen. Konzentrieren Sie sich auf Transparenz (ein Rahmen wie OKRs kann helfen), um Konflikte aufgrund nicht übereinstimmender Annahmen über Prioritäten zu vermeiden.

Erstellen Sie einen Plan

Sobald Sie Möglichkeiten zur Verbesserung der Zusammenarbeit und des Workflows zwischen Entwicklern und Betrieb identifiziert haben, ist es an der Zeit, einen konkreten Plan zu erstellen. Wählen Sie die wichtigsten Möglichkeiten aus und identifizieren Sie die ersten Schritte, um etwas zu bewirken. Courtney Nash empfiehlt, mit einer Gruppe von Leuten zu beginnen, die für die Vision aufgeschlossen sind, und ein kleines Produkt oder eine kleine Dienstleistung als Testumgebung auszuwählen. Bei der Umsetzung großer Änderungen ist es hilfreich, klein anzufangen und von dort aus zu skalieren, nachdem der Erfolg bewiesen ist.

Ingenieure sind nicht immer für ihre zwischenmenschlichen Fähigkeiten bekannt, aber bei der Umstellung auf DevOps geht es genauso um Menschen wie um Prozesse und Tools. Während des gesamten Prozesses sollten Sie wichtige Stakeholder in Ihrem Team und Unternehmen in die Umstellung einbeziehen. Change Management klingt furchtbar unternehmensorientiert, aber im Kern geht es darum, Unterstützung für Ihre Projekte und Ziele aufzubauen, indem Sie Input von wichtigen Stakeholdern sammeln: Sammeln Sie ihr Feedback und ihre Ziele, teilen Sie Ihren Plan auf der Grundlage ihres Inputs mit und gestalten Sie ihn neu, und kommunizieren Sie Ihren Fortschritt mit ihnen. Es ist immer einfacher, isoliert mit Leuten zu arbeiten, die bereits Ihrer Meinung sind, aber für dauerhafte Veränderungen müssen Sie in den Aufbau von Unterstützung in Teams und in Ihrem gesamten Unternehmen investieren.

Wählen Sie schließlich realistische Zeitpläne und Ziele. Es ist wichtig zu beachten, dass einige Auswirkungen der Änderung möglicherweise erst mit der Zeit sichtbar werden, da die Mitarbeiter sich an neue Tools und Arbeitsweisen gewöhnen müssen. Unterschätzen oder vernachlässigen Sie nicht die Zeit, die für die Schulung erforderlich ist, und lassen Sie sich nicht entmutigen, wenn sich das erste ausgewählte Projekt als nicht gut herausstellt. Wie Courtney Nash erwähnt, erkannte Nordstrom.com, dass ihr erstes Projekt letztlich nicht das richtige für den Anfang war. Wichtig ist, dass sie nicht aufgaben, sondern sich für eine andere, besser geeignete Anwendung entschieden.

Messen und reflektieren

Obwohl es selten vorkommt, dass Zeitpläne in komplexen Systemen genau wie geplant eingehalten werden, ist es wichtig, Ihre Arbeit zeitlich zu begrenzen, damit Sie den Verlauf messen und reflektieren können.

Nach dem von Ihnen gewählten Meilenstein bringen Sie die Stakeholder zusammen und führen Sie eine Retrospektive durch. Es gibt eine viele tolle Ressourcen da draußen um bei guten Retrospektiven zu helfen, aber unabhängig von der Herangehensweise sollten Sie darauf achten, dass Sie gezielt Raum schaffen, um Ihre Ergebnisse kritisch zu betrachten, Erfolge zu feiern und darüber nachzudenken, wie Sie den Prozess für die Zukunft ändern oder wiederholen möchten.

Wenn Sie über Fortschritte nachdenken, ist es wichtig, offen und ehrlich zu sein und gleichzeitig von den besten Absichten Ihrer Teamkollegen auszugehen. Sie werden garantiert Fehler machen – das ist bei jedem neuen Prozess unvermeidlich –, aber denken Sie daran (und helfen Sie anderen, sich daran zu erinnern), dass Sie alle auf dasselbe Ziel hinarbeiten und gemeinsame Werte und Ziele teilen.

Gib nicht auf

Die Einführung von DevOps ist für ein Unternehmen eine große Veränderung und wird auf dem Weg dorthin holprig verlaufen. Letztendlich können die Vorteile einer engeren Zusammenarbeit zwischen Teams und einer von Empathie geprägten Entwicklungskultur jedoch sehr groß sein und sich in Produktqualität, Geschwindigkeit und Teammoral niederschlagen.