{"id":34157,"date":"2019-10-31T21:56:43","date_gmt":"2019-10-31T18:56:43","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-nachat-devops-transformatsiyu\/"},"modified":"2019-10-31T21:56:43","modified_gmt":"2019-10-31T18:56:43","slug":"kak-nachat-devops-transformatsiyu","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/kak-nachat-devops-transformatsiyu","title":{"rendered":"Wie man eine DevOps-Transformation beginnt","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Wenn Sie nicht verstehen, was DevOps ist, hier ist eine kurze Zusammenfassung. DevOps ist eine Sammlung von Praktiken, die die \u00c4ngste der Ingenieure verringern<\/strong> und die Anzahl der Ausf\u00e4lle in der Softwareproduktion reduzieren. In der Regel verk\u00fcrzen sie die Markteinf\u00fchrungszeit<\/strong> \u2013 den Zeitraum von der Idee bis zur Auslieferung des Endprodukts an die Kunden, was es erm\u00f6glicht, schnell Gesch\u00e4ftsexperimente durchzuf\u00fchren.<\/strong>.<\/p>\n

Wie beginnt man eine DevOps-Transformation? Kurz gesagt: Wir w\u00e4hlen den Service aus, mit dem wir den Prozess starten, identifizieren die Personen, die mit dem Service zu tun haben, erstellen eine Value Stream Map, gr\u00fcnden ein tempor\u00e4res Team, das zun\u00e4chst f\u00fcr die Transformation zust\u00e4ndig ist, und setzen ihm eine Aufgabe. Wir wiederholen den Zyklus die erforderliche Anzahl von Malen.<\/p>\n

\"Wie<\/p>\n

Ein detaillierter Plan f\u00fcr die DevOps-Transformation mit Beispielen und Anleitungen im Folgenden \u2013 in der Ausf\u00fchrung Vortrag<\/a><\/noindex> Andrej Alexandrow<\/b> \u2013 eines Ingenieurs bei der Firma Express42, die Beratung zur Umsetzung von DevOps bietet und diesen Prozess beschleunigt, weil sie bereits eine Karte der Herausforderungen erstellt hat. Wenn Sie der Meinung sind, dass eine Transformation f\u00fcr Sie nicht erforderlich ist oder dass Ihre Spezifikationen keine DevOps-Praktiken unterst\u00fctzen, verwenden Sie den Bericht als Anleitung zur Identifizierung und Beseitigung von Einschr\u00e4nkungen.
\n<\/a><\/noindex>
\nWenn Sie sich um die DevOps-Transformation sorgen, haben Sie ein gro\u00dfes Unternehmen und m\u00fcssen diesen Prozess allm\u00e4hlich auf die gesamte Struktur ausweiten. Solange es notwendig ist, das Team zu transformieren oder eine Einschr\u00e4nkung zu beseitigen, kann der folgende Algorithmus wiederholt werden.<\/p>\n

Die Auswahl des Services<\/h2>\n

\nDer Plan steht fest, beginnen wir mit dem ersten Schritt \u2013 der Auswahl des Services. Das erste Kriterium ist die Lebensdauer<\/strong>: es gibt alte Services \u2013 Legacy, und neue. Man kann sowohl mit alten als auch mit neuen starten.<\/p>\n

Es ist sinnvoll, einen neuen Service auszuw\u00e4hlen.<\/strong>Er ist frisch, es gibt noch keinen etablierten Arbeitsprozess im Team, das sich um ihn k\u00fcmmert. Rund um ihn gibt es keinen gro\u00dfen technischen Schuldenberg, man muss ihn nicht st\u00e4ndig reparieren. Wir k\u00f6nnen damit machen, was wir wollen.<\/p>\n

Bei einem alten Service gibt es Probleme, die damit zu tun haben, dass \u00c4nderungen immer schwierig sind.<\/strong>Es gibt bereits eine Reihe von ernsthaften Einschr\u00e4nkungen, aber m\u00f6glicherweise besch\u00e4ftigen sich damit Menschen, die bereit sind, alles umzukrempeln \u2013 sie sind m\u00fcde und m\u00f6chten etwas anders machen, weil es schmerzhaft ist.<\/p>\n

Die Arbeit mit einem alten Service schafft einen starken Pr\u00e4zedenzfall<\/strong> in Ihrem Unternehmen \u2013 man kann etwas \u00e4ndern. Wenn Sie einen neuen Service ge\u00e4ndert haben, der 100 Mal pro Stunde in die Produktion geht und alles gut l\u00e4uft, sagen die Leute in Ihrem Unternehmen vielleicht:<\/p>\n

Das ist doch ein neuer Service! Damit war alles einfach, versuchen Sie mal, mit unserem alten Schrott etwas zu machen.<\/em><\/p>\n

Einen Legacy-Service macht es Sinn, in die Transformation zu ziehen, wenn Sie dies mit jemandem tun, zum Beispiel, wenn Sie einen externen Berater eingeladen haben. Seien wir ehrlich, die Transformation wird alles durcheinanderbringen, was nur m\u00f6glich ist.<\/strong>Sie experimentieren und wissen nicht, wohin Sie kommen, welche Technologien Sie verwenden werden und wo und welche Fallstricke in den Prozessen auftauchen werden. Deshalb ist es einfacher, etwas Neues zu \u00e4ndern.<\/p>\n

Wenn Sie alles selbst machen und im Unternehmen keine ernsthaften Kompetenzen vorhanden sind \u2013 nehmen Sie den neuen Service. Wenn Sie einen externen Berater kennen und Mittel vorhanden sind \u2013 w\u00e4hlen Sie den alten.<\/p><\/blockquote>\n

\nEs gibt Services, die einfach nur eine Benutzeroberfl\u00e4che bieten, zum Beispiel eine einfache Website oder eine mobile Anwendung. Aber es gibt auch ernsthafte Dinge wie das Billing. Wenn mit dem Billing etwas nicht stimmt, wird es schwierig, dies zu kl\u00e4ren. Hier haben wir auch eine Wahl.<\/p>\n

Wir arbeiten entweder mit einem kritischen Service<\/strong>, aber wir leiden bereits darunter, er schafft Einschr\u00e4nkungen, oder wir arbeiten mit einer Benutzeroberfl\u00e4che<\/strong>. Das ist das zweite Auswahlkriterium. \u00c4hnlich gibt es die M\u00f6glichkeit, einen erfahrenen Berater hinzuzuziehen \u2013 wir arbeiten mit der schweren Variante.<\/p>\n

Aber selbst in diesem Fall w\u00fcrde ich nicht raten, so vorzugehen, denn solange kein Verst\u00e4ndnis daf\u00fcr besteht, womit man arbeiten soll und in welche Richtung man transformieren m\u00f6chte, ist es keine gute Idee, eine kritische Sache zu nehmen und sie zu durchw\u00fchlen. Deshalb ziehen wir in diesem Fall vor, mit einer Benutzeroberfl\u00e4che zu arbeiten, deren Ausfall nicht kritisch ist.<\/p>\n

Lassen Sie uns nun das Team des Services<\/b>betrachten. Mit denjenigen, die sich um diesen Service k\u00fcmmern, m\u00fcssen wir st\u00e4ndig arbeiten und in sehr engem Kontakt stehen.<\/p>\n

Die Menschen im Team lassen sich grob in zwei Kategorien einteilen: Konservative<\/strong> \u2013 leben in der alten Welt oder wissen einfach nichts \u00fcber DevOps, und Innovatoren<\/strong>, die alle modernen Praktiken mitbringen. Die zweiten haben nicht immer das n\u00f6tige Wissen, sind aber wenigstens bereit dazu.<\/p>\n

Auf der einen Seite sind Konservative erfahrene Leute: lange im Unternehmen, mit tiefen Kenntnissen, aber sie wissen nichts \u00fcber die Praktiken. Auf der anderen Seite sind es Innovatoren, die etwas geh\u00f6rt haben, aber wahrscheinlich nicht sehr lange im Unternehmen arbeiten. Mit wem von ihnen ist es besser zu arbeiten?<\/p>\n

Mit den Konservativen m\u00fcssen wir auf jeden Fall interagieren, da dies ihr Service ist. Wir m\u00fcssen mit ihnen kommunizieren, die Besonderheiten des Services kl\u00e4ren, was so gemacht werden kann und was anders. Wir sind von ihren Beratungen abh\u00e4ngig. Sicherlich m\u00fcssen wir ihnen etwas anvertrauen, weil sie ihren Service besser kennen. Daher ist es wichtig, mit welchem Team wir am Ende in Kontakt treten werden.<\/p>\n

Es ist sinnvoll, Innovatoren in das Team zu w\u00e4hlen, denn die Konservativen k\u00f6nnten uns einen Streich spielen.\n<\/p><\/blockquote>\n

\nIn der Praxis kommt es h\u00e4ufig vor, dass konservative Menschen erhebliches Wissen haben, aber kein Verst\u00e4ndnis daf\u00fcr, wie es weitergeht. Sie haben einfach Angst, dass sie nach der Transformation und Umgestaltung des Services entlassen werden, weil sie nicht mehr ben\u00f6tigt werden. Manchmal sabotieren sie einfach die Arbeit, weil sie nicht verstehen, was passiert.<\/p>\n

Ich hatte einen Fall, als ein Typ aus dem Team alles M\u00f6gliche reparierte, weil es angeblich kritischer war als das, was wir gerade machen. Wir setzen die Aufgabe: implementiere heute dieses St\u00fcck \u2014 nein, am anderen Ende der Welt brennt es, wir gehen es reparieren. Mit solchen Menschen ist es schwer zu arbeiten.<\/p>\n

Die Leute aus dem Team der Konservativen k\u00fcmmern sich oft nicht um Aufgaben oder verschieben sie bis zur letzten Minute. Und wenn, Gott bewahre, Sie einen Fehler gemacht haben und ihnen KPI f\u00fcr die Anzahl der erf\u00fcllten Aufgaben auferlegt haben, und ein Teil aus irgendeinem Grund nicht in den KPI enthalten ist, dann werden sie \u00fcberhaupt nichts tun. Im Grunde genommen haben sie recht, denn sie verlieren dann ihre Pr\u00e4mie.<\/p>\n

Mit Innovatoren ist es einfacher \u2014 sie sind loyaler.<\/strong>Sie haben schon etwas geh\u00f6rt, wollen irgendwohin gehen, deshalb werden sie helfen. Wir brauchen Menschen, die bereit sind, in der ersten Zeit zu leiden: Wenn sich der Service \u00e4ndert, werden alle Schwierigkeiten und Stolpersteine die Innovatoren auf sich nehmen, als w\u00e4ren sie Pioniere. Innovatoren wollen alles Neueste und Modische und bereit zu leiden.<\/p>\n

Konservative k\u00f6nnen sp\u00e4ter in ihren Glauben umgewandelt werden. Wenn Sie zeigen, dass Sie einen Teil ge\u00e4ndert haben und alles gut l\u00e4uft, werden sie wahrscheinlich auch ausprobieren wollen und die neue DevOps-Religion annehmen.<\/p>\n

\"Wie
\n<\/p>\n

Zusammenfassend. Wenn wir die gesamte Transformation in unserem Unternehmen selbst durchf\u00fchren, w\u00e4hlen wir: einen neuen Service, vorzugsweise mit einer einfachen Benutzeroberfl\u00e4che, um nicht allzu sehr unter seinen Ausf\u00e4llen zu leiden, und ein Team von Innovatoren.<\/p><\/blockquote>\n

\nWenn es m\u00f6glich ist, einen externen Berater einzubeziehen, sollten wir anstelle eines neuen den alten Dienst in Anspruch nehmen, unter dem wir bereits leiden. Menschen, die in verschiedenen Unternehmen lange mit Transformationen besch\u00e4ftigt waren, haben verschiedene F\u00e4lle gesehen und verstehen bereits, wie man es richtig macht und in welche Richtung man \u00fcberhaupt gehen sollte.<\/p>\n

Wer ist beteiligt?<\/h2>\n

\nWir m\u00fcssen wirklich alle finden, die irgendeine Beziehung zum Dienst haben: Entwickler, Tester, Administratoren, Sicherheitsfachleute, Manager und m\u00f6glicherweise Product Owners. Obwohl Product Owners keine Techniker sind, haben sie eine Beziehung zum Dienst: Sie treffen Entscheidungen und setzen Aufgaben.<\/p>\n

\"Wie
\n<\/p>\n

Wir m\u00fcssen alle finden, die irgendeine Entscheidung treffen und Einfluss auf das haben, was mit dem Dienst passiert, sie kennenlernen und mit ihnen sprechen.<\/p><\/blockquote>\n

\nWozu ben\u00f6tigen wir sie? Um zu wissen, mit wem wir verhandeln sollen.<\/strong>. W\u00e4hrend der Transformation, wenn sich das gewohnte Arbeitsprinzip mit dem Dienst \u00e4ndert, wird es dennoch zu St\u00f6rungen kommen. Eine Zeit lang wird es Ausf\u00e4lle geben, w\u00e4hrend wir neue Ans\u00e4tze testen. Die Menschen m\u00fcssen darauf vorbereitet sein und damit einverstanden.<\/p>\n

Danach m\u00fcssen wir eine Value Stream Map erstellen und ohne diese Leute wird das nicht gelingen, denn nur sie alle zusammen kennen das Gesamtbild der Geschehnisse. Eine Person wei\u00df niemals alles, was mit dem Dienst passiert.<\/p>\n

Sie werden Leute f\u00fcr das Team empfehlen. Sp\u00e4ter werden wir besprechen, warum ein separates Team ben\u00f6tigt wird. Wir m\u00fcssen Menschen aus bestehenden Abteilungen einbeziehen. Diejenigen, die eine Beziehung zum Dienst haben, k\u00f6nnen Kollegen empfehlen, die in unsere Richtung denken, uns helfen k\u00f6nnen und die Kompetenz haben, die wir ben\u00f6tigen.<\/p>\n

Danach versammeln wir all diese Leute aus verschiedenen Abteilungen in einem Raum und beginnen mit dem Bau der Value Stream Map.<\/p>\n

Wir erstellen eine Value Stream Map.<\/h2>\n

\nDie Value Stream Map ist ein Diagramm oder eine Karte, die den Wertefluss bis zum Kunden darstellt.<\/strong>. Es handelt sich um den gesamten Prozess von der Ideenfindung bis zur Umsetzung, einschlie\u00dflich aller Zwischenetappen und wie der Wert letztlich zu unseren Kunden gelangt.<\/p>\n

Die Value Stream Map wird ben\u00f6tigt, um alle Entwicklungsphasen zu visualisieren,<\/strong>, Probleme durch Messungen, die im aktuellen Prozess vorhanden sind, zu lokalisieren und diese Probleme zu beginnen zu beheben, und das anf\u00e4ngliche Ziel festzulegen.<\/strong>. Das ist der Ort, an dem wir anfangen werden, tats\u00e4chlich etwas zu tun.<\/p>\n

Metriken<\/h3>\n

\nIn der Literatur zur Value Stream Map sind viele verschiedene Metriken beschrieben, aber f\u00fcr den Anfang reichen uns drei.<\/p>\n

Lead Time \u2014 Verz\u00f6gerung\/Wartezeit<\/strong> \u2014 Zeit, in der wir auf etwas warten. Zum Beispiel wartet der Tester, bis der Stand f\u00fcr Tests verf\u00fcgbar ist, und kann in dieser Zeit nichts machen.<\/p>\n

Wertsch\u00f6pfungszeit \u2014 Zeit n\u00fctzlicher Arbeit<\/strong> \u2014 die Zeit, die wir in einer bestimmten Phase aufgebracht haben, um einen Endwert f\u00fcr den Benutzer zu schaffen. Zum Beispiel hat der Tester seinen Test gestartet und begonnen etwas zu \u00fcberpr\u00fcfen. Dies ist die Zeit n\u00fctzlicher Arbeit, in der wir tats\u00e4chlich etwas f\u00fcr das Produkt tun. Daf\u00fcr bezahlen die Kunden \u2014 f\u00fcr hochwertige Software.<\/p>\n

%C\/A \u2014 Prozentsatz der angenommenen Arbeit. <\/strong>Wir haben eine Phase \u2014 Entwicklung, die zweite Phase \u2014 Testing. Wie viele Features die Tester von den Entwicklern angenommen haben, und es gibt diesen Prozentsatz.<\/p>\n

So sieht unsere Karte ungef\u00e4hr aus.<\/p>\n

\"Wie
\n
\nSie kann je nach Struktur der Organisation, Anzahl der Abteilungen und dem, was Sie tun, anders aussehen. Aber im Allgemeinen wird die Karte zwei Phasen enthalten: die Idee <\/strong>und Analytik<\/strong>. In dieser Phase werden Daten erwartet, z.B. Lead Time 2 Wochen und Wertsch\u00f6pfungszeit 2 Tage.<\/p>\n

Wir decken absolut alle Phasen mit Metriken ab.<\/p><\/blockquote>\n

\nBacklog<\/strong> \u2014 wie viele Aufgaben liegen, nachdem die Analysten sie erfunden haben.<\/p>\n

Entwicklung<\/strong> \u2014 wie viele Wochen die Entwickler auf Kl\u00e4rung der Aufgaben, St\u00e4nde oder Ausr\u00fcstung gewartet haben \u2014 egal, aber sie warten auf etwas. Zum Beispiel setzen sie 4 Tage lang ein Feature um. Hier kommt die Metrik %C\/A ins Spiel. Die Entwickler haben nur 80% der Aufgaben aus dem Backlog \u00fcbernommen. Sie glauben, dass die restlichen 20% nicht gen\u00fcgend klare Anforderungen haben und haben sie zur \u00dcberarbeitung geschickt.<\/p>\n

Tests<\/strong>. Im Diagramm ist LT mit 4 Tagen angegeben. Zum Beispiel haben die Tester auf die Freigabe des Teststands gewartet, VA 2 Tage haben sie tats\u00e4chlich etwas getestet, und %C\/A = 40 %. \u2014 Nur 40 % des Codes oder der Features, die die Entwickler gesendet haben, haben die Tester als angemessen angesehen. Alles andere hat ihnen aus irgendeinem Grund nicht gefallen.<\/p>\n

Ich werde nicht detailliert darauf eingehen, wie diese Messungen durchgef\u00fchrt werden, am Ende des Artikels empfehle ich Literatur, aus der man dar\u00fcber lernen kann.<\/p>\n

Das Einzige, was ich empfehlen kann \u2014 Vertrauen Sie den Leuten nicht, die mit Ihnen eine Wertstromkarte erstellen. Sie geben an, wie viel Zeit verschiedene Prozesse in Anspruch nehmen, aber diese Sch\u00e4tzungen sind nicht immer korrekt, daher ist es besser, selbst zu messen.<\/p>\n

Wir hatten einen Fall, als wir in die Abteilung Operations kamen und fragten, wie lange es dauert, eine neue Funktion in die Produktion zu bringen. Uns wurde gesagt, dass es 10 Minuten dauert, und wir dachten, warum sind wir \u00fcberhaupt in dieses Unternehmen gekommen? Es stellte sich heraus, dass 10 Minuten die Laufzeit eines Skripts sind, das den Code auf den Server bringt. Aber davor liegt das Release drei Tage auf dem Server und verstaubt einfach \u2013 im Backlog liegt eine Aufgabe, die deployt werden muss. Das bedeutet, dass es vor der Deploy-Phase eine Wartephase gibt, in der das Projekt einfach liegen bleibt. H\u00e4tten wir nicht mit einem Notizbuch hingegangen, nicht mit den Augen auf die Aufgabe in Jira aufmerksam geworden und begonnen, sie Schritt f\u00fcr Schritt zu verfolgen, h\u00e4tten wir geglaubt, dass alles wunderbar ist und es kein Problem gibt.<\/p>\n

Deshalb m\u00fcssen die Messungen doch selbst durchgef\u00fchrt werden, am besten nicht nur einmal, um eine m\u00f6glichst realistische Vorstellung zu bekommen. Je nach Value Stream Map werden Sie entscheiden, wo Sie anfangen und was Sie zuerst beheben.<\/p>\n

Tempor\u00e4res Team<\/h2>\n

\nViele Unternehmen, die beschlossen haben, DevOps einzuf\u00fchren, bilden ein Team, jedoch nicht ein tempor\u00e4res, sondern eines, das schon mehrere Jahre besteht. Wenn Sie sich den DevOps-Service entschuldigen, in dem verschiedene Muster zum Aufbau von Organisationsstrukturen in DevOps beschrieben sind, werden Sie verstehen, dass dies ein Antipattern ist.<\/p>\n

Wenn ein DevOps-Team \u00fcber mehrere Jahre hinweg st\u00e4ndig existiert, ist das ein gro\u00dfer Fehler, denn DevOps bedeutet Kommunikation zwischen Abteilungen, Geschwindigkeit und Effizienz.<\/p><\/blockquote>\n

\nWenn das Team zwischen den Abteilungen besteht, nur um etwas anderes Separates zu tun, und lange existiert, entsteht ein zus\u00e4tzlicher Barrier. Jetzt muss der Programmierer, anstatt direkt zum Administrator zu gehen, um das Problem zu kl\u00e4ren, zuerst das DevOps-Team kontaktieren, das dann weitervermittelt.<\/p>\n

Deshalb muss zu Beginn ein tempor\u00e4res Team gebildet werden.<\/strong>. Sie wird bedingt f\u00fcr sechs Monate, maximal ein Jahr bestehen, je nach gestellter Aufgabe, nur um eine von uns gew\u00e4hlte Einschr\u00e4nkung zu beseitigen. Danach wird sie sterben. Wenn wir den n\u00e4chsten Punkt w\u00e4hlen, an dem wir starke Schmerzen haben, und feststellen, dass wir daf\u00fcr auch ein separates Team ben\u00f6tigen, dann werden wir es wieder ins Leben rufen. Aber solche Teams sollten nicht \u201epermanent\u201c existieren \u2014 sonst st\u00f6ren sie nur die Kommunikation und \u00fcbernehmen ganz separate Aufgaben, nur um etwas zu tun. Diese Aufgaben k\u00f6nnten \u00fcberhaupt nicht mit DevOps und der Transformation verbunden sein. Warum sollten wir diese Aufgabe nicht an bestehende Abteilungen abgeben?<\/p>\n

Warum ein tempor\u00e4res Team ben\u00f6tigt wird<\/h3>\n

\nKonflikt mit den aktuellen Prozessen<\/strong>. DevOps-Transformation bedeutet nicht nur eine Ver\u00e4nderung der Technologien und Werkzeuge, die wir verwenden, sondern auch eine Ver\u00e4nderung des Arbeitsprozesses, des Denkens und der Werte selbst. Wenn das Team so arbeitet, wie es es gewohnt ist, wird es nicht in der Lage sein, andere Ans\u00e4tze auszuprobieren.<\/p>\n

Diese Personen m\u00fcssen nach anderen Regeln leben: alle KPIs im Unternehmen ignorieren, weil sie versuchen, anders zu arbeiten. Tempor\u00e4re Teams werden keine Antr\u00e4ge ausf\u00fcllen, um einen Server zu erhalten, sondern direkt zu der Abteilung gehen, die daf\u00fcr zust\u00e4ndig ist, und verlangen, dass sie ihnen als Erstes das geben, was sie brauchen, weil es eine vorrangige Aufgabe ist und weil sie versuchen, anders zu leben. Das Team hat einen vollst\u00e4ndigen Konflikt mit allen aktuellen Prozessen. Damit die bestehenden Arbeitsmethoden sie nicht st\u00f6ren und sie auch anderen nicht im Weg stehen, isolieren wir diese Personen und bilden ein separates Team.<\/p>\n

Vermeidung von B\u00fcrokratie in Experimenten<\/strong>. In tempor\u00e4ren Teams gibt es keine B\u00fcrokratie, sie f\u00fcllen keine Arbeitszeiterfassungen aus, und sie berichten nicht an die Manager. Es ist eine absolut separate Welt, in der Menschen anders leben und denken und ganz andere Dinge tun. Man sollte sie nicht unn\u00f6tig st\u00f6ren.<\/p>\n

Ununterbrochene Arbeit am Service<\/strong>. Im ersten Punkt haben wir etwas ausgew\u00e4hlt, an dem wir experimentieren werden. Experimente und die Suche nach besseren Arbeitsweisen sind gut, aber wir m\u00f6chten auch Funktionen erstellen. Wenn das gesamte Team anstelle von Funktionen mit der Transformation besch\u00e4ftigt ist, werden wir anfangen, Einnahmen zu verlieren, und Fehler werden lange bestehen bleiben \u2014 das brauchen wir nicht. Die Schaffung eines tempor\u00e4ren Teams erm\u00f6glicht es uns, zu experimentieren, ohne die Arbeit am Produkt zu unterbrechen.<\/p>\n

Keine Zeit mit Arbeitsaufgaben verschwenden<\/strong>. Es geht wieder um das Produkt. Es dauert lange, bis das Team andere Werkzeuge ausprobiert und so weiter. Damit die Menschen die Werkzeuge beherrschen, sie zu implementieren beginnen und sie richtig nutzen k\u00f6nnen, wird es mindestens ein halbes Jahr dauern. Wenn sie sich auch noch mit dem Produkt besch\u00e4ftigen, wird das halbe Jahr astronomisch lang. Wenn die Leute am Produkt arbeiten, besch\u00e4ftigen sie sich erneut mit den alten Prozessen \u2013 das brauchen wir nicht.<\/p>\n

Deshalb ziehen wir aus verschiedenen Abteilungen Menschen in ein separates Team, das die Transformation des Services \u00fcbernimmt. Dadurch funktioniert der Service, entwickelt sich weiter und wir k\u00f6nnen gleichzeitig einige Experimente damit durchf\u00fchren.<\/p>\n

Das tempor\u00e4re Team k\u00fcmmert sich ausschlie\u00dflich um die DevOps-Transformation \u2013 das Entfernen der Einschr\u00e4nkungen, die wir gefunden haben, und sonst nichts.<\/p><\/blockquote>\n

\nDas Team besteht aus vielseitigen Menschen<\/strong>. Das bedeutet, dass wir nicht nur Entwickler genommen haben. Wir sind nicht einfach in den Service gekommen und haben ein halbes Team herausgenommen \u2013 nein, wir haben Menschen aus verschiedenen Abteilungen<\/strong>. Vor ein paar Punkten haben wir verschiedene Abteilungen und verschiedene Mitarbeiter identifiziert, die mit dem zu transformierenden Service in Verbindung stehen. Aus ihnen bilden wir ein Team, denn es muss vielseitig sein \u2013 wir werden sowohl den Testprozess, den Entwicklungsprozess als auch den Wartungsprozess des Services \u00e4ndern. Unterschiedliche Kompetenzen sind erforderlich.<\/p>\n

Normalerweise nehmen wir einen Entwickler, einen Tester und einen Ingenieur \u2013 jeweils einen, und zusammen mit ihnen denken wir uns L\u00f6sungen aus, die es erm\u00f6glichen, anders zu leben.<\/p>\n

Es w\u00e4re w\u00fcnschenswert, dass diese Leute Autorit\u00e4t in der Organisation haben<\/strong>. Es k\u00f6nnte notwendig sein, einen Konservativen zu engagieren, auch wenn wir das nicht wollen. Wenn wir ein gro\u00dfes Unternehmen haben, werden nicht alle an unser Vorhaben glauben, und einige k\u00f6nnten uns Steine in den Weg legen, zum Beispiel indem sie keinen Stand bereitstellen. Hier wird Autorit\u00e4t ben\u00f6tigt \u2013 eine respektierte Person mit viel Erfahrung, die sich gutes Ansehen bei den Kollegen erarbeitet hat. Die Autorit\u00e4t des Mitarbeiters im Team wird die Aufgabe und die Arbeit des tempor\u00e4ren Teams erleichtern. Die Leute denken dann:<\/p>\n

\u2014 Aha, dieser coole Typ, den wir alle kennen und lieben, ist dabei \u2013 offenbar gibt es im DevOps etwas, das es wert ist, betrachtet zu werden!<\/em><\/p>\n

Ziele setzen<\/h2>\n

\nWir haben Leute versammelt, einen Service ausgew\u00e4hlt, die Einschr\u00e4nkungen betrachtet und festgelegt, auf welche Personen wir Einfluss nehmen werden. Jetzt m\u00fcssen wir ein Ziel setzen, und das sollte ganz klar sein nach SMART<\/strong> \u2013 genau, wie wir es gerne haben.<\/p>\n

Spezifisch \u2014 konkret<\/strong>.<\/p>\n

Messbar \u2014 messbar<\/strong>. Dies ist ein sehr wichtiger Punkt im SMART-Modell. Wenn Sie etwas nicht messen k\u00f6nnen, k\u00f6nnen Sie es nicht \u00e4ndern und nicht verstehen, was und wie Sie es besser oder schlechter gemacht haben.<\/p>\n

Erreichbar \u2014 erreichbar<\/strong>. Ber\u00fccksichtigen Sie Ihre spezifischen Gegebenheiten. Wenn Sie ein Unternehmen mit langj\u00e4hriger Geschichte und einer gro\u00dfen Last an Verpflichtungen sind, das einmal im Jahr eine Version des Produkts herausbringt, k\u00f6nnen Sie nicht in sechs Monaten erreichen, dass neue Versionen des Produkts jede Stunde ver\u00f6ffentlicht werden. Das wird nicht funktionieren. Setzen Sie sich daher ein realistisches Ziel, das innerhalb eines angemessenen Zeitrahmens erreichbar ist.<\/p>\n

Relevant \u2014 relevant. <\/strong>Wir beseitigen nur dasjenige Hindernis, das wirklich unsere aktuellen Ziele verfolgt.<\/p>\n

Zeitlich begrenzt \u2014 zeitlich begrenzt<\/strong>. Wenn es keinen Abgabetermin gibt, wird das Team sich mit allem M\u00f6glichen besch\u00e4ftigen: 15 Technologien statt 3 ausprobieren, riesige Berichte schreiben, nutzlose Forschungen durchf\u00fchren, ihre Implementierung bis zur Perfektion ausfeilen, wenn das Ziel bereits erreicht ist.<\/p>\n

Das Ziel bestimmen wir mithilfe der Value Stream Map \u2014 wir versammeln alle Beteiligten und zeichnen. Aber diesmal zeichnen wir basierend auf der vorherigen Value Stream Map, um das zu skizzieren, was wir erreichen m\u00f6chten.<\/p>\n

\"Wie
\n
\nWir identifizieren ein Hindernis, das wir jetzt sofort beseitigen werden \u2014 das wird das Team tun. Zum Beispiel nehme ich die Wartezeit vom fertigen Release bis zur Bereitstellung in der Produktion \u2014 das ist das h\u00e4ufigste Hindernis, mit dem Menschen zu Beratern kommen.<\/p>\n

Basierend darauf setzen wir die Aufgabe fest: Wir m\u00f6chten, dass die Wartezeit zwischen dem fertigen Release und dem Start im Einsatz maximal eine Stunde betr\u00e4gt.<\/p>\n

Beispielaufgaben.<\/p>\n