Agiles Entwickeln
DevOps krempelt Hierarchien um
Christoph Lixenfeld, seit 25 Jahren Journalist und Autor, vorher hat er Publizistik, Romanistik, Politikwissenschaft und Geschichte studiert.
1994 gründete er mit drei Kollegen das Journalistenbüro druckreif in Hamburg, schrieb seitdem für die Süddeutsche Zeitung, den Spiegel, Focus, den Tagesspiegel, das Handelsblatt, die Wirtschaftswoche und viele andere.
Außerdem macht er Hörfunk, vor allem für DeutschlandRadio, und produziert TV-Beiträge, zum Beispiel für die ARD-Magazine Panorama und PlusMinus.
Inhaltlich geht es in seiner Arbeit häufig um die Themen Wirtschaft und IT, aber nicht nur. So beschäftigt er sich seit mehr als 15 Jahren auch mit unseren Sozialsystemen. 2008 erschien im Econ-Verlag sein Buch "Niemand muss ins Heim".
Christoph Lixenfeld schreibt aber nicht nur, sondern er setzt auch journalistische Produkte ganzheitlich um. Im Rahmen einer Kooperation zwischen Süddeutscher Zeitung und Computerwoche produzierte er so komplette Zeitungsbeilagen zu den Themen Internet und Web Economy inklusive Konzept, Themenplan, Autorenbriefing und Redaktion.
- DevOps steht für hierarchiearme Entwicklungsprozesse.
- Nach Ansicht von Forrester verändern sich dadurch auch hierarchische Strukturen.
- Die Analysten haben 40 Unternehmen zu dem Thema interviewt.
Die Digitalisierung fast sämtlicher Kundenbeziehungen bietet Unternehmen große Chancen und verursacht zugleich Probleme. Nie war es leichter, neue Kunden zu gewinnen oder vorhandene zu verlieren.
Etablierte Unternehmen fürchten sich vor Startups mit neuen Ideen und innovativen Softwarelösungen, während sie selbst sich mit ihren jahrzehntealten Systemen herumschlagen müssen, die sich nicht in wenigen Wochen oder Monaten erneuern lassen.
In seinem Report: "Forget Two-Speed IT. DevOps enables faster delivery across the board" beschreibt Forrester die Vorteile von DevOps als Entwicklungs- und Implementierungsmethode auch und gerade in historisch gewachsenen Anwendungsumgebungen.
Eine Definition von DevOps
Foto: Marvellousworld - Fotolia.com
DevOps ist ein Kunstwort, das sich aus den ersten Silben von ‚Development‘ und ‚Operations‘ zusammensetzt, also aus Entwicklung und Betrieb.
Der Ansatz ähnelt dem der agilen Softwareentwicklung, nur dass es bei DevOps zusätzlich darum geht, Abteilungsgrenzen aufzulösen. Das macht es schwieriger, solche Ansätze in der Praxis zu etablieren.
Gelingen kann das nur, wenn bei allen Beteiligten Anreize für das sich Einlassen auf das Verfahren bestehen.
Es geht um die Frage, wie sich die ursprüngliche Idee einer Software schnell und stabil zum Kunden bringen lässt. Eine Entscheidung für neue Methoden wie DevOps fällt dabei natürlich nur dann, wenn damit aus Sicht der Unternehmensleitung ein quantitativ messbarer Vorteil gegenüber anderen Vorgehensweisen verbunden ist.
Methodisch lautet das Ziel, eine bessere Zusammenarbeit zwischen Entwicklungsteam, Service und Management zu etablieren, als das in traditionellen, hierarchischen Strukturen normalerweise der Fall ist.
Abteilungsgrenzen und Hierarchien abschaffen
Abteilungsgrenzen und Hierarchien sollen so weit wie möglich ausgeschaltet werden, das heißt Entwickler, Fachabteilungen und Management müssen willens und in der Lage sein, auf Augenhöhe zusammenzuarbeiten. Idealerweise arbeiten dabei so viele Beteiligte wie möglich temporär in denselben Räumen.
Foto: MicroTool
Scrum dient zur Steuerung
Zur Steuerung der abteilungsübergreifenden 'Operations' kommt meistens das Scrum-Verfahrenzum Einsatz. Grundannahme dahinter: ModerneSoftwareentwicklungSoftwareentwicklung ist zu komplex, um von vorne bis hinten planbar zu sein. Scrum reduziert die Komplexität erstens durch mehrere Feedbackschleifen, zweitens werden gewünschte Funktionen ständig überprüft und wenn nötig nachgeschärft. Alles zu Scrum auf CIO.de
Das Verfahren ist rollenbasiert, die beiden wichtigsten Rollen sind die des Product Owners und des Scrum Masters. Der Product Owner ist für den Erfolg verantwortlich, muss sicherstellen, dass das entwickelte Produkt sauber definiert ist und am Ende das kann, was es können soll. Der Scrum Master moderiert den ganzen Prozess.
- Retrospektive und Feedback in Scrum-Projekten
Scrum Manager haben die Möglichkeit, den Projekterfolg durch die Analyse des Sprints zu verbessern. Zielführend sind dabei die Retrospektive und das Feedback der Teammitglieder - ein Vorgang, den der Scrum Manager mit Diplomatie moderieren muss. Folgende Methodik mit Arbeitsblättern hat sich bewährt. - Feedback - Schritt 1
Für die Retrospektive erhält jedes Teammitglied ein vorbereitetes Blatt mit seinem Namen und zwei Fragen: "Was kann man von mir erwarten?" und "Was erwarte ich vom Team?" - Feedback - Schritt 2
Der Feedback-Bogen wird um zwei Bereiche ergänzt: "Was ich an Deiner Arbeit schätze ..." und "Was ich Dir wünsche, das Dir besser gelingt ..." - Feedback -Schritt 3
Der Feedback-Bogen wird an den Tischnachbarn weitergegeben, von diesem ausgefüllt und so lange weitergegeben, bis jeder Teilnehmer wieder sein persönliches Blatt vor sich liegen hat – jetzt mit dem schriftlichen Feedback aller beteiligten Teammitglieder. - Selbstreflexion
Zwei weitere Bereiche kommen hinzu – sie dienen der eigenen Reflexion des erhaltenen Feedbacks: "Darauf bin ich stolz ..." und "Das nehme ich mit ..." - Vorgehensmuster
Nach diesem Grundmuster lassen sich Retrospektiven zu einem späteren Zeitpunkt erneut wiederholen.