Wie man eine DevOps-Transformation beginnt

Wenn Sie nicht verstehen, was DevOps ist, hier ist eine kurze Zusammenfassung. DevOps ist eine Sammlung von Praktiken, die die Ängste der Ingenieure verringern und die Anzahl der Ausfälle in der Softwareproduktion reduzieren. In der Regel verkürzen sie die Markteinführungszeit – den Zeitraum von der Idee bis zur Auslieferung des Endprodukts an die Kunden, was es ermöglicht, schnell Geschäftsexperimente durchzuführen..

Wie beginnt man eine DevOps-Transformation? Kurz gesagt: Wir wählen 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ünden ein temporäres Team, das zunächst für die Transformation zuständig ist, und setzen ihm eine Aufgabe. Wir wiederholen den Zyklus die erforderliche Anzahl von Malen.

Ein detaillierter Plan für die DevOps-Transformation mit Beispielen und Anleitungen im Folgenden – in der Ausführung Vortrag Andrej Alexandrow – 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ür Sie nicht erforderlich ist oder dass Ihre Spezifikationen keine DevOps-Praktiken unterstützen, verwenden Sie den Bericht als Anleitung zur Identifizierung und Beseitigung von Einschränkungen.

Wenn Sie sich um die DevOps-Transformation sorgen, haben Sie ein großes Unternehmen und müssen diesen Prozess allmählich auf die gesamte Struktur ausweiten. Solange es notwendig ist, das Team zu transformieren oder eine Einschränkung zu beseitigen, kann der folgende Algorithmus wiederholt werden.

Die Auswahl des Services

Der Plan steht fest, beginnen wir mit dem ersten Schritt – der Auswahl des Services. Das erste Kriterium ist die Lebensdauer: es gibt alte Services – Legacy, und neue. Man kann sowohl mit alten als auch mit neuen starten.

Es ist sinnvoll, einen neuen Service auszuwählen.Er ist frisch, es gibt noch keinen etablierten Arbeitsprozess im Team, das sich um ihn kümmert. Rund um ihn gibt es keinen großen technischen Schuldenberg, man muss ihn nicht ständig reparieren. Wir können damit machen, was wir wollen.

Bei einem alten Service gibt es Probleme, die damit zu tun haben, dass Änderungen immer schwierig sind.Es gibt bereits eine Reihe von ernsthaften Einschränkungen, aber möglicherweise beschäftigen sich damit Menschen, die bereit sind, alles umzukrempeln – sie sind müde und möchten etwas anders machen, weil es schmerzhaft ist.

Die Arbeit mit einem alten Service schafft einen starken Präzedenzfall in Ihrem Unternehmen – man kann etwas ändern. Wenn Sie einen neuen Service geändert haben, der 100 Mal pro Stunde in die Produktion geht und alles gut läuft, sagen die Leute in Ihrem Unternehmen vielleicht:

Das ist doch ein neuer Service! Damit war alles einfach, versuchen Sie mal, mit unserem alten Schrott etwas zu machen.

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öglich ist.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 ändern.

Wenn Sie alles selbst machen und im Unternehmen keine ernsthaften Kompetenzen vorhanden sind – nehmen Sie den neuen Service. Wenn Sie einen externen Berater kennen und Mittel vorhanden sind – wählen Sie den alten.

Es gibt Services, die einfach nur eine Benutzeroberfläche 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ären. Hier haben wir auch eine Wahl.

Wir arbeiten entweder mit einem kritischen Service, aber wir leiden bereits darunter, er schafft Einschränkungen, oder wir arbeiten mit einer Benutzeroberfläche. Das ist das zweite Auswahlkriterium. Ähnlich gibt es die Möglichkeit, einen erfahrenen Berater hinzuzuziehen – wir arbeiten mit der schweren Variante.

Aber selbst in diesem Fall würde ich nicht raten, so vorzugehen, denn solange kein Verständnis dafür besteht, womit man arbeiten soll und in welche Richtung man transformieren möchte, ist es keine gute Idee, eine kritische Sache zu nehmen und sie zu durchwühlen. Deshalb ziehen wir in diesem Fall vor, mit einer Benutzeroberfläche zu arbeiten, deren Ausfall nicht kritisch ist.

Lassen Sie uns nun das Team des Servicesbetrachten. Mit denjenigen, die sich um diesen Service kümmern, müssen wir ständig arbeiten und in sehr engem Kontakt stehen.

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 mitbringen. Die zweiten haben nicht immer das nötige Wissen, sind aber wenigstens bereit dazu.

Auf der einen Seite sind Konservative erfahrene Leute: lange im Unternehmen, mit tiefen Kenntnissen, aber sie wissen nichts über die Praktiken. Auf der anderen Seite sind es Innovatoren, die etwas gehört haben, aber wahrscheinlich nicht sehr lange im Unternehmen arbeiten. Mit wem von ihnen ist es besser zu arbeiten?

Mit den Konservativen müssen wir auf jeden Fall interagieren, da dies ihr Service ist. Wir müssen mit ihnen kommunizieren, die Besonderheiten des Services klären, was so gemacht werden kann und was anders. Wir sind von ihren Beratungen abhängig. Sicherlich müssen wir ihnen etwas anvertrauen, weil sie ihren Service besser kennen. Daher ist es wichtig, mit welchem Team wir am Ende in Kontakt treten werden.

Es ist sinnvoll, Innovatoren in das Team zu wählen, denn die Konservativen könnten uns einen Streich spielen.

In der Praxis kommt es häufig vor, dass konservative Menschen erhebliches Wissen haben, aber kein Verständnis dafür, wie es weitergeht. Sie haben einfach Angst, dass sie nach der Transformation und Umgestaltung des Services entlassen werden, weil sie nicht mehr benötigt werden. Manchmal sabotieren sie einfach die Arbeit, weil sie nicht verstehen, was passiert.

Ich hatte einen Fall, als ein Typ aus dem Team alles Mögliche reparierte, weil es angeblich kritischer war als das, was wir gerade machen. Wir setzen die Aufgabe: implementiere heute dieses Stück — nein, am anderen Ende der Welt brennt es, wir gehen es reparieren. Mit solchen Menschen ist es schwer zu arbeiten.

Die Leute aus dem Team der Konservativen kümmern 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ür die Anzahl der erfüllten Aufgaben auferlegt haben, und ein Teil aus irgendeinem Grund nicht in den KPI enthalten ist, dann werden sie überhaupt nichts tun. Im Grunde genommen haben sie recht, denn sie verlieren dann ihre Prämie.

Mit Innovatoren ist es einfacher — sie sind loyaler.Sie haben schon etwas gehört, wollen irgendwohin gehen, deshalb werden sie helfen. Wir brauchen Menschen, die bereit sind, in der ersten Zeit zu leiden: Wenn sich der Service ändert, werden alle Schwierigkeiten und Stolpersteine die Innovatoren auf sich nehmen, als wären sie Pioniere. Innovatoren wollen alles Neueste und Modische und bereit zu leiden.

Konservative können später in ihren Glauben umgewandelt werden. Wenn Sie zeigen, dass Sie einen Teil geändert haben und alles gut läuft, werden sie wahrscheinlich auch ausprobieren wollen und die neue DevOps-Religion annehmen.

Zusammenfassend. Wenn wir die gesamte Transformation in unserem Unternehmen selbst durchführen, wählen wir: einen neuen Service, vorzugsweise mit einer einfachen Benutzeroberfläche, um nicht allzu sehr unter seinen Ausfällen zu leiden, und ein Team von Innovatoren.

Wenn es möglich 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äftigt waren, haben verschiedene Fälle gesehen und verstehen bereits, wie man es richtig macht und in welche Richtung man überhaupt gehen sollte.

Wer ist beteiligt?

Wir müssen wirklich alle finden, die irgendeine Beziehung zum Dienst haben: Entwickler, Tester, Administratoren, Sicherheitsfachleute, Manager und möglicherweise Product Owners. Obwohl Product Owners keine Techniker sind, haben sie eine Beziehung zum Dienst: Sie treffen Entscheidungen und setzen Aufgaben.

Wir müssen alle finden, die irgendeine Entscheidung treffen und Einfluss auf das haben, was mit dem Dienst passiert, sie kennenlernen und mit ihnen sprechen.

Wozu benötigen wir sie? Um zu wissen, mit wem wir verhandeln sollen.. Während der Transformation, wenn sich das gewohnte Arbeitsprinzip mit dem Dienst ändert, wird es dennoch zu Störungen kommen. Eine Zeit lang wird es Ausfälle geben, während wir neue Ansätze testen. Die Menschen müssen darauf vorbereitet sein und damit einverstanden.

Danach müssen 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ß niemals alles, was mit dem Dienst passiert.

Sie werden Leute für das Team empfehlen. Später werden wir besprechen, warum ein separates Team benötigt wird. Wir müssen Menschen aus bestehenden Abteilungen einbeziehen. Diejenigen, die eine Beziehung zum Dienst haben, können Kollegen empfehlen, die in unsere Richtung denken, uns helfen können und die Kompetenz haben, die wir benötigen.

Danach versammeln wir all diese Leute aus verschiedenen Abteilungen in einem Raum und beginnen mit dem Bau der Value Stream Map.

Wir erstellen eine Value Stream Map.

Die Value Stream Map ist ein Diagramm oder eine Karte, die den Wertefluss bis zum Kunden darstellt.. Es handelt sich um den gesamten Prozess von der Ideenfindung bis zur Umsetzung, einschließlich aller Zwischenetappen und wie der Wert letztlich zu unseren Kunden gelangt.

Die Value Stream Map wird benötigt, um alle Entwicklungsphasen zu visualisieren,, Probleme durch Messungen, die im aktuellen Prozess vorhanden sind, zu lokalisieren und diese Probleme zu beginnen zu beheben, und das anfängliche Ziel festzulegen.. Das ist der Ort, an dem wir anfangen werden, tatsächlich etwas zu tun.

Metriken

In der Literatur zur Value Stream Map sind viele verschiedene Metriken beschrieben, aber für den Anfang reichen uns drei.

Lead Time — Verzögerung/Wartezeit — Zeit, in der wir auf etwas warten. Zum Beispiel wartet der Tester, bis der Stand für Tests verfügbar ist, und kann in dieser Zeit nichts machen.

Wertschöpfungszeit — Zeit nützlicher Arbeit — die Zeit, die wir in einer bestimmten Phase aufgebracht haben, um einen Endwert für den Benutzer zu schaffen. Zum Beispiel hat der Tester seinen Test gestartet und begonnen etwas zu überprüfen. Dies ist die Zeit nützlicher Arbeit, in der wir tatsächlich etwas für das Produkt tun. Dafür bezahlen die Kunden — für hochwertige Software.

%C/A — Prozentsatz der angenommenen Arbeit. Wir haben eine Phase — Entwicklung, die zweite Phase — Testing. Wie viele Features die Tester von den Entwicklern angenommen haben, und es gibt diesen Prozentsatz.

So sieht unsere Karte ungefähr aus.

Sie 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 und Analytik. In dieser Phase werden Daten erwartet, z.B. Lead Time 2 Wochen und Wertschöpfungszeit 2 Tage.

Wir decken absolut alle Phasen mit Metriken ab.

Backlog — wie viele Aufgaben liegen, nachdem die Analysten sie erfunden haben.

Entwicklung — wie viele Wochen die Entwickler auf Klärung der Aufgaben, Stände oder Ausrüstung gewartet haben — 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 übernommen. Sie glauben, dass die restlichen 20% nicht genügend klare Anforderungen haben und haben sie zur Überarbeitung geschickt.

Tests. 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ächlich etwas getestet, und %C/A = 40 %. — 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.

Ich werde nicht detailliert darauf eingehen, wie diese Messungen durchgeführt werden, am Ende des Artikels empfehle ich Literatur, aus der man darüber lernen kann.

Das Einzige, was ich empfehlen kann — 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ätzungen sind nicht immer korrekt, daher ist es besser, selbst zu messen.

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 überhaupt 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 – 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ätten wir nicht mit einem Notizbuch hingegangen, nicht mit den Augen auf die Aufgabe in Jira aufmerksam geworden und begonnen, sie Schritt für Schritt zu verfolgen, hätten wir geglaubt, dass alles wunderbar ist und es kein Problem gibt.

Deshalb müssen die Messungen doch selbst durchgeführt werden, am besten nicht nur einmal, um eine möglichst realistische Vorstellung zu bekommen. Je nach Value Stream Map werden Sie entscheiden, wo Sie anfangen und was Sie zuerst beheben.

Temporäres Team

Viele Unternehmen, die beschlossen haben, DevOps einzuführen, bilden ein Team, jedoch nicht ein temporäres, 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.

Wenn ein DevOps-Team über mehrere Jahre hinweg ständig existiert, ist das ein großer Fehler, denn DevOps bedeutet Kommunikation zwischen Abteilungen, Geschwindigkeit und Effizienz.

Wenn das Team zwischen den Abteilungen besteht, nur um etwas anderes Separates zu tun, und lange existiert, entsteht ein zusätzlicher Barrier. Jetzt muss der Programmierer, anstatt direkt zum Administrator zu gehen, um das Problem zu klären, zuerst das DevOps-Team kontaktieren, das dann weitervermittelt.

Deshalb muss zu Beginn ein temporäres Team gebildet werden.. Sie wird bedingt für sechs Monate, maximal ein Jahr bestehen, je nach gestellter Aufgabe, nur um eine von uns gewählte Einschränkung zu beseitigen. Danach wird sie sterben. Wenn wir den nächsten Punkt wählen, an dem wir starke Schmerzen haben, und feststellen, dass wir dafür auch ein separates Team benötigen, dann werden wir es wieder ins Leben rufen. Aber solche Teams sollten nicht „permanent“ existieren — sonst stören sie nur die Kommunikation und übernehmen ganz separate Aufgaben, nur um etwas zu tun. Diese Aufgaben könnten überhaupt nicht mit DevOps und der Transformation verbunden sein. Warum sollten wir diese Aufgabe nicht an bestehende Abteilungen abgeben?

Warum ein temporäres Team benötigt wird

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

Diese Personen müssen nach anderen Regeln leben: alle KPIs im Unternehmen ignorieren, weil sie versuchen, anders zu arbeiten. Temporäre Teams werden keine Anträge ausfüllen, um einen Server zu erhalten, sondern direkt zu der Abteilung gehen, die dafür zuständig 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ändigen Konflikt mit allen aktuellen Prozessen. Damit die bestehenden Arbeitsmethoden sie nicht stören und sie auch anderen nicht im Weg stehen, isolieren wir diese Personen und bilden ein separates Team.

Vermeidung von Bürokratie in Experimenten. In temporären Teams gibt es keine Bürokratie, sie füllen 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ötig stören.

Ununterbrochene Arbeit am Service. Im ersten Punkt haben wir etwas ausgewählt, an dem wir experimentieren werden. Experimente und die Suche nach besseren Arbeitsweisen sind gut, aber wir möchten auch Funktionen erstellen. Wenn das gesamte Team anstelle von Funktionen mit der Transformation beschäftigt ist, werden wir anfangen, Einnahmen zu verlieren, und Fehler werden lange bestehen bleiben — das brauchen wir nicht. Die Schaffung eines temporären Teams ermöglicht es uns, zu experimentieren, ohne die Arbeit am Produkt zu unterbrechen.

Keine Zeit mit Arbeitsaufgaben verschwenden. 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önnen, wird es mindestens ein halbes Jahr dauern. Wenn sie sich auch noch mit dem Produkt beschäftigen, wird das halbe Jahr astronomisch lang. Wenn die Leute am Produkt arbeiten, beschäftigen sie sich erneut mit den alten Prozessen – das brauchen wir nicht.

Deshalb ziehen wir aus verschiedenen Abteilungen Menschen in ein separates Team, das die Transformation des Services übernimmt. Dadurch funktioniert der Service, entwickelt sich weiter und wir können gleichzeitig einige Experimente damit durchführen.

Das temporäre Team kümmert sich ausschließlich um die DevOps-Transformation – das Entfernen der Einschränkungen, die wir gefunden haben, und sonst nichts.

Das Team besteht aus vielseitigen Menschen. Das bedeutet, dass wir nicht nur Entwickler genommen haben. Wir sind nicht einfach in den Service gekommen und haben ein halbes Team herausgenommen – nein, wir haben Menschen aus verschiedenen Abteilungen. 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 – wir werden sowohl den Testprozess, den Entwicklungsprozess als auch den Wartungsprozess des Services ändern. Unterschiedliche Kompetenzen sind erforderlich.

Normalerweise nehmen wir einen Entwickler, einen Tester und einen Ingenieur – jeweils einen, und zusammen mit ihnen denken wir uns Lösungen aus, die es ermöglichen, anders zu leben.

Es wäre wünschenswert, dass diese Leute Autorität in der Organisation haben. Es könnte notwendig sein, einen Konservativen zu engagieren, auch wenn wir das nicht wollen. Wenn wir ein großes Unternehmen haben, werden nicht alle an unser Vorhaben glauben, und einige könnten uns Steine in den Weg legen, zum Beispiel indem sie keinen Stand bereitstellen. Hier wird Autorität benötigt – eine respektierte Person mit viel Erfahrung, die sich gutes Ansehen bei den Kollegen erarbeitet hat. Die Autorität des Mitarbeiters im Team wird die Aufgabe und die Arbeit des temporären Teams erleichtern. Die Leute denken dann:

— Aha, dieser coole Typ, den wir alle kennen und lieben, ist dabei – offenbar gibt es im DevOps etwas, das es wert ist, betrachtet zu werden!

Ziele setzen

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

Spezifisch — konkret.

Messbar — messbar. Dies ist ein sehr wichtiger Punkt im SMART-Modell. 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.

Erreichbar — erreichbar. Berücksichtigen Sie Ihre spezifischen Gegebenheiten. Wenn Sie ein Unternehmen mit langjähriger Geschichte und einer großen Last an Verpflichtungen sind, das einmal im Jahr eine Version des Produkts herausbringt, können Sie nicht in sechs Monaten erreichen, dass neue Versionen des Produkts jede Stunde veröffentlicht werden. Das wird nicht funktionieren. Setzen Sie sich daher ein realistisches Ziel, das innerhalb eines angemessenen Zeitrahmens erreichbar ist.

Relevant — relevant. Wir beseitigen nur dasjenige Hindernis, das wirklich unsere aktuellen Ziele verfolgt.

Zeitlich begrenzt — zeitlich begrenzt. Wenn es keinen Abgabetermin gibt, wird das Team sich mit allem Möglichen beschäftigen: 15 Technologien statt 3 ausprobieren, riesige Berichte schreiben, nutzlose Forschungen durchführen, ihre Implementierung bis zur Perfektion ausfeilen, wenn das Ziel bereits erreicht ist.

Das Ziel bestimmen wir mithilfe der Value Stream Map — 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öchten.

Wir identifizieren ein Hindernis, das wir jetzt sofort beseitigen werden — das wird das Team tun. Zum Beispiel nehme ich die Wartezeit vom fertigen Release bis zur Bereitstellung in der Produktion — das ist das häufigste Hindernis, mit dem Menschen zu Beratern kommen.

Basierend darauf setzen wir die Aufgabe fest: Wir möchten, dass die Wartezeit zwischen dem fertigen Release und dem Start im Einsatz maximal eine Stunde beträgt.

Beispielaufgaben.

• Die Testdurchlaufzeit von 4 Tagen auf 1 Stunde reduzieren.
• Die wertschöpfende Zeit für die Tests von 2 Tagen auf 3 Stunden reduzieren.
• Die Bereitstellungszeit von 5 Stunden auf 10 Minuten reduzieren.
• Die C/A von 50% auf 95% erhöhen, das heißt, die Anzahl der Funktionen zu erhöhen, die die Tester annehmen, mit anderen Worten, die Qualität der Arbeit der Entwickler zu verbessern.

Die Beispielaufgaben stammen nicht aus der Luft — sie basieren auf den Messungen, die wir durchgeführt haben, als wir die Value Stream Map erstellt haben.

Wir setzen unserem Team eine ähnliche Aufgabe und eine zeitliche Einschränkung. Je nachdem, wie gut es in Ihrem Unternehmen läuft, setzen Sie unterschiedliche Fristen. Im Durchschnitt benötigt es etwa sechs Monate, 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 Menschen fangen an zu arbeiten. 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, wenn sich das gesamte Team zu Beginn jeder Woche trifft und festlegt, was jeder tun wird. Nach einer Woche überprüfen wir: Was wurde gemacht und was nicht, wenn nicht, warum, und überlegen, was als Nächstes zu tun ist.

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

Eine Woche oder zwei haben wir etwas ausprobiert: Technologien, Ansätze, Arbeitsweisen, danach messen wir wieder und schauen — hat sich mit diesem Ansatz etwas verbessert oder verschlechtert? Wenn es schlechter geworden ist, gehen wir in die falsche Richtung, wir müssen den Kurs korrigieren: eine andere Aufgabe festlegen, eine andere Technologie wählen oder etwas anderes tun. Kurze Sprints von 1-2 Wochen ermöglichen es, flexibel zu bleiben und rechtzeitig von schlechten Entscheidungen abzurücken.

Erfolge teilen

Das Team erzielt irgendwelche Erfolge, ob klein oder groß — es spielt keine Rolle, es gibt immer ein Ergebnis. Über dieses Ergebnis sollten im Allgemeinen alle informiert sein: sowohl diejenigen, die an DevOps beteiligt sind, als auch die benachbarten Abteilungen. In einer idealen Welt wäre es wünschenswert, dass dies überhaupt alle erreicht alle Menschen im Unternehmen.

Warum? Wenn wir nicht nur einen Teil des Unternehmens transformieren, nicht nur eine Einschränkung beseitigen, sondern alles, damit das Unternehmen flexibel wird, der Code schnell zum Kunden gelangt und nichts kaputtgeht, müssen alle loyal zur Idee von DevOps sein. Sie können den Ansatz nicht auf Dienste und Teams anwenden, die strikt dagegen sind.

Um Loyalität zu schaffen, müssen wir allen erzählen, dass wir das ausprobiert haben — wir haben Ergebnisse, probiert es auch aus! Das wird das Interesse und die Loyalität an dem, was wir tun, erhöhen, die Menschen werden anfangen, sofort etwas zu versuchen. Wie die Praxis zeigt, wenn wir erzählen, was wir ausprobiert haben und was wir erreicht haben, fangen andere Teams an zu fragen, wie und was sie gemacht haben. Sie schauen sich die Implementierungen, den Code, die Dokumentation an, stellen Fragen und versuchen, etwas bei sich zu ändern.

Darüber zu berichten, was Ihnen gelungen ist — das ist wichtig. So überzeugen Sie, in Ihr Lager der Konservativen zu wechseln, die alles auf die alte Art machen wollten und verwandeln sie in Innovatoren.

Insgesamt

Wir wählen einen Service, als Ausgangspunkt — den Ort, an dem wir die Veränderungen im Unternehmen beginnen. Wir identifizieren alle, die einen Bezug zum Service haben. und arbeiten gemeinsam mit ihnen an der Erstellung einer Value Stream Map, messen und analysieren, wo und welche Einschränkungen bestehen.

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 kennzeichnen, die wir angehen werden.Auf Grundlage dieser Einschränkung setzen wir die Aufgabe, die das Team übernehmen wird. Diese Aufgabe muss unbedingt SMART sein — spezifisch, messbar, relevant für die aktuellen Aufgaben und zeitlich begrenzt.

Wir wiederholen den Prozess, bis wir all unsere Services in die gewünschte Form transformiert haben und alle Einschränkungen beseitigt sind.

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 darüber, wie ein Mitarbeiter zum Leiter einer Abteilung ernannt wurde, die ständig in Flammen stand. Dem neuen Leiter wurde die Aufgabe gestellt:

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

„Das Phoenix-Projekt. Ein Roman darüber, wie DevOps das Leben zum Besseren verändert“ — ein Buch für alle Führungskräfte, denn gerade diese Personen treffen die Entscheidungen darüber, was im Unternehmen geschieht. Wenn du hingegen Ingenieur oder Programmierer bist und möchtest, dass in deinem Unternehmen Bewegung und Transformation beginnen — kaufe das Buch und schenke es der Führungsebene. Dieser Roman erklärt alles und lässt sich schnell und leicht lesen.

Leitfaden zu DevOps

Ein etwas komplizierteres Buch. Es erschien vor einigen Jahren auf Englisch unter dem Titel „The DevOps Handbook How to create world-class agility, reliability, and security in Technology organizations“, ist aber jetzt auch auf Russisch erhältlich. Es ist ein echtes Handbuch — eine praktische Anleitung: wie man Messungen durchführt, was eine Value Stream Map ist und wozu sie dient, wohin man sich bewegen sollte und in welcher Reihenfolge. Das Buch ist genau das richtige für diejenigen, die alles selbst machen möchten. Das Wichtigste ist, dass es Beispiele aus den Erfahrungen anderer Unternehmen enthält.

Zum Beispiel wird dort erzählt, wie ein Unternehmen eine Value Stream Map erstellt hat und feststellte, dass das Problem nicht im Produkt liegt, sondern darin, dass die Kassiererin zwischen dem Laden und dem benachbarten Büro gehen muss, um das Produkt zu nutzen. Anstatt das Problem mit der Software zu lösen, kauften sie einfach Tablets für ihre Verkäufer, und jetzt geht niemand mehr irgendwohin, sondern alle Tätigkeiten werden am Arbeitsplatz ausgeführt. Fazit: Die Value Stream Map kann nicht nur auf Software, sondern auch auf alle Prozesse in der Organisation angewendet werden.

Accelerate

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 es handelt von Forschung. Die Autoren – Nicole Forsgren, Jez Humble und Gene Kim – haben über viele Jahre hinweg verschiedene Praktiken in verschiedenen Unternehmen angewendet und erforscht, welche Praktiken, wie und worauf sie Einfluss haben.

Im zweiten Kapitel, das sich mit Messungen befasst, werden die Value Stream Map, die von mir genannten Metriken und viele andere erwähnt sowie der Messprozess detailliert beschrieben. Die Autoren führen Messungen mit Hilfe von Fragebögen und eigenständigem Task-Tracking durch. Es wird ausführlich erklärt, welche Metriken richtig zu messen sind, welche nicht, sowie menschliche Fehler bei den Messungen. Wenn Sie Schwierigkeiten mit Messungen haben, schauen Sie in das zweite Kapitel des Buches „Accelerate“. Wenn Ihr Team einfach viele Praktiken hat, aber unklar ist, welche Praktiken jetzt angewendet werden sollen, welche später, welche tatsächlich wirken und welche nicht – lesen Sie, das Buch erklärt alles.

Transformation ist eine Frage an der Schnittstelle zwischen DevOps und Management. Irgendwo in diesem Schnittbereich zwischen Entwicklung, Betrieb und Test befinden sich die Themen, die wir versuchen, auf DevOpsConf, die gleiche Integration wird auch benötigt, um ein qualitativ hochwertiges Produkt zu schaffen – das Hauptthema QaulityConf. Management auf dem Festival RIT++ etwa 850 Anwendungen enthalten. Zur Vereinfachung der Entwicklung neuer Anwendungen wurde ein Set von typischen Whale Rider – das bedeutet, dass alle Ideen für Transformationen dort gesammelt werden. Begleiten Sie uns am 27. und 28. Mai, wir werden integrieren und transformieren.

Quelle: habr.com