2.0 Einführung zu Teil 2: Flow-Metriken

Wenn Teil 1 die Philosophie der Messung ist, ist Teil 2 dort, wo diese Philosophie auf die Lieferung selbst trifft: die Metriken, die nicht nur beschreiben, wie schnell und wie sicher ein Team Code von einer Idee zu einem laufenden System bewegt, sondern welche Art von Wert überhaupt durch diese Pipeline fließt. Dieser Teil ist um das Flow Framework herum organisiert, ein Modell, das Mik Kersten in seinem Buch Project to Product von 2018 geschaffen hat und das Softwarelieferung als Wertstrom behandelt und diesem Wertstrom ein gemeinsames Vokabular gibt: vier Flow-Item-Typen und fünf Flow-Metriken, die Engineering-Aktivität mit Geschäftsstrategie in Begriffen verbinden, die eine nicht-technische Stakeholderin oder ein nicht-technischer Stakeholder tatsächlich nutzen kann.

Diese Wahl des organisierenden Frameworks ist bewusst. Die DORA-Metriken, Deployment-Frequenz, Lead Time, Change Failure Rate und Wiederherstellungszeit, sind echt forschungsbasiert validiert und bleiben eines der am besten belegten verfügbaren Lieferframeworks, aber sie messen die Mechanik der Pipeline, nicht das, was durch sie fließt. Ein Team kann hervorragende DORA-Zahlen vorweisen, während sein tatsächlich gelieferter Wert still zu Nacharbeit abgedriftet ist oder weg von der Schulden- und Risikoarbeit, die die Zukunft eines Systems schützt. Dieser Teil behandelt DORA vollständig, aber als einzelnes, konsolidiertes Referenzthema am Ende (Thema 2.10), weil die dringlichere, häufiger fehlende Frage für die meisten Organisationen nicht „wie schnell ist unsere Pipeline” ist, sondern „was liefert unsere Pipeline tatsächlich”. Jedes Thema dieses Teils folgt weiterhin derselben Disziplin, die in Teil 1 etabliert wurde: die Metrik benennen, benennen, wie sie manipuliert wird, und sie mit der Leitplanke paaren, die diese Manipulation fängt.

Für große Teams sind Flow-Metriken das, was teamübergreifenden Vergleich möglich macht, ohne den Wert aus den Augen zu verlieren. Ein Plattform-Team, ein Mobile-Team und ein Daten-Team können in ihrer täglichen Arbeit fast nichts gemeinsam haben, aber Flow-Velocity und Flow-Verteilung, konsistent berechnet, lassen die Führungsebene eine faire Frage über alle drei hinweg stellen: Liefert dieses Team die Art von Wert, die seine aktuelle Phase tatsächlich erfordert. Konzerne und Behörden verlassen sich auf die Metriken dieses Teils, um Plattforminvestitionen zu rechtfertigen, die Rendite konkurrierender Modernisierungsbemühungen zu vergleichen und mit Belegen statt Anekdoten zu zeigen, dass Engineering-Kapazität so zugewiesen wird, wie die Führungsebene glaubt.

Themen in diesem Teil

2.1 Das Flow Framework: Der Ursprung des Frameworks, sein Wertstrommodell, und warum dieses Buch es nutzt, statt nur DORA, um Liefer- und Flow-Metriken zu organisieren.
2.2 Flow-Items: Features, Defekte, Risiken und Schulden: Die Vier-Typen-Taxonomie des Frameworks, ihre Nullsummen-Kapazitätszuweisung, und wie Klassifikation manipuliert wird, wenn sie rückwirkend angewendet wird.
2.3 Flow-Velocity und Flow-Verteilung: Wie viel ausgeliefert wurde und welche Art von Wert es war, immer gemeinsam gelesen.
2.4 Flow-Zeit und Flow-Last: Wie Littles Gesetz beweist, dass ein überlasteter Wertstrom sich mathematisch verlangsamt, nicht nur wahrscheinlich.
2.5 Flow-Effizienz und Work in Process: Warum beschäftigt nicht dasselbe ist wie schnell, und wie die Begrenzung von Work in Process den Durchsatz kontraintuitiv verbessert.
2.6 Zykluszeit und ihre Bestandteile: Die Engineering-Zeit einer Änderung in ihre einzelnen Phasen aufzuschlüsseln, damit ein Team genau weiß, wo die Zeit tatsächlich hingeht.
2.7 Queueing-Theorie: Die Mathematik unter Flow-Last, Flow-Zeit, Zykluszeit und Work in Process, und warum die Wartezeit auf eine gemeinsam genutzte Ressource explodiert, je näher die Auslastung an ihre Grenze kommt.
2.8 Lean-Wertstrom-Metriken: Das klassische Lean-Werkzeugset, Lead Time, Prozesszeit, Zykluszeit, Percent Complete and Accurate und Taktzeit, von dem die softwarespezifischen Metriken dieses Teils abstammen, und wie die beiden Vokabulare verbunden werden.
2.9 Pull-Request- und Code-Review-Metriken: Die Metriken, die innerhalb einer einzelnen Phase der Lieferpipeline leben, und wie sie die Review-Qualität verzerren können, wenn sie unbedacht genutzt werden.
2.10 Das DORA-Metriken-Framework: Die vier DORA-Metriken vollständig, bewusst zuletzt platziert, weil sie die Pipeline messen, nicht den Wert, der durch sie fließt.

Wie diese Themen zusammenhängen

Thema 2.1 führt das Flow Framework als Ganzes ein; Thema 2.2 gibt seine Taxonomie der Flow-Items, und die Themen 2.3 und 2.4 behandeln zusammen seine fünf Flow-Metriken, Velocity und Verteilung gemeinsam, dann Zeit und Last gemeinsam, wobei Last und Zeit direkt an Littles Gesetz gebunden sind. Die Themen 2.5 bis 2.7 zoomen speziell auf die Mechanik unter Flow-Zeit und Zykluszeit: Flow-Effizienz und Work in Process erklären, warum Engineering-Phasen oft langsamer sind, als sie aussehen, Zykluszeit zerlegt diesen Engineering-Anteil in seine Phasen, und Queueing-Theorie formalisiert in beweisbaren mathematischen Begriffen, warum alle Behauptungen der vorangegangenen Themen über Last, Wartezeit und Auslastung zutreffen. Thema 2.8 tritt einen Schritt zurück, um all das bis zu seinem Ursprung im klassischen Lean-Wertstromdenken zurückzuverfolgen, dem gemeinsamen Vokabular, von dem die softwarespezifischen Metriken dieses Teils verallgemeinern. Thema 2.9 behandelt die einzelne Pipeline-Phase, die die meisten Teams am schnellsten verbessern können. Thema 2.10 schließt den Teil mit den DORA-Metriken vollständig ab, präsentiert als gut belegte, aber engere Referenzebene, sobald das breitere, geschäftsseitige Bild aus den früheren Themen bereits im Blick ist.

Die Leitplanken-Disziplin dieses Teils knüpft direkt an Thema 1.2 an: Flow-Velocity wird nie ohne begleitende Flow-Verteilung berichtet, und die Geschwindigkeitsmetriken von DORA bleiben mit seinen Stabilitätsmetriken gepaart, sodass ein Team eine Geschwindigkeitszahl nicht verbessern kann, indem es still riskanteren Code oder eine engere Wertmischung ausliefert. Diese Paarung ist bei keinem der beiden Frameworks Zufall; sie ist die zentrale Einsicht jedes Frameworks, und die Zuverlässigkeitsmetriken in Teil 6 verlängern dieselbe Stabilitätshälfte dieser Paarung in den Produktionsbetrieb, sobald Code bereits ausgeliefert wurde.