Operations heute und morgen, Teil 1: Das moderne IT-Unternehmen
Seite 2: Zukunft des IT-Betriebs
IT-Betrieb in Unternehmen: morgen
Um ausgehend von den beschriebenen Problemen einen modernen IT-Betrieb aufzubauen, stellt sich zunächst die Frage: Hilft es an dieser Stelle, Continuous Delivery und einige neue Tools zum Bereitstellen von Infrastruktur und Systemen einzuführen? Wohl eher nicht, wenn die Feedback-Zyklen vollständig über den gesamten Anwendungslebenszyklus laufen sollen (s. Abb. 2). Es gilt jetzt, zunächst die vorhandenen Prozesse und anfallenden Arbeiten zu visualisieren und im Folgenden besser zu strukturieren.
Ein gutes Mittel bieten hier Kanban-Boards. Sie ermöglichen es, die Arbeitsschritte sowie offene (WIP, work in progress) und erledigte Arbeiten aufzuzeigen. Die Fokussierung auf die Teams und die Umkehr der Arbeitsweise weg vom Push- hin zum Pull-Prinzip entlasten die Mitarbeiter, und Selbstorganisation und Mitabeitermotivation steigen. Diese ersten Erfolge helfen dabei, die bis dahin unterschiedlichen Teams für weitere gemeinsame Arbeit zu begeistern. Das gilt auch für das Management, wenn sich von Beginn an beispielsweise die Dauer der Arbeitsschritte (Durchlaufzeit) festhalten und so die Verbesserungen aufzeigen lassen. Wichtig ist dabei, dass die Verbesserungen nicht zulasten der Mitarbeiter erfolgen. Das kann durch dass Einhalten der Kanban-Prinzipien erreicht werden. Diese sind Visualisierung, Limitierung des WIP, Pull- statt Push-Prinzip und kontinuierliche Verbesserung. Wichtig ist weiterhin, dass die Arbeit fokussiert vonstatten geht. Denn den IT-Mitarbeiter kostet es viel Zeit, sich ständig in neue Arbeit zu hineinzudenken.
Nachdem sich hoffentlich erste Erfolge eingestellt haben, wird es Zeit, sich dem nächsten Problemfeld zu widmen. Teilweise neidisch schauen die Kollegen aus dem Betrieb zu den Entwicklern, die durch beispielsweise Scrum eine deutlich bessere und effizientere Kommunikation mit den Fachbereichen erreicht haben. Damit einher gehen kürzere Releasezyklen mit neuen Features. Selbst hier ist nicht alles Gold, was glänzt, und auch durch fehlerhaftes Umsetzen von Scrum bekommen Entwickler oft zu viele Features aufgedrängt und zu wenig Zeit für technische Schulden. Helfen kann hier beispielsweise eine gemeinsam erstellte "Definition of Done", eine Liste der Dinge, die abgearbeitet sein müssen, bevor eine User Story geschlossen werden kann.
Soll nun die Kommunikation zwischen Anwendungsentwicklern und Betrieb verbessert werden, kann man Scrum-Teams bilden, in denen funktionsĂĽbergreifend Mitglieder aus Betrieb, Entwicklung, Business und QA zusammenarbeiten und fĂĽr den gesamten Lebenszyklus bestimmter Services oder Features verantwortlich sind. Amazons CTO Werner Vogels hat dazu bereits im Mai 2006 im Magazin "Association for Computing Machinery's Queue" geschrieben:
"The traditional model is that you take your software to the wall that separates development and operations, and throw it over and then forget about it. Not at Amazon. You build it, you run it. This brings developers into contact with the day-to-day operation of their software. It also brings them into day-to-day contact with the customer. This customer feedback loop is essential for improving the quality of the service."
Es hat sich jedoch gezeigt, dass solche funktionsübergreifenden Scrum-Teams gerade am Anfang einer Transformation der täglichen Arbeit des IT-Betriebs wenig gerecht werden. Das liegt vor allem daran, dass der Anteil von ungeplanter Arbeit im IT-Betrieb deutlich höher ist als der von geplanter. Nun gibt es verschiedene Wege zum Erfolg, aber wieder hilft es, zunächst den Prozentsatz von geplanter und ungeplanter Arbeit im IT-Betrieb überhaupt sichtbar zu machen (etwa über Kanban-Boards). Wie im Folgenden auf das neu erworbene Wissen reagiert wird, ist noch einmal ein ganz anderes Thema.
Die Menge der ungeplanten Arbeit im IT-Betrieb hat dazu geführt, dass neue Ausprägungen des Scrum-Frameworks entwickelt wurden, die es ermöglichen, die Arbeit des IT-Betriebs besser abzudecken. Scrum-ban mischt beispielsweise Ideen von Scrum und Kanban, um der Arbeit des IT-Betriebs gerechter zu werden. Die generellen Ziele von Scrum-ban sind:
- mit Iterationen wie in Scrum starten
- eine Spalte fĂĽr wichtige/dringende Arbeiten einfĂĽhren
- Arbeit nicht frĂĽhzeitig Teammitgliedern zuweisen
- den WIP limitieren
- mit bedachten Schritten zum Pull-Prinzip
- immer den Arbeitsfluss beachten
- Vorbereitung- und Durchlaufzeit sind wichtiger als Burndown Charts
- Die durchschnittliche Durchlaufzeit zu kennen ist wichtiger als die genaue Schätzung jeder einzelnen Aufgabe
Um mit den Scrum-Teams der Entwickler effektiv zusammenarbeiten zu können, lässt sich einer weiteren Methode bedienen: des "scrum of scrum"-Meetings. Hier wird aus jedem Team ein sogenannter Team-Botschafter entsendet. Diese Botschafter treffen sich regelmäßig und berichten aus ihren Teilprojekten. Im günstigsten Fall stellt sich relativ schnell ein gemeinsames Verantwortungsgefühl für die Anwendung ein, und die Mitarbeiter fangen an, sich über ihre Grenzen hinweg mit den nun gemeinsamen Problemen zu beschäftigen.
Die entstehende Kommunikation sollte dazu genutzt werden, die über den Softwarelebenszyklus entstandenen technische Schulden nach und nach abzubauen. Gegebenenfalls wird nun das erste Mal gemeinsam darüber gesprochen, dass ein bestimmtes Modul beim Deployment immer wieder Ärger macht, woraufhin die Entwickler anfangen, ihre Tests auszuweiten. Im Folgenden lässt sich jetzt vereinbaren, dass die Teams zusammen das Überwachen und den Support für die Anwendung gewährleisten. Das führt im Umkehrschluss schnell zu bereinigten Log-Nachrichten genau so wie zu generell stabilerer Software.
Für ein erfolgreiches Umsetzen der oben angerissenen Ideen ist es wichtig, dass das Management Verantwortung abgibt und den Teams Vertrauen entgegenbringt. Gerade am Anfang, beim Aufbau der neuen Team-Strukturen, lassen sich durch zu wenig Vertrauen und Freiraum viele gute Vorsätze zerstören. Auch innerhalb der Teams ist es wichtig, dass ein reges Mit- und kein Gegeneinander gelebt wird. Letzten Endes soll damit auch der in vielen Firmen existierende "Hidden Champion" in regulierte Bahnen gebracht werden. Er ist ein Mitarbeiter, der häufig zum Beispiel bei einem fehlerhaften Deployment gerufen wird, dann mit Root-Rechten quer durch die Systeme marschiert und am Ende auf wundersame Weise alles wieder zum Laufen bekommt. Was erst einmal nach großer Kunst aussieht, entpuppt sich bei genauerer Betrachtung als hausgemacht. Der Hidden Champion wird oft so viel in Anspruch genommen, dass seine Lösungen oft die späteren Probleme erst verursachen, die wiederum nur er selbst lösen kann. Wird er mit den neuen Team-Strukturen gebändigt und agiert in klaren Strukturen, wird er es sein, der neue Trends und Techniken vorantreibt, für die er bis dahin keine Zeit gefunden hat.
