Der Blätterkatalog benötigt Javascript.
Bitte aktivieren Sie Javascript in Ihren Browser-Einstellungen.
The Blätterkatalog requires Javascript.
Please activate Javascript in your browser settings.
8 l 2022 Betrieb das tut was sie soll Damit wurde die bis dahin vorherrschende Plan-Build-Run-Struktur durch ein agiles DevOps-Modell abgelöst Agile im IT-Betrieb nur bedingt einsetzbar Doch während die Einführung von agilen Methoden bei Entwicklerteams weit vorangeschritten ist hadert vor allem der IT-Betrieb damit Grund dafür ist die Gratwanderung die hier bewältigt werden muss Zum einen soll das Team schneller und agiler werden zum anderen muss an einigen Vorgehen und Verhaltensweisen festgehalten werden – etwa bei der Einhaltung bestimmter Sicherheitsrichtlinien Das gilt insbesondere für sogenannte „Brownfield-Unternehmen“ also Firmen die beispielsweise nicht nativ in der Cloud starten sondern Lösungen bereits auf bestehender Infrastruktur außerhalb der Cloud betreiben Hier kollidieren agile Methoden wie Scrum gegebenenfalls mit der bestehenden Arbeitsweise der verantwortlichen IT-Abteilung Scrum fokussiert sich lediglich auf die Produktentwicklung und blendet den Betrieb aus Sprint-Ziele in Scrum werden stets zu Beginn fixiert und sollen der Logik nach nicht im laufenden Sprint verändert werden Das ist kaum mit der täglichen Arbeit der Operations-Teams in Einklang zu bringen denn hier wird größtenteils reaktiv gearbeitet – etwa im Support Etwas anders verhält es sich mit Kanban oder auch Scrumban Bei diesen Methoden lassen sich die tägliche Support-Arbeit und das Arbeiten an Projekten besser in Einklang bringen und durch ein vernünftiges und transparentes Ticketing-System werden Kapazitätskonflikte besser sichtbar Agile Operations als Lösung Der Agile-Operations-Ansatz bringt den Betrieb der Lösung von Beginn an in die Produktplanung und -erstellung mit ein Daher benötigt man neben der passenden Methode für Agile Operations als zweiten Schritt eine neu gedachte Teamstruktur – speziell weil Operations mitgedacht werden soll DevOps Agile haben hier bereits Vorarbeit geleistet Die Product Owner PO sind ganzheitlich für das Produkt verantwortlich Sie stellen die Produktvision sowie die Die Squad-Member arbeiten entweder an Ops Tasks in einem Sprint oder an Dev Tasks in einem Sprint Zwischen Sprints können die KollegInnen rotieren je nachdem ob mehr Kapazität bei Dev oder bei Ops gebraucht wird Dies entscheiden Product Owner PO Architect und Lead Operations LO zusammen Letztes Wort hat der PO Roadmap auf Die Teams arbeiten in Squads zusammen an einem Sprint und werden dabei von anderen KollegInnen etwa aus Chaptern ein fachlicher Querschnitt über die Squads hinweg oder Gilden freiwillige übergreifende Interessengruppen wie zum Beispiel Testautomatisierung unterstützt Zudem sorgt ein Agile Coach für die Einhaltung der Regeln und stellt die Autonomie sicher Um nun Operations zu integrieren empfiehlt sich die Bestimmung eines Lead Operations LO sowie eines Architects AR Ersterer verantwortet den Betrieb des Produktes innerhalb der Squads und Letzterer stellt die technische Architektur des Produkts übergreifend sicher sprich sowohl die Erstellung als auch den nachhaltigen Betrieb Zudem stimmen sich beide vor jedem Sprint mit dem PO ab und definieren gemeinsam die Gewichtung zwischen Operations-Aufgaben und Entwicklung sowie dem Backlog siehe auch Abbildung Dieses Vorgehen spielt wiederum der Kanban-Methode in die Karten wobei – soweit planbar – eine Auswahl an Arbeitspaketen getroffen wird und diese mit der Sprint-Planung harmonisiert werden kann Durch Agile Operations teilt sich das Team je Sprint in Development und Betrieb auf – je nach Bedarf des Teams und seiner Stakeholder Am Ende ist es die Entscheidung des Product Owners wie viel Kapazitäten er in dem einen oder anderen benötigt Der Vorteil ist die höhere Flexibilität pro Produkt sowie das geschaffene Verständnis in den Teams – sowohl für die Entwicklung als auch für den Betrieb des Produkts Auch die Produktqualität profitiert Nun könnte man meinen dass der Ansatz der Agile Operations hauptsächlich den IT-Betrieb beeinflusst Doch wenn man genau hinsieht kann dieses Vorgehen die Produktqualität verbessern Indem gemäß dem Credo „Du baust es du betreibst es auch“ entwickelt wird fließen die Qualitätsansprüche der IT-Operations früher oder später automatisch in die Produktentwicklung ein – schließlich haben EntwicklerInnen nur selten Lust freiwillig mitten in der Nacht aufzustehen um die Störung eines Produktes zu beheben Florian Weigmann Chief Product Officer bei Plusserver Bi ld Plu ss er ve r