{"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 mit der DevOps-Transformation beginnt","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Wenn Sie nicht genau wissen, was DevOps ist, hier eine kurze Zusammenfassung. DevOps bezeichnet eine Reihe von Praktiken, die die \u00c4ngste der Ingenieure verringern<\/strong> und die Anzahl der Software-Fehler reduzieren. In der Regel verk\u00fcrzen sie die Markteinf\u00fchrungszeit<\/strong> \u2014 den Zeitraum von der Idee bis zur Auslieferung des Endprodukts an die Kunden, was schnelle gesch\u00e4ftliche Experimente erm\u00f6glicht.<\/strong>.<\/p>\n

Wie startet man eine DevOps-Transformation? Kurz gefasst: W\u00e4hlen Sie den Service, mit dem Sie den Prozess beginnen wollen, identifizieren Sie die beteiligten Personen, erstellen Sie eine Value Stream Map, bilden Sie ein tempor\u00e4res Team, das die Transformation zun\u00e4chst vorantreibt, und geben Sie ihm eine Aufgabe. Wiederholen Sie den Zyklus so oft wie n\u00f6tig.<\/p>\n

\"Wie<\/p>\n

Ein detaillierter Plan zur DevOps-Transformation mit Beispielen und Anleitungen finden Sie im Folgenden \u2014 in der Ausarbeitung Vortrag<\/a><\/noindex> Andrei Alexandrow<\/b> \u2014 eines Ingenieurs von Express42, einem Unternehmen, das Beratung zur Einf\u00fchrung von DevOps anbietet und diesen Prozess beschleunigt, da es bereits eine Karte der Stolpersteine erstellt hat. Wenn Sie denken, dass Sie keine Transformation ben\u00f6tigen oder Ihre Spezifikationen keine DevOps-Praktiken erfordern, nutzen Sie den Bericht als Anleitung zur Identifizierung und Beseitigung von Einschr\u00e4nkungen.
\n<\/a><\/noindex>
\nWenn Sie sich mit der Frage der DevOps-Transformation besch\u00e4ftigen, dann haben Sie ein gro\u00dfes Unternehmen, und es ist notwendig, diesen Prozess schrittweise in die gesamte Struktur zu skalieren. Solange es die Notwendigkeit gibt, das Team zu transformieren oder ein bestimmtes Hindernis zu beseitigen, kann der unten stehende Algorithmus wiederholt werden.<\/p>\n

Auswahl des Dienstes<\/h2>\n

\nDer Plan steht, beginnen wir mit dem ersten Schritt \u2013 der Auswahl des Dienstes. Das erste Kriterium \u2013 Lebensdauer<\/strong>: es gibt alte Dienste \u2013 Legacy, und neue. Man kann sowohl mit den einen als auch mit den anderen beginnen.<\/p>\n

Einen jungen Dienst auszuw\u00e4hlen, macht Sinn<\/strong>. Er ist neu, es gibt noch keinen etablierten Arbeitsprozess im Team, das sich darum k\u00fcmmert. Es gibt keinen Berichtsberg an technischem Schulden, den man st\u00e4ndig reparieren muss. Wir k\u00f6nnen damit machen, was wir wollen.<\/p>\n

Im Fall eines alten Dienstes gibt es Probleme, die damit verbunden sind, dass \u00c4nderungen immer schwierig sind<\/strong>. Dort gibt es bereits eine Reihe ernster Einschr\u00e4nkungen, aber vielleicht sind es Menschen, die bereit sind, alles \u00fcber den Haufen zu werfen \u2013 sie sind m\u00fcde und m\u00f6chten etwas anders machen, weil es schmerzhaft ist.<\/p>\n

Die Arbeit mit einem alten Dienst schafft einen starken Pr\u00e4zedenzfall<\/strong> In Ihrem Unternehmen kann sich etwas \u00e4ndern. Wenn Sie einen neuen Service implementiert haben, der 100 Mal pro Stunde reibungslos l\u00e4uft, k\u00f6nnten die Leute in Ihrer Firma sagen:<\/p>\n

\u201eDas ist doch ein neuer Service! Das war alles so einfach, probieren Sie mal etwas mit unserem alten Kram zu machen.\u201c<\/em><\/p>\n

Einen Legacy-Service macht es Sinn, in eine Transformation zu bringen, wenn Sie dies zusammen mit jemandem tun, zum Beispiel wenn Sie einen externen Berater eingeladen haben. Seien wir ehrlich, die Transformation wird alles ersch\u00fcttern, was nur geht.<\/strong>Sie experimentieren und wissen nicht, wohin Sie kommen, welche Technologien Sie nutzen wollen und wo und welche Fallstricke in den Prozessen auftauchen k\u00f6nnten. Daher ist es einfacher, etwas Neues zu \u00e4ndern.<\/p>\n

Wenn Sie alles selbst machen und im Unternehmen keine ernsthafte Kompetenz vorhanden ist, w\u00e4hlen Sie einen neuen Service. Wenn Sie einen externen Berater kennen und die Mittel haben, entscheiden Sie sich f\u00fcr den alten.<\/p><\/blockquote>\n

\nEs gibt Services, die einfach nur eine Benutzeroberfl\u00e4che bieten, wie eine einfache Website oder eine mobile App. Aber es gibt auch ernsthafte Dinge wie das Billing. Wenn mit dem Billing etwas schiefgeht, wird die Kl\u00e4rung schwierig sein. Auch hier haben wir eine Wahl.<\/p>\n

Wir arbeiten entweder mit einem kritischen Service.<\/strong>, aber bereits darunter leiden wir, es schafft Einschr\u00e4nkungen, oder wir arbeiten mit der Benutzeroberfl\u00e4che<\/strong>. Dies ist das zweite Auswahlkriterium. Ebenso besteht die M\u00f6glichkeit, einen erfahrenen Berater hinzuzuziehen \u2014 wir arbeiten mit der schwierigen Variante.<\/p>\n

Aber selbst in diesem Fall w\u00fcrde ich nicht raten, dies zu tun, denn solange es kein Verst\u00e4ndnis daf\u00fcr gibt, womit man arbeitet und in welche Richtung man transformieren m\u00f6chte, ist es keine gute Idee, eine kritische Sache zu nehmen und sie durcheinander zu bringen. Daher ziehen wir in diesem Fall vor, mit der Benutzeroberfl\u00e4che zu arbeiten, deren Ausfall nicht kritisch ist.<\/p>\n

Gleich weiter zum Serviceteam<\/b>. Mit denen, die sich um diesen Service k\u00fcmmern, m\u00fcssen wir st\u00e4ndig arbeiten und in sehr engem Kontakt interagieren.<\/p>\n

Die Menschen im Team lassen sich grob in zwei Kategorien einteilen: Konservative<\/strong> \u2014 leben in der alten Welt oder wissen einfach nichts \u00fcber DevOps, und Innovatoren<\/strong>, die alle modernen Praktiken vorantreiben. Letztere haben nicht immer das n\u00f6tige Wissen, aber sie sind zumindest bereit daf\u00fcr.<\/p>\n

Einerseits sind die Konservativen erfahrene Fachleute: lange im Unternehmen, kennen alle Details, jedoch haben sie m\u00f6glicherweise kein Wissen \u00fcber moderne Praktiken. Andererseits stehen die Innovatoren, die zwar etwas geh\u00f6rt haben, aber vermutlich nicht lange im Unternehmen sind. Mit wem ist es besser, zusammenzuarbeiten?<\/p>\n

Mit den Konservativen m\u00fcssen wir in jedem Fall interagieren, da sie den Service verwalten. Wir m\u00fcssen mit ihnen kommunizieren, die Spezifikationen des Services kl\u00e4ren, was m\u00f6glich ist und was nicht. Wir sind von ihren Beratungen abh\u00e4ngig. Wahrscheinlich werden wir ihnen Aufgaben \u00fcbertragen m\u00fcssen, weil sie ihren Service besser kennen. Daher ist es wichtig, welches Team letztendlich unser Ansprechpartner sein wird.<\/p>\n

Es ist sinnvoll, das Team mit Innovatoren auszuw\u00e4hlen, da Konservative m\u00f6glicherweise die Entwicklung behindern k\u00f6nnten.\n<\/p><\/blockquote>\n

\nIn der Praxis ist es oft so, dass konservative Personen \u00fcber erhebliche Erfahrung verf\u00fcgen, jedoch kein Verst\u00e4ndnis daf\u00fcr haben, wie es weitergeht. Sie bef\u00fcrchten einfach, nach der Transformation und Umstrukturierung des Services aufgrund ihrer vermeintlichen \u00dcberfl\u00fcssigkeit entlassen zu werden. Manchmal sabotieren sie die Arbeit auch nur aufgrund von Unverst\u00e4ndnis dar\u00fcber, was geschieht.<\/p>\n

Ich hatte einmal einen Fall, in dem ein Kollege alles m\u00f6gliche reparierte, weil es angeblich wichtiger war als das, was wir gerade taten. Wir setzen uns das Ziel, heute diesen Teil umzusetzen \u2013 nein, am anderen Ende der Welt gibt es ein Feuer, also gehen wir das reparieren. Mit solchen Leuten zu arbeiten, ist schwierig.<\/p>\n

Die Leute im Team der Konservativen lassen Aufgaben oft liegen oder schieben sie bis zur letzten Minute auf. Und wenn, Gott bewahre, Sie einen Fehler gemacht haben und ihnen KPIs f\u00fcr die Anzahl der erledigten Aufgabenpflichten zugewiesen haben, und aus irgendeinem Grund eine bestimmte Aufgabe nicht in den KPIs enthalten ist, werden sie \u00fcberhaupt nichts tun. Insofern h\u00e4tten sie recht, denn sie riskieren dann, ihren Bonus zu verlieren.<\/p>\n

Mit Innovatoren ist es einfacher \u2013 sie sind loyaler.<\/strong>Sie haben schon etwas geh\u00f6rt, wollen irgendwo hingehen, deshalb helfen sie. Wir brauchen Leute, die bereit sind, zun\u00e4chst zu leiden: Wenn sich der Service \u00e4ndert, werden alle Probleme und Stolpersteine die Innovatoren als Pioniere erleben. Innovatoren wollen immer das Neueste und Beste, auch wenn sie dabei Schwierigkeiten haben.<\/p>\n

Die Konservativen kann man sp\u00e4ter in seinen Glauben f\u00fchren. Wenn Sie zeigen, dass Sie einen Teil ge\u00e4ndert haben und alles gut funktioniert, werden sie wahrscheinlich auch testen wollen und die neue DevOps-Religion annehmen.<\/p>\n

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

Lassen Sie uns zusammenfassen. Wenn wir die gesamte Transformation intern in unserem Unternehmen durchf\u00fchren, w\u00e4hlen wir einen neuen Dienst, idealerweise mit einer einfachen Benutzeroberfl\u00e4che, damit wir nicht allzu sehr unter m\u00f6glichen Ausf\u00e4llen leiden.<\/p><\/blockquote>\n

\nWenn es die M\u00f6glichkeit gibt, einen externen Berater hinzuzuziehen, sollten wir stattdessen den alten Dienst verwenden, bei dem wir bereits Schwierigkeiten haben. Personen, die bereits lange in verschiedenen Unternehmen an Transformationen gearbeitet haben, haben unterschiedliche F\u00e4lle gesehen und wissen bereits, wie es richtig geht und in welche Richtung man \u00fcberhaupt gehen sollte.<\/p>\n

Wer ist involviert?<\/h2>\n

\nWir m\u00fcssen alle finden, die irgendeine Verbindung zum Dienst haben: Entwickler, Tester, Administratoren, Sicherheitsexperten, Manager und m\u00f6glicherweise Product Owners. Obwohl Product Owners keine technischen Fachleute sind, haben sie dennoch einen Bezug zum Dienst: Sie treffen Entscheidungen und setzen Aufgaben.<\/p>\n

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

Jeden, der Entscheidungen trifft und Einfluss darauf hat, was mit dem Dienst passiert, m\u00fcssen wir finden, kennenlernen und kontaktieren.<\/p><\/blockquote>\n

\nWozu brauchen wir sie? Um zu wissen, mit wem wir verhandeln m\u00fcssen.<\/strong>. W\u00e4hrend der Transformation, wenn sich die gewohnte Arbeitsweise mit dem Service \u00e4ndert, wird es trotzdem Turbulenzen geben. Eine Zeit lang wird es St\u00f6rungen geben, w\u00e4hrend wir neue Ans\u00e4tze testen. Die Menschen m\u00fcssen darauf vorbereitet sein und damit einverstanden sein.<\/p>\n

Dann m\u00fcssen wir eine Value Stream Map erstellen, und ohne diese Personen wird das nicht m\u00f6glich sein, denn nur sie haben ein vollst\u00e4ndiges Bild von den Abl\u00e4ufen. Eine einzelne Person kennt niemals alles, was mit dem Service geschieht.<\/p>\n

Sie werden Personen f\u00fcr das Team empfehlen. Sp\u00e4ter werden wir besprechen, warum ein eigenes Team erforderlich ist. Wir m\u00fcssen Personen aus bestehenden Abteilungen einbeziehen. Diejenigen, die mit dem Service zu tun haben, k\u00f6nnen Kollegen empfehlen, die in unsere Richtung denken, die uns helfen k\u00f6nnen und die die n\u00f6tige Kompetenz besitzen.<\/p>\n

Danach bringen wir all diese Personen aus verschiedenen Abteilungen in einen Raum und beginnen, eine Value Stream Map zu erstellen.<\/p>\n

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

\nDie Value Stream Map ist ein Diagramm oder eine Karte, die den Wertstrom zum Kunden darstellt.<\/strong>. Es ist der gesamte Prozess von der Ideenfindung bis zur Umsetzung, einschlie\u00dflich aller Zwischenphasen und wie der Wert letztendlich zu unseren Kunden gelangt.<\/p>\n

Die Value Stream Map ist notwendig, um Alle Phasen der Entwicklung visualisieren<\/strong>, Probleme identifizieren durch Messungen im aktuellen Prozess und beginnen, diese Probleme zu beheben, und ein erstes Ziel setzen<\/strong>. Hier werden wir wirklich etwas in die Tat umsetzen.<\/p>\n

Metriken<\/h3>\n

\nIn der Literatur zur Value Stream Map gibt es viele verschiedene Metriken, aber f\u00fcr den Anfang gen\u00fcgen uns drei.<\/p>\n

Lead Time \u2014 Wartezeit<\/strong> \u2014 die Zeit, die wir warten. Beispielsweise wartet der Tester darauf, dass eine Testumgebung verf\u00fcgbar wird, und kann in dieser Zeit nichts tun.<\/p>\n

Wertsch\u00f6pfungszeit \u2014 Zeit der produktiven Arbeit<\/strong> \u2014 die Zeit, die wir in einem bestimmten Schritt aufwenden, um einen Endwert f\u00fcr den Benutzer zu schaffen. Zum Beispiel, wenn der Tester seinen Test gestartet hat und damit beginnt, etwas zu \u00fcberpr\u00fcfen. Das ist die produktive Zeit, in der wir tats\u00e4chlich an dem Produkt arbeiten. Das ist es, wof\u00fcr die Kunden bezahlen \u2014 f\u00fcr qualitativ hochwertige Software.<\/p>\n

%C\/A \u2014 Prozentsatz der akzeptierten Arbeit. <\/strong>Wir haben eine Phase \u2014 die Entwicklung, die zweite Phase \u2014 die Tests. Wie viele Funktionen haben die Tester von den Entwicklern akzeptiert, und dieser Prozentsatz wird ermittelt.<\/p>\n

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

\"Wie
\n
\nJe nach Organisationsstruktur, Anzahl der Abteilungen und Ihrem T\u00e4tigkeitsbereich kann dies unterschiedlich aussehen. Im Allgemeinen wird die Karte jedoch zwei Phasen aufweisen: die Idee <\/strong>und Analyse<\/strong>. In dieser Phase werden Daten erwartet, beispielsweise eine Lead Time von 2 Wochen und eine Value Added Time von 2 Tagen.<\/p>\n

Mit Metriken decken wir alle Phasen umfassend ab.<\/p><\/blockquote>\n

\nBacklog<\/strong> \u2013 wie viele Aufgaben liegen nach der Ideenfindung durch die Analysten bereit.<\/p>\n

Entwicklung<\/strong> \u2013 wie viele Wochen die Entwickler auf Klarstellungen zu Aufgaben, St\u00e4nden oder Ausr\u00fcstung gewartet haben \u2013 egal, aber sie warten auf etwas. Zum Beispiel dauert es 4 Tage, um ein Feature zu implementieren. Hier erscheint die Metrik %C\/A. Die Entwickler haben nur 80 % der Aufgaben aus dem Backlog \u00fcbernommen. Sie glauben, dass die restlichen 20 % unzureichend definierte Anforderungen haben und haben sie zur \u00dcberarbeitung zur\u00fcckgeschickt.<\/p>\n

Testen<\/strong>. In der Grafik ist LT mit 4 Tagen festgelegt. Zum Beispiel warteten die Tester auf die Freigabe des Teststands, VA von 2 Tagen, in denen sie tats\u00e4chlich etwas testen, und %C\/A = 40 %. \u2013 Nur 40 % des Codes oder der Features, die die Entwickler geschickt haben, hielten die Tester f\u00fcr angemessen. Alles andere gefiel ihnen aus irgendeinem Grund nicht.<\/p>\n

Ich werde nicht im Detail darauf eingehen, wie man diese Messungen durchf\u00fchrt, am Ende des Artikels empfehle ich Literatur, durch die man mehr dar\u00fcber erfahren kann.<\/p>\n

Das Einzige, was ich empfehlen kann, ist, den Leuten nicht zu glauben, die mit Ihnen eine Value Stream Map 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 einmal den Fall, dass wir bei der Abteilung Operations nachfragten, wie lange es dauert, eine neue Funktion in die Produktion zu bringen. Man antwortete uns, dass es 10 Minuten dauere, und wir dachten, warum wir \u00fcberhaupt in dieses Unternehmen gekommen sind. Es stellte sich heraus, dass die 10 Minuten die Laufzeit eines Skripts waren, das den Code auf den Server bringt. Aber vorher liegt das Release drei Tage auf dem Server und verstaubt \u2013 die Aufgabe, die bereitgestellt werden muss, liegt im Backlog. Das bedeutet, dass es vor der Bereitstellung eine Wartezeit gibt, in der das Projekt einfach liegen bleibt. Wenn wir nicht mit einem Notizbuch gekommen w\u00e4ren, nicht mit unseren Blicken auf die Aufgabe in Jira h\u00e4ngen geblieben w\u00e4ren und nicht begonnen h\u00e4tten, sie schrittweise zu verfolgen, h\u00e4tten wir geglaubt, dass alles wunderbar ist und kein Problem besteht.<\/p>\n

Daher m\u00fcssen die Messungen in der Tat selbst durchgef\u00fchrt werden, idealerweise nicht nur einmal, um eine realistische Vorstellung zu bekommen. Je nach Value Stream Map entscheiden Sie, von wo aus Sie beginnen und was zuerst verbessert werden sollte.<\/p>\n

Tempor\u00e4res Team<\/h2>\n

\nViele Unternehmen, die sich entschieden haben, DevOps einzuf\u00fchren, bilden ein Team, das jedoch nicht tempor\u00e4r, sondern \u00fcber mehrere Jahre bestehen bleibt. Wenn Sie den DevOps-Service ansprechen, der verschiedene Muster zur Strukturierung der Organisation in DevOps beschreibt, werden Sie feststellen, dass dies ein Antimuster ist.<\/p>\n

Wenn ein DevOps-Team \u00fcber mehrere Jahre hinweg dauerhaft existiert, ist das ein gravierender Fehler, denn DevOps dreht sich um die Kommunikation zwischen Abteilungen, um Geschwindigkeit und Effizienz.<\/p><\/blockquote>\n

\nWenn das Team zwischen den Abteilungen existiert, nur um etwas anderes zu erledigen und lange besteht, schafft es zus\u00e4tzliche Barrieren. Jetzt muss der Programmierer, anstatt sofort zum Administrator zu gehen, um ein Problem zu l\u00f6sen, zuerst an die DevOps-Abteilung wenden, und diese wiederum wird sich weiter darum k\u00fcmmern.<\/p>\n

Deshalb muss zun\u00e4chst ein tempor\u00e4res Team gegr\u00fcndet werden.<\/strong>. Sie wird voraussichtlich sechs Monate, maximal ein Jahr, bestehen, abh\u00e4ngig von der gestellten Aufgabe, nur um eine ausgew\u00e4hlte Einschr\u00e4nkung zu beseitigen. Danach wird sie verschwinden. Wenn wir den n\u00e4chsten Punkt w\u00e4hlen, an dem wir gro\u00dfen Schmerz empfinden, und feststellen, dass wir daf\u00fcr ebenfalls ein separates Team ben\u00f6tigen, werden wir es wieder aufbauen. Aber solche Teams sollten nicht dauerhaft bestehen \u2014 sie st\u00f6ren lediglich die Kommunikation und \u00fcbernehmen v\u00f6llig andere Aufgaben, nur um etwas zu tun. Diese Aufgaben k\u00f6nnen sich \u00fcberhaupt nicht auf DevOps oder Transformation beziehen. Warum sollten wir diese Aufgabe nicht an bestehende Abteilungen \u00fcbergeben?<\/p>\n

Warum ein tempor\u00e4res Team n\u00f6tig ist<\/h3>\n

\nKonflikt mit aktuellen Prozessen<\/strong>. DevOps-Transformation bedeutet nicht nur eine \u00c4nderung der Technologien und Werkzeuge, die wir verwenden, sondern auch eine \u00c4nderung des Arbeitsprozesses, des Denkens und der Werte. Wenn das Team weiterhin 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: Sie ignorieren alle KPI im Unternehmen, da sie versuchen, anders zu arbeiten. Tempor\u00e4re Teams werden keine Antr\u00e4ge ausf\u00fcllen, um einen Server zu erhalten, sondern sich direkt an die verantwortliche Abteilung wenden mit der Forderung, ihnen zuerst das zu geben, was sie ben\u00f6tigen, denn das ist eine priorit\u00e4re Aufgabe und sie versuchen, anders zu leben. Das Team hat einen vollst\u00e4ndigen Konflikt mit allen aktuellen Prozessen. Um sicherzustellen, dass die bestehenden Arbeitsmethoden sie nicht st\u00f6ren und sie nicht andere st\u00f6ren, isolieren wir diese Personen und bilden ein eigenes Team.<\/p>\n

Vermeidung von B\u00fcrokratie in Experimenten<\/strong>. In tempor\u00e4ren Teams gibt es keine B\u00fcrokratie, sie f\u00fcllen keine Arbeitszeitberichte aus, sie berichten nicht an die Manager. Das ist eine v\u00f6llig eigene Welt, in der die Menschen anders leben und denken und sich mit ganz anderen Dingen besch\u00e4ftigen. Man sollte sie nicht zus\u00e4tzlich st\u00f6ren.<\/p>\n

Ununterbrochene Arbeit am Dienst<\/strong>. Im ersten Punkt haben wir etwas ausgew\u00e4hlt, an dem wir experimentieren werden. Experimente und die Suche nach besseren Arbeitsweisen sind wichtig, doch wir m\u00f6chten auch neue Funktionen entwickeln. Wenn das gesamte Team sich an der Transformation statt an den Features beteiligt, fangen wir an, Einnahmen zu verlieren, und Bugs werden lange bestehen bleiben \u2013 das wollen wir vermeiden. Die Bildung eines tempor\u00e4ren Teams erm\u00f6glicht es uns, zu experimentieren, ohne die Arbeit am Produkt zu stoppen.<\/p>\n

Keine Zeit f\u00fcr Arbeitsaufgaben verschwenden<\/strong>. Es geht wieder um das Produkt. Es ben\u00f6tigt viel Zeit, damit das Team andere Werkzeuge und \u00c4hnliches ausprobiert. Damit die Leute die Werkzeuge beherrschen, sie implementieren und richtig verwenden k\u00f6nnen, braucht es mindestens ein halbes Jahr. Wenn sie gleichzeitig auch am Produkt arbeiten m\u00fcssen, dehnt sich dieses halbe Jahr enorm aus. Arbeiten die Leute am Produkt, sind sie wieder mit den alten Prozessen besch\u00e4ftigt \u2013 das wollen wir vermeiden.<\/p>\n

Deshalb w\u00e4hlen wir Leute aus verschiedenen Abteilungen aus, um ein separates Team zu bilden, das sich mit der Transformation des Services besch\u00e4ftigen wird. Dadurch bleibt der Service aktiv, entwickelt sich weiter, und wir k\u00f6nnen gleichzeitig einige Experimente darauf durchf\u00fchren.<\/p>\n

Das tempor\u00e4re Team konzentriert sich ausschlie\u00dflich auf die DevOps-Transformation \u2013 die Beseitigung der Einschr\u00e4nkungen, die wir identifiziert haben, und nichts Weiteres.<\/p><\/blockquote>\n

\nDas Team besteht aus vielseitigen Fachleuten<\/strong>. Das bedeutet, dass wir nicht nur Entwickler ausgew\u00e4hlt haben. Wir sind nicht in den Service gegangen und haben dort ein ganzes Team \u00fcbernommen \u2013 nein, wir haben Menschen aus verschiedenen Abteilungen<\/strong>. Vor einigen Punkten haben wir verschiedene Abteilungen und Mitarbeiter gefunden, die mit dem transformierten Service in Zusammenhang stehen. Aus ihnen setzen wir unser Team zusammen, denn es muss vielseitig sein \u2013 wir werden sowohl den Testprozess, den Entwicklungsprozess als auch den Serviceprozess ver\u00e4ndern. Es sind unterschiedliche Kompetenzen erforderlich.<\/p>\n

In der Regel w\u00e4hlen wir einen Entwickler, einen Tester und einen Ingenieur \u2013 jeweils einen \u2013 und entwickeln gemeinsam mit ihnen eine L\u00f6sung, die ein anderes Arbeiten erm\u00f6glicht.<\/p>\n

Es w\u00e4re w\u00fcnschenswert, dass diese Personen in der Organisation Autorit\u00e4t genie\u00dfen.<\/strong>. M\u00f6glicherweise m\u00fcssen wir einen Berater hinzuziehen, auch wenn wir das nicht m\u00f6chten. Wenn wir ein gro\u00dfes Unternehmen haben, werden nicht alle an unser Vorhaben glauben, und einige k\u00f6nnten uns Steine in den Weg legen, indem sie beispielsweise keinen Stand zur Verf\u00fcgung stellen. Hier wird ein \"Autorit\u00e4tsperson\" ben\u00f6tigt \u2013 eine respektierte Person mit viel Erfahrung, die sich das Vertrauen der Kollegen erarbeitet hat. Die Autorit\u00e4t eines Mitarbeiters im Team erleichtert die Aufgabe und die Arbeit des tempor\u00e4ren Teams. Die Leute werden denken:<\/p>\n

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

Wir setzen ein Ziel<\/h2>\n

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

Specific \u2013 spezifisch<\/strong>.<\/p>\n

Measurable \u2013 messbar<\/strong>. Dies ist ein sehr wichtiger Punkt im SMART. 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

Achievable \u2013 erreichbar<\/strong>. Passen Sie dies an Ihre Spezifikationen an. Wenn Sie ein Unternehmen mit langer Geschichte und vielen Verpflichtungen sind, das einmal im Jahr eine Produktversion herausbringt, k\u00f6nnen Sie nicht innerhalb von sechs Monaten erreichen, dass neue Versionen jede Stunde ver\u00f6ffentlicht werden. Das ist nicht m\u00f6glich. Setzen Sie sich daher ein realistisches Ziel, das innerhalb eines akzeptablen Zeitrahmens erreicht werden kann.<\/p>\n

Relevant \u2014 relevant. <\/strong>Wir beseitigen nur die Einschr\u00e4nkung, die wirklich unsere aktuellen Ziele verfolgt.<\/p>\n

Time Limited \u2014 zeitlich begrenzt.<\/strong>. Wenn es keine Frist gibt, wird das Team sich mit allem M\u00f6glichen besch\u00e4ftigen: 15 Technologien statt 3 auszuprobieren, riesige Berichte zu schreiben, nutzlose Forschungen durchzuf\u00fchren oder ihre Implementierung bis zur Perfektion zu bringen, nachdem das Ziel bereits erreicht ist.<\/p>\n

Wir nehmen das Ziel mithilfe einer Value Stream Map \u2014 wir versammeln alle Beteiligten und zeichnen. Aber diesmal zeichnen wir auf der Grundlage der vorherigen Value Stream Map, was wir erreichen wollen.<\/p>\n

\"Wie
\n
\nWir identifizieren eine Einschr\u00e4nkung, die wir sofort beseitigen werden \u2014 das wird das Team \u00fcbernehmen. Zum Beispiel habe ich die Wartezeit vom fertigen Release bis zu dessen Deployment in die Produktion gew\u00e4hlt \u2014 das ist die h\u00e4ufigste Einschr\u00e4nkung, mit der Menschen zu Beratern kommen.<\/p>\n

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

Beispiele f\u00fcr Aufgaben.<\/p>\n