So starten Sie die DevOps-Transformation

Wenn Sie nicht verstehen, was DevOps ist, finden Sie hier einen kurzen Spickzettel. DevOps ist eine Reihe von Methoden, die die Ängste der Ingenieure verringern und die Anzahl der Fehler in der Softwareproduktion verringern. In der Regel verkürzen sie auch die Markteinführungszeit - den Zeitraum von der Idee bis zur Auslieferung des Endprodukts an die Kunden, sodass Sie schnell Geschäftsexperimente durchführen können .

Wie starte ich die DevOps-Transformation? Kurz gesagt: Wir wählen den Service aus, von dem aus wir den Prozess starten, identifizieren diejenigen, die mit dem Service zusammenhängen, erstellen die Value Stream Map, erstellen ein temporäres Team, das sich zum ersten Mal mit der Transformation befasst, und legen ihm eine Aufgabe fest. Wir wiederholen den Zyklus so oft wie nötig.


Ein detaillierter DevOps-Transformationsplan mit Beispielen und Anweisungen unter dem Schnitt befindet sich in der Dekodierung des Berichts von Andrei Alexandrov , einem Ingenieur bei Express42, der zum Keimen von DevOps rät und diesen Prozess beschleunigt, da bereits eine Rechenkarte erstellt wurde. Wenn Sie den Eindruck haben, dass Sie die Transformation nicht benötigen oder wenn Sie solche Besonderheiten haben, dass DevOps-Praktiken nicht geeignet sind, verwenden Sie den Bericht als Anweisung zum Auffinden und Aufheben von Einschränkungen.

Wenn Sie sich Sorgen über das Problem der DevOps-Transformation machen, haben Sie ein großes Unternehmen und müssen diesen Prozess schrittweise auf die gesamte Struktur skalieren. Solange das Team transformiert oder eine Einschränkung aufgehoben werden muss, kann der folgende Algorithmus wiederholt werden.

Serviceauswahl

Wir haben einen Plan entworfen. Beginnen Sie mit dem ersten Schritt - der Auswahl eines Dienstes. Das erste Kriterium ist die Lebensdauer : Es gibt alte und neue Dienste. Sie können mit diesen und anderen beginnen.

Es ist logisch, einen jungen Dienst zu wählen . Es ist frisch, es gibt keinen etablierten Prozess, in einem Team zu arbeiten, das sich damit befasst. Um ihn herum gibt es keinen Berg technischer Schulden, keine Notwendigkeit, sie ständig zu reparieren. Wir können mit ihm machen, was wir wollen.

Beim alten Dienst gibt es Probleme damit, dass es immer schwierig ist, Änderungen vorzunehmen . Es gibt bereits einige schwerwiegende Einschränkungen, aber vielleicht tun es Leute, die bereit sind, alles auf den Kopf zu stellen - sie sind müde und wollen etwas anders machen, weil es weh tut.

Die Arbeit mit dem alten Service schafft einen starken Präzedenzfall in Ihrem Unternehmen - Sie können etwas ändern. Wenn Sie einen neuen Dienst ändern, wird er 100 Mal pro Stunde ausgeführt, und alles ist in Ordnung. Dann können die Mitarbeiter Ihres Unternehmens sagen:

- Dies ist ein neuer Service! Dort war alles einfach, versuchen Sie etwas mit unseren aufgemotzten Dingen zu tun.

Es ist sinnvoll, einen Legacy-Service in eine Transformation umzuwandeln, wenn Sie dies mit jemandem tun, beispielsweise wenn Sie einen externen Berater eingeladen haben. Seien wir ehrlich, die Transformation wird alles, was möglich ist, ins Wanken bringen . Sie experimentieren und wissen nicht, woher Sie kommen, welche Technologien und warum Sie verwenden, wo und welche Fallstricke in den Prozessen auftreten werden. Daher ist eine neue Änderung einfacher.

Wenn Sie alles selbst erledigen, das Unternehmen jedoch keine ernsthafte Kompetenz besitzt, übernehmen wir einen neuen Service. Wenn Sie einen externen Berater kennen und über Mittel verfügen, wählen Sie den alten.

Es gibt Dienste, die nur eine Schnittstelle für Benutzer sind, z. B. eine einfache Website oder eine mobile Anwendung. Aber es gibt ernsthafte Dinge im Sinne der Abrechnung. Wenn bei der Abrechnung etwas schief geht, ist es schwer zu verstehen. Hier haben wir auch eine Wahl.

Wir arbeiten entweder mit einem kritischen Dienst , leiden aber bereits darunter, es entstehen Einschränkungen, oder wir arbeiten mit der Schnittstelle . Dies ist das zweite Auswahlkriterium. Ebenso ist es möglich, einen erfahrenen Berater zu gewinnen - wir arbeiten mit einer schwierigen Option.

Aber selbst in diesem Fall würde ich nicht raten, dies zu tun, denn obwohl es kein Verständnis dafür gibt, womit man arbeiten und wie man sich transformiert, ist es keine gute Idee, eine kritische Sache zu nehmen und sie zu schütteln. In diesem Fall arbeiten wir daher lieber mit einer Schnittstelle, deren Fehler nicht kritisch ist.

Betrachten Sie als nächstes den Dienstbefehl . Mit denen, die an diesem Service beteiligt sind, müssen wir ständig in sehr engem Kontakt arbeiten und interagieren.

Die Mitarbeiter des Teams werden bedingt in zwei Kategorien unterteilt: Konservative - sie leben in der alten Welt oder wissen einfach nichts über DevOps - und Innovatoren , die alle modischen Praktiken anwenden. Letztere verstehen das Thema nicht immer, sind aber zumindest bereit dafür.

Einerseits sind Konservative erfahrene Menschen: Sie sind schon lange im Unternehmen, sie verstehen es vollständig, aber sie wissen nicht nur über Praktiken Bescheid. Auf der anderen Seite gibt es Innovatoren, die etwas gehört haben, aber höchstwahrscheinlich vor nicht allzu langer Zeit für das Unternehmen gearbeitet haben. Mit welchem ​​von ihnen ist es besser zu arbeiten?

In jedem Fall müssen Sie mit Konservativen interagieren, da dies deren Service ist. Wir müssen mit ihnen kommunizieren, die Besonderheiten des Dienstes herausfinden, was auf diese Weise getan werden kann und was anders ist. Wir sind auf ihren Rat angewiesen. Sicherlich müssen sie etwas anvertrauen, weil sie ihren Service besser kennen. Daher ist es wichtig, mit welchem ​​Team wir irgendwann Kontakt haben werden.

Es ist logisch, ein Innovatorenteam zu wählen, da Konservative ein Schwein setzen können.

In der Praxis kommt es häufig vor, dass konservative Menschen über umfangreiche Erfahrungen verfügen, aber es gibt kein Verständnis dafür, wie sie weiterleben sollen. Sie befürchten lediglich, dass sie nach der Umgestaltung und Änderung des Dienstes als unnötig abgetan werden. Manchmal sabotieren sie die Arbeit, einfach weil sie nicht verstehen, was passiert.

Ich hatte einen Fall, in dem ein Mann aus einem Team irgendetwas repariert hat, weil es angeblich kritischer ist als das, was wir jetzt tun. Wir haben uns die Aufgabe gestellt: dieses Stück heute zu realisieren - nein, es gibt ein Feuer auf der anderen Seite der Welt, wir werden es reparieren. Es ist schwierig, mit solchen Menschen zu arbeiten.

Leute aus dem konservativen Team verstopfen oft Aufgaben oder verschieben sie bis zum letzten. Und wenn John Willis Sie rettet, Sie einen Fehler gemacht und sie mit KPI für die Anzahl der erledigten Aufgaben aufgehängt haben und aus irgendeinem Grund einige von ihnen nicht in KPI enthalten waren, werden sie überhaupt nichts tun. Im Allgemeinen haben sie Recht, denn dann verlieren sie den Bonus.

Mit Innovatoren ist es einfacher - sie sind loyaler . Sie haben schon etwas gehört, sie wollen irgendwohin, also werden sie helfen. Wir brauchen Menschen, die bereit sind, das erste Mal zu leiden: Wenn sich der Service ändert, werden alle Kegel und Rechen von Innovatoren als Pioniere gefangen. Innovatoren wollen das Neueste und Modischste und leiden.

Konservative können später konvertiert werden. Wenn Sie zeigen, dass Sie ein Stück geändert haben und alles gut funktioniert, werden sie höchstwahrscheinlich auch versuchen wollen, die neue DevOps-Religion zu übernehmen.

Zusammenfassend. Wenn wir die gesamte Transformation in unserem Unternehmen selbst durchführen, wählen wir: einen neuen Service, vorzugsweise eine einfache Schnittstelle, um nicht viel unter dessen Zusammenbruch zu leiden, und ein Team von Innovatoren.

Wenn es möglich ist, einen externen Berater anstelle eines neuen zu rufen, nehmen wir den alten Service in Anspruch, unter dem wir bereits leiden. Menschen, die sich seit geraumer Zeit in verschiedenen Unternehmen mit Transformation befasst haben, haben verschiedene Fälle gesehen und verstehen bereits, wie man es richtig macht und welchen Weg man im Allgemeinen geht.

Wer ist beteiligt?

Wir müssen im Allgemeinen jeden finden, der zumindest etwas mit dem Service zu tun hat: Entwickler, Tester, Administratoren, Sicherheitspersonal, Manager und möglicherweise Produktbesitzer. Trotz der Tatsache, dass Product Owners keine Technikfreaks sind, hängen sie mit dem Service zusammen: Treffen Sie eine Entscheidung, stellen Sie eine Aufgabe.

Jeder, der zumindest einige Entscheidungen trifft und beeinflusst, was mit dem Service passiert, muss finden, sich treffen und chatten.

Was sind sie für uns? Zu wissen, mit wem zu verhandeln ist . Wenn sich während der Transformation das übliche Prinzip der Arbeit mit dem Dienst ändert, wird es trotzdem wackeln. Es wird für eine Weile Pannen geben, während wir neue Ansätze testen. Die Menschen sollten darauf vorbereitet sein und damit einverstanden sein.

Dann müssen Sie eine Value Stream Map erstellen, und ohne diese Personen können Sie sie nicht erstellen, da nur alle zusammen das vollständige Bild des Geschehens kennen. Eine Person weiß nie alles, was mit dem Service passiert.

Sie werden die Leute im Team beraten. Später werden wir diskutieren, warum ein separates Team benötigt wird. Es müssen Mitarbeiter aus bestehenden Abteilungen aufgenommen werden. Diejenigen, die mit dem Service verbunden sind, können Kollegen empfehlen, die in unsere Richtung denken, die uns helfen und die Kompetenz in dem haben, was wir brauchen.

Dann sammeln wir all diese Personen aus verschiedenen Abteilungen in einem Raum und beginnen mit der Erstellung einer Wertstromkarte.

Erstellen einer Wertstromkarte

Wertstromkarte ist ein Diagramm oder eine Karte, die den Wertefluss zum Client zeigt . Dies ist der gesamte Prozess von der Erfindung einer Idee bis zur Umsetzung, einschließlich aller Zwischenstufen und wie der Wert letztendlich unsere Kunden erreicht.

Die Value Stream Map wird benötigt, um alle Entwicklungsstadien zu visualisieren , Probleme durch Messungen zu lokalisieren, die sich im aktuellen Prozess befinden, und um diese Probleme zu beseitigen und ein erstes Ziel festzulegen . Dies ist der Ort, an dem wir anfangen werden, wirklich etwas zu tun.

Metriken

In der Value Stream Map-Literatur sind viele verschiedene Metriken beschrieben, aber für den Anfang benötigen wir nur drei.

Vorlaufzeit - Verzögerung / Wartezeit - die Zeit, in der wir auf etwas warten. Beispielsweise wartet der Tester, bis der Prüfstand freigegeben ist, und kann derzeit nichts tun.

Wertschöpfungszeit - die Zeit nützlicher Arbeit - die Zeit, die wir in dieser und jener Phase verbracht haben, um den ultimativen Wert für den Benutzer zu schaffen. Zum Beispiel führte ein Tester seinen Test durch und begann, etwas zu testen. Dies ist die Zeit nützlicher Arbeit, in der wir wirklich etwas für das Produkt tun. Dafür bezahlen Kunden - für hochwertige Software.

% C / A - Prozentsatz der angenommenen Arbeit. Wir haben eine Stufe - Entwicklung, die zweite Stufe - Testen. Wie viele Funktionen haben Tester von Entwicklern übernommen, und es gibt diesen Prozentsatz.

So sieht unsere Karte aus.



Je nach Struktur der Organisation, Anzahl der Abteilungen und Ihrer Tätigkeit kann dies unterschiedlich aussehen. Im allgemeinen Fall besteht die Karte jedoch aus zwei Phasen: einer Idee und einer Analyse . Zu diesem Zeitpunkt werden Daten erwartet, z. B. Vorlaufzeit 2 Wochen und Wertschöpfungszeit 2 Tage.

Metriken decken absolut alle Phasen ab.

Rückstand - wie viele Aufgaben lagen, nachdem die Analysten sie erstellt hatten.

Entwicklung - wie viele Wochen Entwickler auf Klärungen von Aufgaben, Ständen oder Geräten gewartet haben - spielt keine Rolle, aber sie warten auf etwas. Zum Beispiel implementieren sie eine Funktion für 4 Tage. Hier wird die% C / A-Metrik angezeigt. Entwickler haben nur 80% der Aufgaben aus dem Backlog übernommen. Sie glauben, dass die restlichen 20% keine eindeutige TK haben, und haben sie zur Überarbeitung geschickt.

Testen . Auf dem LT-Schema sind 4 Tage festgelegt. Zum Beispiel warteten Tester darauf, dass der Prüfstand freigegeben wurde, VA 2 Tage lang testeten sie wirklich etwas und% C / A = 40%. - Nur 40% des Codes oder der Funktionen, die die Entwickler gesendet haben, wurden von Testern als angemessen angesehen. Den Rest gefiel ihnen aus irgendeinem Grund nicht.

Ich werde nicht näher darauf eingehen, wie diese Messungen durchgeführt werden sollen. Am Ende des Artikels werde ich Literatur empfehlen, aus der Sie mehr darüber erfahren können.

Das einzige, was ich rate, ist, den Leuten nicht zu glauben, die mit Ihnen die Value Stream Map erstellen werden. Sie geben an, wie viel Zeit die verschiedenen Prozesse in Anspruch nehmen. Diese Schätzungen sind jedoch nicht immer korrekt. Daher ist es besser, sich selbst zu messen.

Wir hatten einen Fall, als wir in die Betriebsabteilung kamen und fragten, wie lange es dauert, ein neues Feature für die Produktion bereitzustellen. Sie antworteten diese 10 Minuten und wir dachten, warum sind wir zu dieser Firma gekommen? Es stellte sich heraus, dass 10 Minuten die Laufzeit des Skripts sind, das den Code aufnimmt und an den Server übermittelt. Zuvor liegt die Version jedoch drei Tage auf dem Server und sammelt nur Staub - in Backlog liegt die Aufgabe, die bereitgestellt werden muss. Es stellt sich heraus, dass es vor der Bereitstellungsphase eine Wartephase gibt, in der das Projekt einfach lügt. Wenn wir nicht mit einem Notizbuch gegangen wären, nicht auf eine Aufgabe in Jira aufmerksam geworden wären und nicht begonnen hätten, sie schrittweise zu verfolgen, hätten wir gedacht, dass alles wunderbar ist und es kein Problem gibt.

Daher müssen die Messungen immer noch selbst durchgeführt werden, vorzugsweise mehr als einmal, um eine realitätsnahe Darstellung zu erhalten. Abhängig von der Value Stream Map entscheiden Sie, wo Sie beginnen und was zuerst behoben werden soll.

Temporäres Team

Viele Unternehmen, die sich für die Einführung von DevOps entschieden haben, bilden ein Team, das nicht nur vorübergehend ist, sondern mehrere Jahre besteht. Wenn Sie zum DevOps-Entschuldigungsdienst gehen, der die verschiedenen Muster für den Aufbau einer Organisationsstruktur in DevOps beschreibt, werden Sie verstehen, dass dies ein Antimuster ist.

Wenn das DevOps-Team seit mehreren Jahren ununterbrochen besteht, ist dies ein großer Fehler, da es bei DevOps um die Kommunikation zwischen Abteilungen, um Geschwindigkeit und Effizienz geht.

Wenn ein Team zwischen Abteilungen besteht, nur um etwas anderes getrennt zu tun, und es für eine lange Zeit besteht, entsteht eine zusätzliche Barriere. Anstatt direkt zum Administrator zu gehen, muss der Programmierer jetzt zuerst die DevOps-Abteilung kontaktieren, und er wird weiter gehen.

Daher müssen Sie zu Beginn ein temporäres Team erstellen . Es wird für einen suspendierten Zeitraum von sechs Monaten, maximal ein Jahr, je nach Aufgabe bestehen, nur um eine von uns gewählte Einschränkung zu beseitigen. Dann wird sie sterben. Wenn wir den nächsten Punkt wählen, an dem es sehr weh tut, und verstehen, dass wir auch ein separates Team dafür brauchen, werden wir ihn erneut erstellen. Solche Teams sollten jedoch nicht „permanent“ existieren - dann unterbrechen sie nur die Kommunikation und übernehmen im Allgemeinen separate Aufgaben, nur um etwas zu tun. Diese Aufgaben beziehen sich möglicherweise überhaupt nicht auf DevOps oder Transformation. Warum geben wir diese Aufgabe nicht an die bestehenden Abteilungen weiter?

Warum brauchen Sie ein temporäres Team?

Konflikt mit aktuellen Prozessen . Die DevOps-Transformation ist nicht nur eine Änderung der von uns verwendeten Technologien und Werkzeuge, sondern auch eine Änderung des Arbeits-, Denk- und Werteprozesses. Wenn das Team so arbeitet, wie sie es gewohnt ist, kann sie keine anderen Ansätze ausprobieren.

Diese Personen sollten nach unterschiedlichen Regeln leben: Ignorieren Sie alle KPIs im Unternehmen, da sie versuchen, anders zu arbeiten. Temporäre Teams füllen keine Anträge aus, um einen Server zu erhalten, sondern wenden sich direkt an die Abteilung, die sie verwaltet, und fordern, dass sie als Erste das geben, was sie benötigen, da dies eine vorrangige Aufgabe ist und sie versuchen, anders zu leben. Das Team hat einen vollständigen Konflikt mit allen aktuellen Prozessen. Damit die vorhandenen Arbeitsmethoden sie jetzt nicht stören und sie andere nicht stören, isolieren wir diese Personen, indem wir sie als separates Team herausgreifen.

Vermeidung von Bürokratie in Experimenten . In temporären Teams gibt es keine Bürokratie, sie füllen keine Berichte über die Arbeitszeit aus und sie berichten nicht an Manager. Dies ist eine völlig separate Welt, in der Menschen anders leben und denken und ganz andere Dinge tun. Belästige sie nicht noch einmal.

Non-Stop-Arbeit am Service . Im ersten Absatz haben wir etwas ausgewählt, mit dem wir experimentieren können. Es ist gut zu experimentieren und Wege zu finden, um besser zu arbeiten, aber wir möchten auch Funktionen ausführen. Wenn sich das gesamte Team auf Transformation anstatt auf Funktionen einlässt, werden wir anfangen, Einnahmen zu verlieren, Fehler werden für eine lange Zeit hängen bleiben - wir brauchen dies nicht. Durch das Erstellen eines temporären Teams können Sie experimentieren, ohne die Arbeit am Produkt zu beenden.

Verschwenden Sie keine Zeit mit Arbeitsaufgaben . Hier geht es wieder um das Produkt. Das Team braucht viel Zeit, um andere Tools und Dinge auszuprobieren. Es dauert mindestens sechs Monate, bis die Benutzer die Tools beherrschen, mit der Implementierung beginnen und sie normal verwenden können. Wenn sie sich auch mit dem Produkt befassen - sechs Monate kosmisch strecken. Wenn Menschen mit einem Produkt beschäftigt sind, arbeiten sie wieder mit alten Prozessen - das brauchen wir nicht.

Aus diesem Grund trennen wir Mitarbeiter aus verschiedenen Abteilungen in ein separates Team, das sich mit der Transformation des Service befasst. Infolgedessen funktioniert der Service, entwickelt sich weiter und gleichzeitig haben wir einige Experimente durchgeführt.

Das temporäre Team ist nur an der DevOps-Transformation beteiligt - es beseitigt die Einschränkungen, die wir gefunden haben, und nichts weiter.

Das Team besteht aus universellen Menschen . Das heißt, wir haben nicht nur Entwickler mitgenommen. Wir sind nicht zum Service gekommen und haben von dort kein halbes Team mitgenommen - nein, wir haben Leute aus verschiedenen Abteilungen mitgenommen . Vor einigen Punkten haben wir verschiedene Abteilungen und Mitarbeiter gefunden, die mit dem Transformationsservice zusammenhängen. Von diesen rekrutieren wir ein Team, weil es universell sein muss - wir werden den Testprozess, den Entwicklungsprozess und den Prozess der Wartung des Service ändern. Unterschiedliche Kompetenzen sind erforderlich.

Normalerweise nehmen wir einen Entwickler, Tester und Ingenieur unter bestimmten Bedingungen - jeweils einzeln. Zusammen mit ihnen entwickeln wir eine Lösung, mit der Sie anders leben können.

Es ist wünschenswert, dass diese Personen Autorität in der Organisation haben . Möglicherweise müssen Sie einen Konservativen nehmen, obwohl Sie dies nicht möchten. Wenn wir ein großes Unternehmen haben, wird nicht jeder an unser Unternehmen glauben, und jemand kann Stöcke in die Räder stecken, zum Beispiel keinen Stand hervorheben. Hier brauchen Sie "Autorität" - eine angesehene Person mit umfassender Erfahrung, die eine gute Einstellung von Kollegen verdient. Die Autorität des Mitarbeiters im Team vereinfacht die Aufgabe und Arbeit des temporären Teams. Die Leute werden denken:

- Ja, dieser coole Typ, den wir alle kennen und lieben, passt da rein - anscheinend hat DevOps etwas, das es wert ist, angeschaut zu werden!

Wir haben uns ein Ziel gesetzt

Wir versammelten Menschen, wählten einen Dienst, schauten uns die Einschränkungen an und bestimmten, welche Menschen wir beeinflussen werden. Jetzt müssen Sie sich ein Ziel setzen und es sollte bei SMART richtig sein - das ist alles, was wir lieben.

Spezifisch - spezifisch .

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

Erreichbar ist erreichbar . Passen Sie es an Ihre Besonderheiten an. Wenn Sie ein Unternehmen mit einer langen Geschichte und einer großen Verantwortung sind, das einmal im Jahr eine Produktversion veröffentlicht, können Sie in sechs Monaten nicht stündlich neue Produktversionen veröffentlichen. So wird es nicht funktionieren. Setzen Sie sich daher ein echtes Ziel, das in einem akzeptablen Zeitraum erreichbar ist.

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

Zeitlich begrenzt - zeitlich begrenzt . Wenn es keine Frist gibt, wird das Team alles tun: 15 statt 3 Technologien ausprobieren, große Berichte schreiben, nutzlose Forschung betreiben, die Implementierung zum Leuchten bringen, wenn das Ziel bereits erreicht ist.

Wir nehmen das Ziel mit Hilfe der Value Stream Map - wieder sammeln wir alle Menschen und zeichnen. Aber erst jetzt zeichnen wir basierend auf der vorherigen Value Stream Map, was wir bekommen möchten.



Wir haben eine Einschränkung herausgearbeitet, die wir jetzt beseitigen werden - das wird das Team tun. Als Beispiel habe ich die Erwartung von einer fertigen Version bis zu ihrer Bereitstellung in der Produktion genommen - dies ist die häufigste Einschränkung, die Menschen an Berater wenden.

Auf dieser Grundlage legen wir die Aufgabe fest: Wir möchten, dass die Wartezeit zwischen einer fertigen Version und dem Inkrafttreten maximal eine Stunde beträgt.

Beispiele für Aufgaben.

• Reduzieren Sie die Vorlaufzeit von 4 Tagen auf 1 Stunde.
• Reduzieren Sie die Wertschöpfungszeit für Tests von 2 Tagen auf 3 Stunden.
• Reduzieren Sie die Bereitstellung der Vorlaufzeit von 5 Stunden auf 10 Minuten.
• Erhöhen Sie den C / A-Wert von 50% auf 95%, dh erhöhen Sie die Anzahl der Funktionen, die Tester akzeptieren. Mit anderen Worten, verbessern Sie die Qualität der Entwickler.

Beispiele für Aufgaben werden nicht aus dem Kopf genommen - sie basieren auf den Messungen, die wir bei der Entwicklung der Wertstromkarte durchgeführt haben.

Wir haben eine ähnliche Aufgabe wie unser Team und ein Zeitlimit festgelegt. , , . , , , .

, , , . — : - , , .

, moving-moving , , , . : , , , , , .

.

- : , , , — ? , , : , - . 1-2 .

- , — , - . : , DevOps, . , .

Warum? , , , , , , , DevOps. , .

, , — , ! , , - . , , , , . , , , - .

, — . , - .

Insgesamt

, — , . , - Value Stream Map , , .

, . Value Stream Map , , . , . SMART — , , .

, .

. Nützliche Materialien

, DevOps .

«»

— «The Phoenix Project: A Novel about It, Devops, and Helping Your Business Win». DevOps — , , . :

— , , .

« “”. , DevOps » — , , . , — . , .

DevOps

. «The DevOps Handbook How to create world‑class agility, reliability, and security in Technology organizations», . handbook — : , Value Stream Map , , . , . , .

, , Value Stream Map , , , , . , , , , . : Value Stream Map , .

Accelerate

: «Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations». — . , . — Nicole Forsgren, Jez Humble Gene Kim — , , .

, , Value Stream Map, , , , . . , , , . , «Accelerate». , , , , , — , .

Transformation ist eine Schnittstelle zwischen DevOps und Management. Irgendwo im selben Schnittpunkt von Entwicklung, Betrieb und Test sind Themen, die wir auf der DevOpsConf diskutieren möchten. Dieselbe Integration ist erforderlich, um ein Qualitätsprodukt zu erstellen - das Hauptthema von QaulityConf . Das Management beim RIT ++ Festival wird von Whale Rider präsentiert - das bedeutet Ideen für die Transformation von allem dort. Treten Sie am 27. und 28. Mai bei, wir werden uns integrieren und transformieren.