Wie man mit der DevOps-Transformation beginnt

Wenn Sie nicht genau wissen, was DevOps ist, hier eine kurze Zusammenfassung. DevOps bezeichnet eine Reihe von Praktiken, die die Ängste der Ingenieure verringern und die Anzahl der Software-Fehler reduzieren. In der Regel verkürzen sie die Markteinführungszeit — den Zeitraum von der Idee bis zur Auslieferung des Endprodukts an die Kunden, was schnelle geschäftliche Experimente ermöglicht..

Wie startet man eine DevOps-Transformation? Kurz gefasst: Wählen 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äres Team, das die Transformation zunächst vorantreibt, und geben Sie ihm eine Aufgabe. Wiederholen Sie den Zyklus so oft wie nötig.

Ein detaillierter Plan zur DevOps-Transformation mit Beispielen und Anleitungen finden Sie im Folgenden — in der Ausarbeitung Vortrag Andrei Alexandrow — eines Ingenieurs von Express42, einem Unternehmen, das Beratung zur Einführung von DevOps anbietet und diesen Prozess beschleunigt, da es bereits eine Karte der Stolpersteine erstellt hat. Wenn Sie denken, dass Sie keine Transformation benötigen oder Ihre Spezifikationen keine DevOps-Praktiken erfordern, nutzen Sie den Bericht als Anleitung zur Identifizierung und Beseitigung von Einschränkungen.

Wenn Sie sich mit der Frage der DevOps-Transformation beschäftigen, dann haben Sie ein großes 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.

Auswahl des Dienstes

Der Plan steht, beginnen wir mit dem ersten Schritt – der Auswahl des Dienstes. Das erste Kriterium – Lebensdauer: es gibt alte Dienste – Legacy, und neue. Man kann sowohl mit den einen als auch mit den anderen beginnen.

Einen jungen Dienst auszuwählen, macht Sinn. Er ist neu, es gibt noch keinen etablierten Arbeitsprozess im Team, das sich darum kümmert. Es gibt keinen Berichtsberg an technischem Schulden, den man ständig reparieren muss. Wir können damit machen, was wir wollen.

Im Fall eines alten Dienstes gibt es Probleme, die damit verbunden sind, dass Änderungen immer schwierig sind. Dort gibt es bereits eine Reihe ernster Einschränkungen, aber vielleicht sind es Menschen, die bereit sind, alles über den Haufen zu werfen – sie sind müde und möchten etwas anders machen, weil es schmerzhaft ist.

Die Arbeit mit einem alten Dienst schafft einen starken Präzedenzfall In Ihrem Unternehmen kann sich etwas ändern. Wenn Sie einen neuen Service implementiert haben, der 100 Mal pro Stunde reibungslos läuft, könnten die Leute in Ihrer Firma sagen:

„Das ist doch ein neuer Service! Das war alles so einfach, probieren Sie mal etwas mit unserem alten Kram zu machen.“

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üttern, was nur geht.Sie experimentieren und wissen nicht, wohin Sie kommen, welche Technologien Sie nutzen wollen und wo und welche Fallstricke in den Prozessen auftauchen könnten. Daher ist es einfacher, etwas Neues zu ändern.

Wenn Sie alles selbst machen und im Unternehmen keine ernsthafte Kompetenz vorhanden ist, wählen Sie einen neuen Service. Wenn Sie einen externen Berater kennen und die Mittel haben, entscheiden Sie sich für den alten.

Es gibt Services, die einfach nur eine Benutzeroberfläche 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ärung schwierig sein. Auch hier haben wir eine Wahl.

Wir arbeiten entweder mit einem kritischen Service., aber bereits darunter leiden wir, es schafft Einschränkungen, oder wir arbeiten mit der Benutzeroberfläche. Dies ist das zweite Auswahlkriterium. Ebenso besteht die Möglichkeit, einen erfahrenen Berater hinzuzuziehen — wir arbeiten mit der schwierigen Variante.

Aber selbst in diesem Fall würde ich nicht raten, dies zu tun, denn solange es kein Verständnis dafür gibt, womit man arbeitet und in welche Richtung man transformieren möchte, 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äche zu arbeiten, deren Ausfall nicht kritisch ist.

Gleich weiter zum Serviceteam. Mit denen, die sich um diesen Service kümmern, müssen wir ständig arbeiten und in sehr engem Kontakt interagieren.

Die Menschen im Team lassen sich grob in zwei Kategorien einteilen: Konservative — leben in der alten Welt oder wissen einfach nichts über DevOps, und Innovatoren, die alle modernen Praktiken vorantreiben. Letztere haben nicht immer das nötige Wissen, aber sie sind zumindest bereit dafür.

Einerseits sind die Konservativen erfahrene Fachleute: lange im Unternehmen, kennen alle Details, jedoch haben sie möglicherweise kein Wissen über moderne Praktiken. Andererseits stehen die Innovatoren, die zwar etwas gehört haben, aber vermutlich nicht lange im Unternehmen sind. Mit wem ist es besser, zusammenzuarbeiten?

Mit den Konservativen müssen wir in jedem Fall interagieren, da sie den Service verwalten. Wir müssen mit ihnen kommunizieren, die Spezifikationen des Services klären, was möglich ist und was nicht. Wir sind von ihren Beratungen abhängig. Wahrscheinlich werden wir ihnen Aufgaben übertragen müssen, weil sie ihren Service besser kennen. Daher ist es wichtig, welches Team letztendlich unser Ansprechpartner sein wird.

Es ist sinnvoll, das Team mit Innovatoren auszuwählen, da Konservative möglicherweise die Entwicklung behindern könnten.

In der Praxis ist es oft so, dass konservative Personen über erhebliche Erfahrung verfügen, jedoch kein Verständnis dafür haben, wie es weitergeht. Sie befürchten einfach, nach der Transformation und Umstrukturierung des Services aufgrund ihrer vermeintlichen Überflüssigkeit entlassen zu werden. Manchmal sabotieren sie die Arbeit auch nur aufgrund von Unverständnis darüber, was geschieht.

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

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ür die Anzahl der erledigten Aufgabenpflichten zugewiesen haben, und aus irgendeinem Grund eine bestimmte Aufgabe nicht in den KPIs enthalten ist, werden sie überhaupt nichts tun. Insofern hätten sie recht, denn sie riskieren dann, ihren Bonus zu verlieren.

Mit Innovatoren ist es einfacher – sie sind loyaler.Sie haben schon etwas gehört, wollen irgendwo hingehen, deshalb helfen sie. Wir brauchen Leute, die bereit sind, zunächst zu leiden: Wenn sich der Service ändert, werden alle Probleme und Stolpersteine die Innovatoren als Pioniere erleben. Innovatoren wollen immer das Neueste und Beste, auch wenn sie dabei Schwierigkeiten haben.

Die Konservativen kann man später in seinen Glauben führen. Wenn Sie zeigen, dass Sie einen Teil geändert haben und alles gut funktioniert, werden sie wahrscheinlich auch testen wollen und die neue DevOps-Religion annehmen.

Lassen Sie uns zusammenfassen. Wenn wir die gesamte Transformation intern in unserem Unternehmen durchführen, wählen wir einen neuen Dienst, idealerweise mit einer einfachen Benutzeroberfläche, damit wir nicht allzu sehr unter möglichen Ausfällen leiden.

Wenn es die Möglichkeit 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älle gesehen und wissen bereits, wie es richtig geht und in welche Richtung man überhaupt gehen sollte.

Wer ist involviert?

Wir müssen alle finden, die irgendeine Verbindung zum Dienst haben: Entwickler, Tester, Administratoren, Sicherheitsexperten, Manager und möglicherweise Product Owners. Obwohl Product Owners keine technischen Fachleute sind, haben sie dennoch einen Bezug zum Dienst: Sie treffen Entscheidungen und setzen Aufgaben.

Jeden, der Entscheidungen trifft und Einfluss darauf hat, was mit dem Dienst passiert, müssen wir finden, kennenlernen und kontaktieren.

Wozu brauchen wir sie? Um zu wissen, mit wem wir verhandeln müssen.. Während der Transformation, wenn sich die gewohnte Arbeitsweise mit dem Service ändert, wird es trotzdem Turbulenzen geben. Eine Zeit lang wird es Störungen geben, während wir neue Ansätze testen. Die Menschen müssen darauf vorbereitet sein und damit einverstanden sein.

Dann müssen wir eine Value Stream Map erstellen, und ohne diese Personen wird das nicht möglich sein, denn nur sie haben ein vollständiges Bild von den Abläufen. Eine einzelne Person kennt niemals alles, was mit dem Service geschieht.

Sie werden Personen für das Team empfehlen. Später werden wir besprechen, warum ein eigenes Team erforderlich ist. Wir müssen Personen aus bestehenden Abteilungen einbeziehen. Diejenigen, die mit dem Service zu tun haben, können Kollegen empfehlen, die in unsere Richtung denken, die uns helfen können und die die nötige Kompetenz besitzen.

Danach bringen wir all diese Personen aus verschiedenen Abteilungen in einen Raum und beginnen, eine Value Stream Map zu erstellen.

Wir erstellen eine Value Stream Map

Die Value Stream Map ist ein Diagramm oder eine Karte, die den Wertstrom zum Kunden darstellt.. Es ist der gesamte Prozess von der Ideenfindung bis zur Umsetzung, einschließlich aller Zwischenphasen und wie der Wert letztendlich zu unseren Kunden gelangt.

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

Metriken

In der Literatur zur Value Stream Map gibt es viele verschiedene Metriken, aber für den Anfang genügen uns drei.

Lead Time — Wartezeit — die Zeit, die wir warten. Beispielsweise wartet der Tester darauf, dass eine Testumgebung verfügbar wird, und kann in dieser Zeit nichts tun.

Wertschöpfungszeit — Zeit der produktiven Arbeit — die Zeit, die wir in einem bestimmten Schritt aufwenden, um einen Endwert für den Benutzer zu schaffen. Zum Beispiel, wenn der Tester seinen Test gestartet hat und damit beginnt, etwas zu überprüfen. Das ist die produktive Zeit, in der wir tatsächlich an dem Produkt arbeiten. Das ist es, wofür die Kunden bezahlen — für qualitativ hochwertige Software.

%C/A — Prozentsatz der akzeptierten Arbeit. Wir haben eine Phase — die Entwicklung, die zweite Phase — die Tests. Wie viele Funktionen haben die Tester von den Entwicklern akzeptiert, und dieser Prozentsatz wird ermittelt.

So sieht unsere Karte ungefähr aus.

Je nach Organisationsstruktur, Anzahl der Abteilungen und Ihrem Tätigkeitsbereich kann dies unterschiedlich aussehen. Im Allgemeinen wird die Karte jedoch zwei Phasen aufweisen: die Idee und Analyse. In dieser Phase werden Daten erwartet, beispielsweise eine Lead Time von 2 Wochen und eine Value Added Time von 2 Tagen.

Mit Metriken decken wir alle Phasen umfassend ab.

Backlog – wie viele Aufgaben liegen nach der Ideenfindung durch die Analysten bereit.

Entwicklung – wie viele Wochen die Entwickler auf Klarstellungen zu Aufgaben, Ständen oder Ausrüstung gewartet haben – 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 übernommen. Sie glauben, dass die restlichen 20 % unzureichend definierte Anforderungen haben und haben sie zur Überarbeitung zurückgeschickt.

Testen. 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ächlich etwas testen, und %C/A = 40 %. – Nur 40 % des Codes oder der Features, die die Entwickler geschickt haben, hielten die Tester für angemessen. Alles andere gefiel ihnen aus irgendeinem Grund nicht.

Ich werde nicht im Detail darauf eingehen, wie man diese Messungen durchführt, am Ende des Artikels empfehle ich Literatur, durch die man mehr darüber erfahren kann.

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ätzungen sind nicht immer korrekt. Daher ist es besser, selbst zu messen.

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 überhaupt 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 – 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ären, nicht mit unseren Blicken auf die Aufgabe in Jira hängen geblieben wären und nicht begonnen hätten, sie schrittweise zu verfolgen, hätten wir geglaubt, dass alles wunderbar ist und kein Problem besteht.

Daher müssen die Messungen in der Tat selbst durchgeführt 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.

Temporäres Team

Viele Unternehmen, die sich entschieden haben, DevOps einzuführen, bilden ein Team, das jedoch nicht temporär, sondern über 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.

Wenn ein DevOps-Team über mehrere Jahre hinweg dauerhaft existiert, ist das ein gravierender Fehler, denn DevOps dreht sich um die Kommunikation zwischen Abteilungen, um Geschwindigkeit und Effizienz.

Wenn das Team zwischen den Abteilungen existiert, nur um etwas anderes zu erledigen und lange besteht, schafft es zusätzliche Barrieren. Jetzt muss der Programmierer, anstatt sofort zum Administrator zu gehen, um ein Problem zu lösen, zuerst an die DevOps-Abteilung wenden, und diese wiederum wird sich weiter darum kümmern.

Deshalb muss zunächst ein temporäres Team gegründet werden.. Sie wird voraussichtlich sechs Monate, maximal ein Jahr, bestehen, abhängig von der gestellten Aufgabe, nur um eine ausgewählte Einschränkung zu beseitigen. Danach wird sie verschwinden. Wenn wir den nächsten Punkt wählen, an dem wir großen Schmerz empfinden, und feststellen, dass wir dafür ebenfalls ein separates Team benötigen, werden wir es wieder aufbauen. Aber solche Teams sollten nicht dauerhaft bestehen — sie stören lediglich die Kommunikation und übernehmen völlig andere Aufgaben, nur um etwas zu tun. Diese Aufgaben können sich überhaupt nicht auf DevOps oder Transformation beziehen. Warum sollten wir diese Aufgabe nicht an bestehende Abteilungen übergeben?

Warum ein temporäres Team nötig ist

Konflikt mit aktuellen Prozessen. DevOps-Transformation bedeutet nicht nur eine Änderung der Technologien und Werkzeuge, die wir verwenden, sondern auch eine Änderung 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ätze auszuprobieren.

Diese Personen müssen nach anderen Regeln leben: Sie ignorieren alle KPI im Unternehmen, da sie versuchen, anders zu arbeiten. Temporäre Teams werden keine Anträge ausfüllen, um einen Server zu erhalten, sondern sich direkt an die verantwortliche Abteilung wenden mit der Forderung, ihnen zuerst das zu geben, was sie benötigen, denn das ist eine prioritäre Aufgabe und sie versuchen, anders zu leben. Das Team hat einen vollständigen Konflikt mit allen aktuellen Prozessen. Um sicherzustellen, dass die bestehenden Arbeitsmethoden sie nicht stören und sie nicht andere stören, isolieren wir diese Personen und bilden ein eigenes Team.

Vermeidung von Bürokratie in Experimenten. In temporären Teams gibt es keine Bürokratie, sie füllen keine Arbeitszeitberichte aus, sie berichten nicht an die Manager. Das ist eine völlig eigene Welt, in der die Menschen anders leben und denken und sich mit ganz anderen Dingen beschäftigen. Man sollte sie nicht zusätzlich stören.

Ununterbrochene Arbeit am Dienst. Im ersten Punkt haben wir etwas ausgewählt, an dem wir experimentieren werden. Experimente und die Suche nach besseren Arbeitsweisen sind wichtig, doch wir möchten 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 – das wollen wir vermeiden. Die Bildung eines temporären Teams ermöglicht es uns, zu experimentieren, ohne die Arbeit am Produkt zu stoppen.

Keine Zeit für Arbeitsaufgaben verschwenden. Es geht wieder um das Produkt. Es benötigt viel Zeit, damit das Team andere Werkzeuge und Ähnliches ausprobiert. Damit die Leute die Werkzeuge beherrschen, sie implementieren und richtig verwenden können, braucht es mindestens ein halbes Jahr. Wenn sie gleichzeitig auch am Produkt arbeiten müssen, dehnt sich dieses halbe Jahr enorm aus. Arbeiten die Leute am Produkt, sind sie wieder mit den alten Prozessen beschäftigt – das wollen wir vermeiden.

Deshalb wählen wir Leute aus verschiedenen Abteilungen aus, um ein separates Team zu bilden, das sich mit der Transformation des Services beschäftigen wird. Dadurch bleibt der Service aktiv, entwickelt sich weiter, und wir können gleichzeitig einige Experimente darauf durchführen.

Das temporäre Team konzentriert sich ausschließlich auf die DevOps-Transformation – die Beseitigung der Einschränkungen, die wir identifiziert haben, und nichts Weiteres.

Das Team besteht aus vielseitigen Fachleuten. Das bedeutet, dass wir nicht nur Entwickler ausgewählt haben. Wir sind nicht in den Service gegangen und haben dort ein ganzes Team übernommen – nein, wir haben Menschen aus verschiedenen Abteilungen. 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 – wir werden sowohl den Testprozess, den Entwicklungsprozess als auch den Serviceprozess verändern. Es sind unterschiedliche Kompetenzen erforderlich.

In der Regel wählen wir einen Entwickler, einen Tester und einen Ingenieur – jeweils einen – und entwickeln gemeinsam mit ihnen eine Lösung, die ein anderes Arbeiten ermöglicht.

Es wäre wünschenswert, dass diese Personen in der Organisation Autorität genießen.. Möglicherweise müssen wir einen Berater hinzuziehen, auch wenn wir das nicht möchten. Wenn wir ein großes Unternehmen haben, werden nicht alle an unser Vorhaben glauben, und einige könnten uns Steine in den Weg legen, indem sie beispielsweise keinen Stand zur Verfügung stellen. Hier wird ein "Autoritätsperson" benötigt – eine respektierte Person mit viel Erfahrung, die sich das Vertrauen der Kollegen erarbeitet hat. Die Autorität eines Mitarbeiters im Team erleichtert die Aufgabe und die Arbeit des temporären Teams. Die Leute werden denken:

— Ah, dieser coole Typ, den wir alle kennen und lieben, ist dabei – offensichtlich gibt es im DevOps-Bereich etwas, das es wert ist, näher betrachtet zu werden!

Wir setzen ein Ziel

Wir haben Leute versammelt, einen Dienst ausgewählt, die Einschränkungen betrachtet und festgelegt, auf welche Personen wir Einfluss nehmen können. Jetzt müssen wir ein Ziel setzen, und das sollte ganz klar nach SMART sein – genau wie wir es mögen.

Specific – spezifisch.

Measurable – messbar. Dies ist ein sehr wichtiger Punkt im SMART. Wenn Sie etwas nicht messen können, können Sie es nicht ändern und nicht verstehen, was und wie Sie es besser oder schlechter gemacht haben.

Achievable – erreichbar. 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önnen Sie nicht innerhalb von sechs Monaten erreichen, dass neue Versionen jede Stunde veröffentlicht werden. Das ist nicht möglich. Setzen Sie sich daher ein realistisches Ziel, das innerhalb eines akzeptablen Zeitrahmens erreicht werden kann.

Relevant — relevant. Wir beseitigen nur die Einschränkung, die wirklich unsere aktuellen Ziele verfolgt.

Time Limited — zeitlich begrenzt.. Wenn es keine Frist gibt, wird das Team sich mit allem Möglichen beschäftigen: 15 Technologien statt 3 auszuprobieren, riesige Berichte zu schreiben, nutzlose Forschungen durchzuführen oder ihre Implementierung bis zur Perfektion zu bringen, nachdem das Ziel bereits erreicht ist.

Wir nehmen das Ziel mithilfe einer Value Stream Map — wir versammeln alle Beteiligten und zeichnen. Aber diesmal zeichnen wir auf der Grundlage der vorherigen Value Stream Map, was wir erreichen wollen.

Wir identifizieren eine Einschränkung, die wir sofort beseitigen werden — das wird das Team übernehmen. Zum Beispiel habe ich die Wartezeit vom fertigen Release bis zu dessen Deployment in die Produktion gewählt — das ist die häufigste Einschränkung, mit der Menschen zu Beratern kommen.

Basierend darauf definieren wir eine Aufgabe: Wir möchten, dass die Zeitspanne zwischen dem fertigen Release und dem Einsatz maximal eine Stunde beträgt.

Beispiele für Aufgaben.

• Die Testleadzeit von vier Tagen auf eine Stunde reduzieren.
• Die wertschöpfende Zeit für Tests von zwei Tagen auf drei Stunden reduzieren.
• Die Deploy-Zeit von fünf Stunden auf zehn Minuten verkürzen.
• Die C/A von 50 % auf 95 % erhöhen, das bedeutet, die Anzahl der Funktionen, die von den Testern angenommen werden, zu steigern und damit die Qualität der Arbeit der Entwickler zu verbessern.

Die Beispiele für Aufgaben sind nicht willkürlich gewählt – sie basieren auf Messungen, die wir beim Erstellen der Value Stream Map durchgeführt haben.

Wir setzen eine ähnliche Aufgabe für unser Team und ein Zeitlimit. Abhängig davon, wie gut es in Ihrem Unternehmen läuft, setzen Sie unterschiedliche Fristen. Im Durchschnitt dauert es etwa ein halbes Jahr, um ein Hindernis zu beseitigen, wenn die Leute dies zum ersten Mal tun und noch nicht wissen, mit welchen Technologien und wie genau sie das Problem lösen werden.

Kurze Planung

Also, unser Team ist gegründet, es hat ein Ziel, die Leute beginnen mit der Arbeit. Ein wichtiger Punkt ist die kurze Planung der Arbeit: Sprints von ein bis zwei Wochenund nicht mehr, messbare Verbesserungen jede Woche und Kurskorrektur.

Zum Beispiel verwenden wir oft den Ansatz moving-moving, bei dem sich das gesamte Team zu Beginn jeder Woche trifft und aufschreibt, was jeder tun wird. Nach einer Woche überprüfen wir, was erledigt wurde und was nicht, und falls etwas nicht erledigt wurde, überlegen wir warum und was als Nächstes zu tun ist.

Sprints ermöglichen es, den Kurs rechtzeitig zu korrigieren.

Eine oder zwei Wochen probieren wir etwas aus: Technologien, Ansätze, Arbeitsweisen; danach messen wir erneut und schauen – hat sich die Situation mit diesem Ansatz verbessert oder verschlechtert? Wenn es schlechter ist, bedeutet das, dass wir in die falsche Richtung gehen. Dann müssen wir den Kurs anpassen: eine andere Aufgabe setzen, eine andere Technologie verwenden oder etwas Ähnliches tun. Kurze Sprints von 1-2 Wochen erleichtern es, flexibel zu bleiben und rechtzeitig von schlechten Entscheidungen abzuwägen.

Teilen Sie Erfolge

Das Team erzielt Erfolge, ob klein oder groß – es spielt keine Rolle, es gibt immer ein Ergebnis. Jeder sollte über dieses Ergebnis informiert sein: sowohl diejenigen, die in DevOps tätig sind, als auch die benachbarten Abteilungen. In einer idealen Welt sollte dies tatsächlich alle Personen im Unternehmen erreichen..

Warum? Wenn wir nicht nur einen Teil des Unternehmens transformieren, ein einzelnes Hindernis beseitigen, sondern alles insgesamt, damit das Unternehmen flexibel wird, der Code schnell zum Kunden gelangt und nichts kaputtgeht, müssen alle der Idee von DevOps gegenüber loyal sein. Sie können keinen Ansatz auf Dienstleistungen und Teams anwenden, die kategorisch dagegen sind.

Um Loyalität zu schaffen, müssen wir allen mitteilen, dass wir dies ausprobiert haben – wir haben Ergebnisse, probieren Sie es auch! Das wird das Interesse und die Loyalität zu dem, was wir tun, steigern; die Leute werden anfangen, direkt jetzt selbst etwas auszuprobieren. Die Erfahrung zeigt, dass, wenn wir erzählen, was wir ausprobiert haben und was wir erreicht haben, andere Teams beginnen zu fragen, wie und was wir gemacht haben. Sie sehen sich die Implementierungen, den Code, die Dokumentation an, kommen mit Fragen und versuchen, etwas bei sich zu ändern.

Es ist wichtig, darüber zu berichten, was Ihnen gelungen ist. So überzeugen Sie die konservativen Kollegen, die alles beim Alten belassen wollten, sich in Innovatoren zu verwandeln.

Gesamt

Wählen Sie einen Dienst, als Ausgangspunkt – der Ort, an dem wir mit den Veränderungen im Unternehmen beginnen. Identifizieren Sie alle, die mit dem Dienst zu tun haben. und zusammen mit ihnen bauen wir eine Value Stream Map, messen und beobachten, wo es Einschränkungen gibt.

Wir bilden ein neues temporäres Team, das die gestellte Aufgabe lösen wird. Basierend auf den Messungen und der Value Stream Map zeichnen wir eine neue Karte, auf der wir die Einschränkung hervorheben, die wir angehen werden. Auf Grundlage dieser Einschränkung setzen wir eine Aufgabe, um die sich das Team kümmern wird. Die Aufgabe sollte unbedingt SMART sein — spezifisch, messbar, relevant für die aktuellen Aufgaben und zeitlich begrenzt.

Wir wiederholen den Prozess, bis wir alle unsere Dienstleistungen auf das erforderliche Niveau transformiert und alle Einschränkungen beseitigt haben.

Bonus. Nützliche Materialien

Für diejenigen, die DevOps selbstständig angehen möchten.

Projekt 'Phoenix'

Der Originaltitel lautet „The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win“. Dies ist ein Roman über DevOps — die Geschichte, wie ein Mitarbeiter zum Leiter einer Abteilung gemacht wurde, die ständig in der Krise steckte. Der neuen Leitung wurde folgende Aufgabe gegeben:

— Du hast mehrere Jahre Zeit, um alles zu verbessern, damit wir endlich unser Produkt schnell und effektiv an unsere Kunden liefern können.

„Projekt Phoenix“. Ein Roman darüber, wie DevOps das Leben zum Besseren verändert – ein Buch für alle Führungskräfte, denn genau diese Menschen treffen die Entscheidungen, die das Unternehmen betreffen. Wenn Sie Ingenieur oder Programmierer sind und möchten, dass in Ihrer Firma Bewegung und Transformation stattfinden – kaufen Sie das Buch und verschenken Sie es an die Geschäftsleitung. Dieser Roman erklärt alles und lässt sich schnell und leicht lesen.

DevOps-Handbuch

Ein etwas anspruchsvolleres Buch. Es wurde vor einigen Jahren in Englisch unter dem Titel „The DevOps Handbook: How to create world-class agility, reliability, and security in Technology organizations“ veröffentlicht, ist aber jetzt auch auf Deutsch erhältlich. Dies ist ein echtes Handbuch – ein praktischer Leitfaden: wie man Messungen durchführt, was eine Value Stream Map ist und warum sie notwendig ist, wohin man sich bewegen sollte und in welcher Reihenfolge. Das Buch ist genau das Richtige für diejenigen, die alles selbst in die Hand nehmen wollen. Das Wichtigste ist, dass es Beispiele aus der Erfahrung anderer Unternehmen enthält.

Zum Beispiel wird beschrieben, wie ein Unternehmen eine Value Stream Map erstellt hat und herausfand, dass das Problem nicht im Produkt lag, sondern darin, dass die Kassiererin zwischen dem Geschäft und dem benachbarten Büro hin und her ging, um das Produkt zu nutzen. Anstatt das Problem mit der Software zu lösen, kauften sie ihren Verkäufern Tablets, und jetzt müssen die Leute nirgendwo mehr hingehen; alle Tätigkeiten erfolgen am Arbeitsplatz. Fazit: Die Value Stream Map lässt sich nicht nur auf Software, sondern auf alle Prozesse in der Organisation anwenden.

Beschleunigen

Vollständiger Titel: „Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations“. Dies ist das nächste Level – Hardcore. Das Buch wurde letztes Jahr veröffentlicht, bisher nur auf Englisch, und handelt von Forschung. Die Autoren – Nicole Forsgren, Jez Humble und Gene Kim – haben über viele Jahre hinweg verschiedene Praktiken in verschiedenen Unternehmen angewendet und untersucht, welche Praktiken wie und auf was Einfluss nehmen.

Im zweiten Kapitel, das sich mit Messungen beschäftigt, werden das Value Stream Mapping, die von mir genannten Kennzahlen und viele weitere Aspekte erwähnt, und der Messprozess wird ausführlich beschrieben. Die Autoren führen Messungen mithilfe von Umfragen und Selbstverfolgung von Aufgaben durch. Es wird detailliert erläutert, welche Kennzahlen korrekt zu messen sind, welche nicht, sowie menschliche Fehler bei den Messungen. Wenn Sie Schwierigkeiten bei den Messungen haben, wenden Sie sich an das zweite Kapitel des Buches „Accelerate“. Wenn Ihr Team viele Praktiken hat, aber unklar ist, welche Praktiken jetzt angewendet werden sollten, welche später, welche effektiv sind und welche nicht – lesen Sie, das Buch bietet alle Antworten.

Transformation - ein Thema an der Schnittstelle von DevOps und Management. Irgendwo in diesem Überschneidungsbereich von Entwicklung, Betrieb und Testing befinden sich die Themen, die wir zu diskutieren versuchen auf DevOpsConf, auch die gleiche Integration ist notwendig, um ein hochwertiges Produkt zu erstellen – das Hauptthema QaulityConf. Das Management auf dem Festival RIT++ wurden Whale Rider – bedeutet, dass alle Ideen zur Transformation dort gesammelt werden. Schließen Sie sich uns am 27. und 28. Mai an, wir werden integrieren und transformieren.

Quelle: habr.com