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

Da sich Entwicklung und Geschäftsentwicklung immer weiter beschleunigen, benötigen Teams für ihren Erfolg eine agile und kollaborative Arbeitsumgebung. Die Umstellung auf ein DevOps-Modell ist ein entscheidender Schritt für den Erfolg Ihrer Entwicklungsteams, doch für viele Unternehmen kann die Umstellung eine Herausforderung darstellen.

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

DevOps ist eine Bewegung in der Softwarewelt, die sich auf die Zusammenarbeit zwischen Entwicklern und Betriebsteams, Kundeneinfühlungsvermögen und Infrastrukturautomatisierung konzentriert. In traditionellen Modellen schreiben Entwickler Code und übergeben ihn dann an Betriebsteams, die ihn in einer Produktionsumgebung bereitstellen und ausführen. Dies führt häufig zu mangelnder Eigenverantwortung zwischen den beiden Teams („Auf meinem lokalen Rechner hat es funktioniert!“) und 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 entwickeln Tools und Prozesse, die Entwicklern helfen, Code schneller und einfacher zu schreiben, zu testen und auszuliefern.

Durch das Durchbrechen traditioneller Grenzen zwischen Entwicklern und Betrieb erfolgt die Entwicklung schneller und mit mehr Kundenempathie. Dies führt letztendlich zu einem besseren Kundenerlebnis und einem zufriedeneren Team. Anstatt das andere Team als Hindernis oder Hürde zu betrachten, sehen sich Entwickler und Betrieb bei richtiger Vorgehensweise als Teamkollegen, die gemeinsam daran arbeiten, Mehrwert für Kunden und Unternehmen zu schaffen.

Leider ist die Einführung der DevOps-Kultur und -Praktiken in Ihrem Unternehmen nicht einfach. Große Veränderungen an seit langem etablierten Silos können Widerstand hervorrufen, und Führungskräfte scheuen oft die damit verbundenen Kosten. Um diese Bedenken und Bedenken zu zerstreuen, haben wir einige Tipps für die Umstellung auf ein 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 starten jedoch wahrscheinlich nicht im luftleeren Raum – betrachten und diskutieren Sie die besten Beispiele für die aktuelle Zusammenarbeit Ihrer Betriebs- und Softwareentwicklungsteams. Gibt es bestimmte Entwicklungs-/Betriebsgruppen, die bereits eng zusammenarbeiten, eine gute Kommunikation fördern oder gemeinsame Planungen durchführen? Konzentrieren Sie sich auf das, was bereits funktioniert und wie es verbessert werden kann, anstatt auf das, was nicht funktioniert. Das sorgt für positive Ergebnisse und erhöht die Erfolgschancen.

Sie könnten eine Brainstorming-Sitzung in der Gruppe organisieren 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 -problemen 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? Die Quantifizierung der Auswirkungen dieser Schwachstellen kann Ihnen helfen, den Übergang gegenüber den Geschäftspartnern zu 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 von Betriebs- und Entwicklungsteams zu entwickeln. Wenn Ihr Unternehmen traditionell stark isoliert ist, kann es eine neue Denkweise sein, bei der Planung und Priorisierung die Ziele anderer Teams zu berücksichtigen. Die gemeinsamen Ziele der einzelnen Teams und deren Erfolgsaussichten können dieses Verständnis und die Empathie fördern. 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 Menschen zu beginnen, die für die Vision empfänglich sind, und ein kleines Produkt oder eine kleine Dienstleistung als Testumgebung auszuwählen. Bei der Umsetzung großer Veränderungen ist es hilfreich, klein anzufangen und nach dem Erfolg von dort aus zu skalieren.

Ingenieure sind nicht immer für ihre soziale Kompetenz bekannt, doch beim Umstieg auf DevOps geht es ebenso um Menschen wie um Prozesse und Tools. Während des gesamten Prozesses sollten Sie wichtige Stakeholder Ihres Teams und Unternehmens in den Umstieg einbeziehen. Change Management klingt zwar etwas unternehmensorientiert, aber im Kern geht es darum, Unterstützung für Ihre Projekte und Ziele zu gewinnen, indem Sie Input von wichtigen Stakeholdern einholen: Sammeln Sie deren Feedback und Ziele, teilen Sie Ihren Plan anhand ihres Inputs mit und gestalten Sie ihn neu, und kommunizieren Sie Ihre Fortschritte mit ihnen. Es ist immer einfacher, isoliert mit Leuten zu arbeiten, die bereits einer Meinung sind, aber für dauerhafte Veränderungen müssen Sie in den Aufbau von Unterstützung in Teams und im 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 nach einiger Zeit sichtbar werden, da sich die Mitarbeiter an neue Tools und Arbeitsweisen gewöhnen müssen. Unterschätzen Sie nicht den Zeitaufwand für die Schulung und lassen Sie sich nicht entmutigen, wenn sich das erste ausgewählte Projekt als nicht gut erweist. Wie Courtney Nash erwähnt, erkannte Nordstrom.com, dass ihr erstes Projekt letztendlich 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 in komplexen Systemen selten vorkommt, dass Zeitpläne 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 Beteiligten 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 vom Ansatz sollten Sie sicherstellen, 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.

Bei der Betrachtung des Fortschritts ist es wichtig, offen und ehrlich zu sein und gleichzeitig von den besten Absichten der Teamkollegen auszugehen. Fehler sind garantiert – 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 der Weg dorthin wird nicht ohne Hindernisse sein. Letztendlich können sich die Vorteile einer engeren Zusammenarbeit zwischen den Teams und einer stärker von Empathie geprägten Entwicklungskultur jedoch als sehr wertvoll erweisen und sich in Produktqualität, Geschwindigkeit und Teammoral niederschlagen.