Das Warum des Wertstrommanagements – germanic

Wenn Sie wie ich sind und mehr als einmal in der Technik unterwegs waren, haben Sie Akronyme mit drei Buchstaben kommen und gehen sehen. Manchmal ist die Technologie, auf die sie sich beziehen, ein Blitz in der Pfanne; ein anderes Mal hängt es ein bisschen herum, bevor es in die Plattformen aufgenommen wird, auf denen wir aufbauen.

Und so ist es auch mit dem Value Stream Management (VSM), das in DevOps-Kreisen immer beliebter wird. Die erste Frage, die ich dazu stelle, ist, warum? Ist dies eine neue Innovation, die einen Namen benötigt, oder hat jemand eine Schwäche in vorhandenen Tools und Methoden entdeckt?

Kurz gesagt, VSM bezieht sich auf die Notwendigkeit – oder die Fähigkeit -, einen Überblick darüber zu haben, wie Software erstellt wird. Während Funktionseinheiten die Pipeline durchlaufen, vom Konzept bis zur Bereitstellung, können Manager davon profitieren, zu verstehen, wie dies geschieht, von der Geschwindigkeit der Entwicklung bis hin zu den Engpässen, dem Wert, der geliefert wird, und so weiter.

Die Frage, ob wir VSM benötigen, ist im Bereich der Softwareentwicklung besonders wichtig, nicht zuletzt, weil Menschen schon sehr lange Anwendungen erstellen. Sie würden denken, wir würden wissen, wie das geht und wie wir den Prozess jetzt verwalten.

Hat die DevOps-Welt eine Epiphanie erreicht, in der sie plötzlich das Geheimnis des Lebens, des Universums und der Entwicklung von Software entdeckte? Nicht ganz. VSM (das auch ein Erbe hat) existiert als Antwort auf einen aktuellen Bedarf. Schauen wir uns also die Ursachen an.

Seien wir ehrlich: Die Softwareentwicklung läuft seit Jahrzehnten in den Sand. Als die Systeme größer und komplexer wurden, konnten lineare Prozesse nicht mithalten oder, genauer gesagt, die Dinge zunehmend verlangsamen. Es gibt vielleicht noch einige Befürworter von Wasserfällen, aber allzu oft war der Prozess selbst der Engpass, der die Innovation behinderte.

In den neunziger Jahren untersuchten viele Menschen verschiedene Arten, Dinge zu tun. Einige entschieden sich für Lean-Manufacturing-Ansätze und japanische Effizienztechniken. Andere konzentrierten sich auf Ergebnisse, mit anwendungsfallorientiertem Design und eXtreme-Programmierung, wobei es bei beiden darum ging, nur Dinge zu erledigen. Als ich Menschen in agilen Entwicklungsmethoden wie DSDM schulte, waren solche Ansätze jedoch die Ausnahme.

Und dann erschien eine neue Realität, angetrieben vom Web, Open Source, RESTful APIs und vielem mehr, in der Kinder Dinge erledigten und ältere, knusprigere Ansätze übersprangen. Websites und Apps mussten schnell entwickelt werden. Sie mussten schnell zusammengesetzt und dort veröffentlicht werden. Die Leute fingen an zu sagen: Sehen Sie, können wir diese Website erst nächste Woche bekommen?

Das Bedürfnis nach Geschwindigkeit war sehr stark von Angst getrieben, und wir sehen dies auch heute noch, wenn Unternehmen (zu Recht, aber hyperbolisch) erfahren, wie sie sich verändern müssen oder das Risiko eingehen, aus dem Geschäft auszusteigen. Mit der Beschleunigung der Softwareentwicklung kam es jedoch zu neuen Herausforderungen und Engpässen – nicht zuletzt zu der Notwendigkeit, Veränderungen zu kontrollieren (eines der Grundprinzipien von DevOps im Jahr 2007).

Schneller Vorlauf bis heute, und es gibt eine ganze Reihe neuer Herausforderungen. Tatsache ist, dass jeder Ansatz, wenn er universell angewendet wird, letztendlich Schwächen aufweist. In diesem Fall wirkt sich eine „gerechte“ schnelle Entwicklung der Dinge nachteilig auf andere Aspekte aus, z. B. eine gute Entwicklung (vgl. Qualität und Sicherheit der Verschiebung nach links) oder die Bereitstellung von Dingen, die einen positiven Unterschied bewirken.

Letzteres ist der Punkt, an dem VSM einsetzt. Es dient im Wesentlichen dazu, eine Lücke zu schließen: Wenn Sie nicht darüber nachdenken, ob Sie die richtigen Dinge auf die richtige Weise tun, ist es wahrscheinlich an der Zeit, anzufangen. Wir befinden uns jetzt in einer Zeit, in der agile Praktiken, die früher die Ausnahme waren, zur Norm geworden sind. Aber Agilität selbst reicht nicht aus: „Managed Agile“ ist das, was benötigt wird.

Das bringt uns zu einer weiteren Herausforderung. Die Welt hat sich von Szenarien, in denen jeder Dinge auf die gleiche Weise (Wasserfall) baute, zu Entwicklungsprozessen entwickelt, die sich je nach den Wünschen der Menschen ändern. Dies ist großartig, wenn Sie gerade erst loslegen und sich auf das Bauen konzentrieren möchten, aber nicht so gut, wenn Sie beispielsweise Teams wechseln und weitermachen möchten, ohne zu lernen, wie alles wieder funktioniert.

Ehrlich gesagt sind Entwicklungsprozesse fragmentiert, ineffizient, umständlich und kostspielig geworden. Was nicht gut ist – Teams möchten nicht ihre Zeit damit verbringen, Prozesse und Tools zu verwalten, wenn sie coole neue Anwendungen erstellen könnten. Und hier kommt VSM ins Spiel.

Der Begriff Wertstrom stammt aus der Fertigung. Ich denke, der einfachste Weg, darüber nachzudenken, besteht darin, darüber nachzudenken, was Sie als einen Strom von Aktivitäten liefern möchten, die Wert aufeinander aufbauen. Denken Sie also zunächst an die Entwicklungspipeline als Wertstrom. Machen Sie es effizient und effektiv und versuchen Sie dann, Wertströme im gesamten Unternehmen zu standardisieren.

Jemand hat mich kürzlich gefragt: Wendet VSM jetzt nicht nur Geschäftsprozessmodellierungs- und -verwaltungstechniken auf Software an? Und ich antwortete: Es geht nur darum, Geschäftsprozessmodellierung und -verwaltung auf die Softwareentwicklung anzuwenden. Dies geht auf die Definition eines Geschäftsprozesses durch Hammer und Champy zurück: Es handelt sich um eine Abfolge von Aktivitäten, die einem Kunden einen Mehrwert bieten, und genau das sollte die Softwarebereitstellung sein.

Die Verwaltung von Wertströmen ist vorhanden, da dies derzeit erforderlich ist, obwohl sie an vielen Stellen nicht vorhanden ist, an denen versucht wird, DevOps-Praktiken zu implementieren. Es ist also wirklich die Wiedereinsetzung bewährter Management-Governance- und Sichtbarkeitsprinzipien in sich schnell bewegende, dynamische und agile Umgebungen.

Wird VSM dauern? Das ist eine weitere gute Frage. Ich höre, dass einige Organisationen VSM als einen weiteren Aufwand ansehen (Hinweis: Sie machen es wahrscheinlich falsch). Ich bin auch der Meinung, dass wir, wenn wir als Kollektiv von Befürwortern von Entwicklung und Betrieb zustimmen könnten, dass wir nicht jedes einzelne Projekt benötigen, um Best Practices neu zu erfinden, unsere Pipelines wahrscheinlich stärker standardisieren könnten, um mehr Zeit für den Einstieg zu haben mit, ja, den coolen Sachen.

Ich möchte keine Rückkehr zu belastenden Methoden wie dem Wasserfall sehen. Ich möchte, dass Innovatoren innovativ sind, Entwickler sich entwickeln und Betreiber mit minimalem Stress arbeiten. Ich beobachte mit Interesse den Schritt des DevOps-Instituts zur Bewertung von Fähigkeiten, freue mich über die Übernahme produktbasierter Ansätze in der Softwareentwicklung und spreche mit mehreren Anbietern darüber, wie wir Pipelines als Codeform in eine Terraform sehen könnten -wie offener Standard.

Alle diese Themen fördern einen kohärenteren zukünftigen Ansatz. Es gibt einen Katalysator für all dies, nämlich Microservices-Ansätze, die angesichts der Komplexität, die sie erzeugen, um Unkompliziertheit bitten. Vgl. Ein kürzlich geführtes Gespräch mit Tracy Regan von DeployHub über die Notwendigkeit der Verwaltung der Anwendungskonfiguration.

Mir ist klar, dass ich die Frage noch nicht beantwortet habe. Ich glaube, VSM wird sich durchsetzen, aber als Merkmal umfassenderer End-to-End-Tools und -Plattformen und nicht als zusätzliche Ebene. Verwaltete Wertströme sind eine gute Sache, aber Sie sollten dafür kein separates Tool benötigen, das vom Rest Ihrer Toolchain isoliert ist.

Letztendlich ist VSM also keine massive Offenbarung. Es ist einfach ein Symptom dafür, wo wir uns befinden, da wir versuchen, softwarebasierte Innovationen in großem Maßstab bereitzustellen. Die Reise ist noch lange nicht vorbei, aber sie erreicht einen Ort der Konvergenz, der auf Mikrodiensten basiert (die ironischerweise auf modulare Gestaltungsprinzipien von 1974 zurückgehen). Best Practice ist im Entstehen begriffen und wird die Standards und Plattformen liefern, die wir für die Zukunft benötigen.

.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.