zurück zum Artikel

Auf der ersten englischen Version der DevOps-Konferenz Continuous Lifecycle in London zeigten Anfang Mai Experten aus aller Welt, wie Software schneller an den Nutzer kommt und sich die zugehörigen Prozesse in den letzten Jahren geändert haben.

Forschung, Entwicklung, Umsetzung, Vertrieb: Damit aus einer Idee Software werden kann, die dann ihren Weg zum Nutzer findet, müssen viele Menschen mit unterschiedlichen Fähigkeiten zusammenarbeiten. Dass die Aufgaben meist streng auf verschiedene Abteilungen verteilt sind, macht das Zusammenspiel mitunter holprig und vor allem eins: langsam. Abhilfe sollen die Prinzipien von Continuous Delivery und DevOps schaffen, mit deren Hilfe Release-Zylen verkürzt werden und Entwicklung und Betrieb (Development und Operations) näher zusammenrücken.

Gleich zu Beginn machte Keynote-Sprecher Jez Humble klar: "Continuous Delivery ist kein Kompromiss: Wir können schneller und besser sein, das eine schließt das andere nicht aus." Humble muss es wissen: Er ist einer der wichtigsten Experten auf dem Gebiet, hat am Standardwerk zum Thema mitgeschrieben. Er plädiert für die Rückkehr der "wissenschaftlichen Methode" in den Entwickleralltag: Hypothese aufstellen, testen, Daten sammeln, wiederholen. Unternehmen wie Amazon und Etsy testen Neuerungen ständig an kleinen Zielgruppen ihrer Kunden, ohne damit den Verkaufsstrom negativ zu beeinflussen. Denn, so Humble, das größte Verschwendungspotenzial im Unternehmen liegt da, wo am Kunden vorbei entwickelt wird.

Der Wille zählt

Über eins waren sich alle Redner einig, ob sie nun über Testing, Microservices oder Dienst auf Abruf berichteten: Es reicht nicht, "DevOps-Spezialisten" einzustellen oder eine schicke Chatsoftware für alle anzubieten. Vielmehr muss es einen grundsätzlichen Wandel in der Unternehmenskultur geben. Mehr Kommunikation, mehr Offenheit untereinander, weg vom Einzelkämpfer hin zum Teamplayer. Und das über die Grenzen der einzelnen Abteilungen hinaus.

DevOps bringt im Idealfall alle Beteiligten dazu, über ihre Rollen nachzudenken. Shai Yallin etwa, Software-Entwickler bei der Cloud-Entwicklerplattform WIX, gibt seinen Kollegen den Rat, sich als Gärtner ihrer Software zu sehen: Wenn man das "Wachstum" der Software verfolgen möchte, gibt man die Verantwortung für ihr Wohlergehen nicht achtlos an den Betrieb ab, sondern bleibt in Verbindung, um mögliche Schwachstellen früh zu erkennen.

Aus der Sicht des Betriebs hatte Katherine Daniels in ihrer Keynote einiges zum Thema beizutragen. Als Senior Operations Engineer bei Etsy berichtete sie vom dort genutzten System des "designierten Betriebs". Dabei stellen Mitarbeiter aus dem Bereich Operations ihre Kenntnisse auch anderen Teams zur Verfügung und können eingreifen, wenn sie Probleme sehen. Neben diesen operativen Vorteilen ist auch der persönliche Kontakt wichtig. Daniels möchte Mauern einreißen – nicht nur die zwischen Entwicklern und Betrieb, sondern auch die zwischen Kollegen mit und ohne technischen Hintergrund. In Etsys Bootcamp, das jeder neue Mitarbeiter durchlaufen muss, gibt es deshalb auch eine Station in der Kundenberatung. Die Botschaft: Jeder soll sehen, wie das Produkt wirklich beim Kunden ankommt.

Wer nun denkt "Klingt toll, auch mein Arbeitgeber sollte DevOps einführen!", der muss einen langen Atem haben. Laut DevOps-Verfechter Steve Pereira braucht es drei bis sechs Jahre, bis sich Continuous Delivery und DevOps im Unternehmen etabliert haben. Je größer das Unternehmen, desto länger die Durststrecke. Das setzt natürlich ein gewisses Durchhaltevermögen voraus – und die Bereitschaft, den Arbeitsplatz nicht nach zwei Jahren wieder zu wechseln.

Bei all den Diskussionen bleibt jedoch die Frage nach der Finanzierung nicht aus: Continuous Delivery bedeutet auch, dass Projekte mit offenem Ende laufen, ständig aktualisiert und von immer mehr Mitarbeitern betreut werden müssen. Um Gewinn zu machen, ist auch hier Kommunikation gefragt – diesmal mit dem Kunden, wie Projekmanagerin Helen Hosein von Softwire erklärt. Software ist kein Produkt von der Stange, sondern eine Maßanfertigung. Das bedeutet ständige Anpassung, auch im Preis. Damit das Budget des Auftraggebers trotzdem nicht explodiert, bietet Hosein ihm unterschiedliche Finanzierungsoptionen an. Etwa die "Menüvariante": Dabei zahlt der Kunde einen Festpreis für das "Menü" und kann im Laufe des Entwicklungsprozesses gleichwertige Posten gegeneinander austauschen, sobald es erforderlich ist. So haben beide Seiten Planungssicherheit und können trotzdem relativ flexibel auf unvorhergesehene Probleme reagieren.

Von inklusiver Unternehmenskultur zur inklusiven Industrie

Doch man hört nicht nur Positives: Im Zuge des DevOps-Siegeszuges klagen nicht wenige Unternehmen über einen Talentmangel. Um an gute Mitarbeiter zu kommen, die programmieren, aber auch kommunizieren können, haben Katherine Daniels und Jez Humble eine Idee: Statt weiter vorwiegend auf Männer mit weißer Hautfarbe zu setzen, sollten sich Unternehmen, und letztlich die gesamte Industrie, diversifizieren. Dabei geht es den beiden nicht um Männer-Bashing. Vielmehr sehen sie ein riesiges verstecktes Potenzial: zum einen für die Ideenfindung und Zusammenarbeit im Team, die sich verbessern, wenn nicht alle denselben Hintergrund haben, zum anderen für die eigentliche Produktentwicklung. Durch gemischte Teams ließe sich vermeiden, an einem Großteil der Weltbevölkerung vorbeizuentwickeln, da sie bereits in den Prozess einbezogen würden. Das gemeinsame Ziel lautet schließlich, die eigene Software erfolgreich an den Nutzer zu bringen. Ideen dafür, wie sich der Weg dahin optimieren lässt, konnten die Veranstalter heise Developer und The Register ihren über 270 Besuchern auf jeden Fall mit nach Hause geben.

Lisa Öztürkoglu
lebt als freie Autorin in London. Sie schreibt unter anderem über die Wechselwirkungen zwischen Technik und Gesellschaft.
(jul [1])

URL dieses Artikels:
https://www.heise.de/-3207835

Links in diesem Artikel:
[1] mailto:jul@heise.de

Copyright © 2016 Heise Medien