Value Stream Mapping für früheres Vertrauen

Value Stream Mapping (VSM) ist ein nützliches Werkzeug, um die verschiedenen Aktivitäten bei der Softwareentwicklung zu verstehen und Engpässe zu identifizieren.

Einer der besten Aspekte dieser Übung ist, dass jeder diese Visualisierung versteht, so dass es ein gemeinsames Verständnis des Softwareentwicklungsprozesses gibt.

In den letzten Jahren habe ich eine Variation der Wertstromkarte verwendet. Indem ich der Gleichung 'Vertrauen' hinzufügte, um ein gemeinsames Verständnis dessen zu erhalten, was geschieht, und um Änderungen in den Lieferstrategien zu visualisieren.

Schritt 1: Visualisieren Sie die Lieferschritte

Zeichnen Sie gemeinsam mit dem Team die verschiedenen "Stadien" auf, in denen sich die Änderungen befinden. Dabei kann es sich um den Code in einem bestimmten Zweig oder um die Bereitstellungsumgebung eines Artefakts handeln.

Markieren Sie außerdem, welche "Gates" vorhanden sind - welche Art von Tests oder Prüfungen durchgeführt werden und ob diese vollständig automatisiert oder manuell sind.

Schritt 2: Fügen Sie Messungen und 'Vertrauen' hinzu.

Entscheiden Sie bei jedem Schritt gemeinsam mit dem Team, wie lange er typischerweise dauert. Für den Anfang kann sich das Team auf die Dauer einigen, aber wenn es sich auf Daten stützt, können bessere Entscheidungen getroffen werden.

Neben der Dauer achtet das Team auch auf den unglücklichen Verlauf, z.B. entdeckte Fehler, Build-Fehlschläge usw. Diese beiden Messgrößen sind vergrößerte Versionen der DORA-Metriken 'Vorlaufzeit' und 'Änderungsfehlerrate'.

Was schwieriger zu messen ist, ist das 'Vertrauen'. Aber es ist eine nützliche Übung, auch dies zu erfassen. Tests, die nie aus den richtigen Gründen scheitern, sorgen eher für ein geringes Vertrauen, während eine Überprüfung, die zu nützlichem Feedback führt, einen enormen Schub geben kann.

Entscheiden Sie gemeinsam mit dem Team, wie viel Vertrauen Sie in jeden einzelnen Schritt setzen. Die Unit-Tests könnten z.B. wenig Vertrauen schaffen, während eine lang laufende 'Regressionssuite' einen enormen Schub geben könnte.

Schritt 3: shift-links Vertrauen

Die Ergebnisse der vorangegangenen Übungen werden genutzt, um die Diskussion anzuregen und Fragen zu beantworten:

• "Was ist notwendig, um das Vertrauen zu erlangen, das wir früher erhalten haben?"
  z.B. was deckt die 'Regression Suite' ab, was die Unit-Tests nicht können?
• "Ist jeder Schritt überhaupt sinnvoll?"
• "Welche 'optionalen' Schritte sollten wir zu einem automatisierten Quality Gate machen?"
  zum Beispiel, Prüfungen, die manche Leute in ihrer IDE haben, könnten auch als Teil der Pipeline ausgeführt werden?

Versuchen Sie, zumindest ein paar kleine Verbesserungen oder Automatisierungen zu identifizieren und diese in eine neue Version der Visualisierung einzuzeichnen. Der erste Schritt besteht darin, das Vertrauen früher zu verbessern, so dass andere Schritte möglicherweise weniger wichtig werden und der Prozess vereinfacht werden kann.

Die Auslieferungspipeline kann als Trichter betrachtet werden, bei dem in der Regel mehr Änderungen eingehen als Implementierungen in die Produktion gehen. Je höher dieses Verhältnis ist, desto länger verzögert sich die Softwarebereitstellung und desto größer ist der Umfang der bereitzustellenden Arbeit - was das Risiko der Inbetriebnahme jeder Änderung erhöht.

Das Ziel ist es, früher und effizienter Vertrauen zu schaffen, so dass letztendlich mehr Änderungen in die Produktion übernommen werden können.

Fazit

Das Hinzufügen von Vertrauen zur Wertstromanalyse ist ein nützliches Werkzeug, um (über-)komplizierte Lieferungen zu verstehen und zu verbessern. Um verschwenderische Schritte zu eliminieren und kontinuierlich zu liefern, ist es notwendig, früh im Prozess Vertrauen zu gewinnen.

Es ist wichtig zu erwähnen, dass dieser Ansatz davon ausgeht, dass alle Änderungen Ihres Teams wertvoll sind. Er übt Druck auf den internen Lieferprozess aus, stellt aber Ihre Produktstrategie (d.h. das, was für Ihre Kunden wirklich wertvoll ist) möglicherweise nicht in Frage.

Haben Sie Fragen? Wenden Sie sich bitte an uns

Dieser Blog ist Teil unserer Serie "


Ganzheitliche Horizonte


". Sehen Sie sich den vorherigen Eintrag an - "Das Kostenparadoxon der Cloud" von Albert Starreveld. Oder lesen Sie weiter zum nächsten Artikel - "Ich denke über die Produktivität von Entwicklern nach" von Jochum Börger.