Mike Bild
post

Developer Productivity: verkürzte Zyklen bei hoher Qualität

Produktivität ist nicht mehr Stunden, sondern kurze Feedbackschleifen mal Qualität. Der Engpass ist fast nie das Tippen, sondern das Warten – auf Build, Review und Umgebung.

≈ 8 Min. Lesezeit
SoftwareDelivery

Wenn ich in Teams gerufen werde, weil die Delivery zu langsam sei, höre ich fast immer denselben ersten Satz: „Wir bräuchten mehr Leute.“ Und fast immer stimmt er nicht. Nach ein, zwei Tagen im System zeige ich dieselbe Rechnung: Ein Change wird in vielleicht zwei Stunden geschrieben und liegt danach drei Tage in der Leitung – im Build, in der Review-Queue, in der Warteschlange auf eine Testumgebung. Es wird nicht zu wenig getippt. Es wird zu lange gewartet.

Genau darum geht es in diesem Text. Ich will die verbreitete Gleichung „Produktivität = geleistete Stunden“ durch eine bessere ersetzen: Produktivität = kurze Feedbackschleifen × Qualität. Zwei Dinge sind an dieser Formel wichtig. Erstens: Es ist ein Produkt, keine Summe. Fällt die Qualität auf null, fällt die Produktivität auf null – egal, wie schnell Sie deployen. Zweitens: Der Hebel ist die Zykluszeit, nicht das Volumen. Wer die Zeit von der Idee bis zur Rückmeldung halbiert, verdoppelt nicht die Tastenanschläge, sondern die Anzahl der Lernschritte pro Woche.

Speed und Stability sind kein Trade-off

Der hartnäckigste Denkfehler in dieser Diskussion ist die Annahme, man müsse sich zwischen Tempo und Stabilität entscheiden. „Wir könnten schneller liefern, aber dann bricht mehr“ – diesen Satz höre ich in Steering-Runden regelmäßig. Die Daten sagen das Gegenteil.

Der Zentralbefund aus Accelerate (Forsgren, Humble, Kim, 2018), die Buchfassung der DORA-Forschung mit über 23.000 Antworten aus mehr als 2.000 Organisationen, ist eindeutig: High-Performer sind bei Geschwindigkeit und Qualität besser. Nirgends in den Daten erkauft sich ein Team das eine durch das andere. Die schnellen Teams sind auch die stabilen. Das ist keine Meinung, sondern ein statistischer Zusammenhang – und er ist das Fundament für die These, dass Zyklen und Qualität kein Nullsummenspiel sind, sondern sich gegenseitig tragen.

Operationalisiert wird das über die vier DORA-Metriken, die genau diese zwei Dimensionen messen. Für den Durchsatz: Deployment Frequency und Lead Time for Changes – die Zeit von Commit bis Produktion. Für die Stabilität: Time to Restore Service (die Zeit bis zur Wiederherstellung nach einem Incident) und Change Failure Rate – der Anteil der Deployments, die einen Fehler verursachen. Die Lead Time ist dabei die messbar gemachte „kurze Feedbackschleife“ aus meiner Formel. Wer sie senkt, senkt genau die Wartezeit, um die es hier geht.

Ein Hinweis zur Präzision, weil das oft schlampig zitiert wird: Die State-of-DevOps-Reports haben Teams jahrelang in Cluster einsortiert – 2021 noch mit einer eigenen „Elite“-Gruppe. Der 2022er Report fand nur noch drei Cluster (High, Medium, Low), kein „Elite“ mehr. Wer heute mit „laut DORA sind Elite-Teams…“ argumentiert, sollte wissen, aus welchem Jahr die Zahl stammt.

Warum der Engpass das Warten ist

Continuous Integration wird oft als „Tooling“ verstanden – man richtet einen Build-Server ein, Haken dran. Der Sinn ist ein anderer. Martin Fowler definiert CI als Praxis, bei der Teammitglieder häufig integrieren und jede Integration durch einen automatisierten Build inklusive Tests verifiziert wird, um Integrationsfehler so früh wie möglich zu erkennen. Das entscheidende Wort ist „früh“. CI ist eine Latenz-Maschine: Sie verkürzt die Zeit zwischen einem Fehler und seiner Entdeckung. Der Engpass, den CI adressiert, ist Warte- und Integrationslatenz – nicht Code-Volumen.

Die Deployment-Pipeline (ebenfalls Fowler) ist der bewusste Umgang mit dieser Latenz. Man zerlegt den Weg zur Produktion in Stages: Frühe Stages geben in Sekunden bis Minuten schnelle Zuversicht, spätere sind gründlicher und dürfen dafür langsamer sein. Das ist kein technisches Detail, sondern eine Gestaltungsentscheidung darüber, wo Feedback schnell und wo es gründlich sein soll.

pipeline:
  - stage: commit          # target: < 10 min  -> fastest feedback
    steps: [compile, unit_tests, static_analysis]
  - stage: acceptance      # target: minutes   -> contract & integration
    steps: [contract_tests, integration_tests]
  - stage: deploy_staging  # ephemeral environment on demand
    steps: [provision_env, smoke_tests]
  - stage: production      # gated by feature_flag, not by branch age
    steps: [progressive_rollout, health_check]

Wenn ich mit einem Team vor so einem Skelett sitze, stelle ich immer dieselbe Frage: Wo geht die Zeit real verloren? Die Antwort ist selten unit_tests. Sie ist compile, wenn der Commit-Build zwölf Minuten braucht statt unter zehn. Sie ist review, wenn ein Pull Request zwei Tage in der Queue liegt. Sie ist provision_env, wenn eine Testumgebung von Hand beantragt und über Nacht bereitgestellt wird. Das sind die eigentlichen Latenzhebel. Das Schreiben der Tests – die „Tipp-Kante“ – ist fast nie das Problem.

Das erklärt auch, warum „shift left“ mehr ist als ein Buzzword. Ein Vertragsbruch zwischen zwei Services, der erst in einer nächtlichen End-to-End-Umgebung auffällt, kostet einen Tag. Derselbe Bruch, der im Commit-Build auffällt, kostet Minuten. Es ist derselbe Fehler – nur die Feedbacklatenz unterscheidet sich um Größenordnungen.

Die zwei Schleifen

Kurze Zyklen gibt es auf zwei Ebenen, und ich sehe oft, dass Teams nur eine davon optimieren. Die innere Schleife ist die Delivery: code → commit → build → automated tests → review → deploy, gemessen in Minuten. Die äußere Schleife ist die Discovery: hypothesis → build → measure → learn, gemessen in Tagen bis Wochen. Die innere Schleife stellt sicher, dass Sie schnell und sicher etwas ausliefern. Die äußere stellt sicher, dass es das Richtige ist.

Diese äußere Schleife wird gern vergessen, dabei ist sie derselbe Gedanke auf der Produktebene. Eric Ries hat sie im Lean Startup (2011) als Build–Measure–Learn mit dem Ziel des validated learning beschrieben. Teresa Torres hat sie in Continuous Discovery Habits (2021) konkretisiert: wöchentliche Kundeninterviews, der Opportunity Solution Tree als Landkarte der Möglichkeiten, systematisches Assumption Testing. Auch hier zählt nicht mehr Output, sondern kürzere Lernzyklen. Ein Team, das seine innere Schleife auf Minuten drückt, aber ein halbes Jahr wartet, bevor es merkt, dass das Feature niemand braucht, hat den falschen Engpass optimiert.

flowchart LR
  subgraph inner["Inner loop – Delivery (minutes)"]
    code["code"] --> commit["commit"]
    commit -->|"wait: build"| build["build"]
    build --> tests["automated tests"]
    tests -->|"wait: review"| review["review"]
    review -->|"wait: provision env"| deploy["deploy"]
  end
  subgraph outer["Outer loop – Discovery (days / weeks)"]
    hypothesis["hypothesis"] --> buildit["build"]
    buildit --> measure["measure"]
    measure --> learn["learn"]
    learn --> hypothesis
  end
  deploy --> measure
  learn -.-> code

Die dicken Kanten in dieser Skizze sind bewusst die Wartekanten: build, review, provision env. An ihnen entscheidet sich die Zykluszeit. Die DORA-Lead-Time misst die innere Schleife, die Discovery-Kadenz die äußere. Beide zusammen ergeben die Zahl, die zählt: wie oft ein Team pro Woche etwas Validiertes lernt.

Qualität ist das Netz, nicht die Bremse

Jetzt der Teil, den man in der Tempo-Euphorie gern überspringt. Die Formel ist multiplikativ. Kurze Zyklen ohne Qualitätsnetz bedeuten nicht „schneller liefern“, sondern „schneller kaputtgehen“. Wer die Batch-Size reduziert und häufiger deployt, ohne automatisierte Tests, Contract-Tests und eine echte Deployment-Pipeline, senkt vor allem eines: die Zeit bis zum nächsten Incident. Batch-Size-Reduktion ohne Stabilitätsmechanismen verlagert den Engpass nur – vom Warten vor dem Deploy zum Aufräumen danach.

Deshalb gehört Qualität in dieselbe Pipeline wie das Tempo. Ein Mechanismus, den ich fast immer empfehle, wenn Services über Grenzen hinweg kommunizieren, ist Consumer-Driven Contract Testing. Die Idee (sie geht auf Ian Robinson und Fowler, 2006, zurück und ist mit Frameworks wie Pact breit etabliert): Der Konsument beschreibt, was er vom Provider erwartet, und diese Erwartung wird auf beiden Seiten unabhängig verifiziert – ohne eine gemeinsame, langsame End-to-End-Umgebung hochziehen zu müssen.

// consumer side: describe the expectation, generate a pact file
consumerTest("fetches a user by id", () => {
  provider
    .given("a user exists")
    .uponReceiving("a request for user 42")
    .withRequest({ method: "GET", path: "/users/42" })
    .willRespondWith({
      status: 200,
      body: { id: 42, name: like("Ada") }, // matcher, not a fixed value
    });
  // -> produces a pact contract, verified in the provider's own pipeline
});

Der Gewinn ist doppelt. Der Contract-Test läuft in der acceptance-Stage in Sekunden statt der End-to-End-Test in Minuten in einer eigens provisionierten Umgebung – die Feedbackschleife an der Service-Grenze wird kürzer. Und er ist präziser: Er sagt nicht nur „irgendwas ist rot“, sondern „der Provider liefert name nicht mehr“. Das ist Qualität, die Tempo ermöglicht, statt es zu bremsen.

Auf Architekturebene gehört derselbe Gedanke dazu. Michael Nygard hat in Release It! (2007, 2. Auflage 2018) die Stability Patterns beschrieben – Circuit Breaker, Bulkhead und Verwandte –, damit ein Fehler in einem Teil nicht das Ganze mitreißt. Und Neal Ford, Rebecca Parsons und Patrick Kua haben in Building Evolutionary Architecture (2017) die Idee der Fitness Functions eingeführt: automatisierte, ausführbare Prüfungen für Architektureigenschaften wie Latenz, Kopplung oder Sicherheit. Beides ist dieselbe Bewegung wie bei den Tests – Qualität wird zu etwas Ausführbarem gemacht, das in der Pipeline schnell Feedback gibt, statt in einem Review-Dokument zu verstauben.

Wie man kurze Zyklen konkret baut

Aus der Praxis ein paar Hebel, die zuverlässig wirken – geordnet nach dem, was die Wartekanten am direktesten trifft.

Der Commit-Build muss schnell sein. Fowlers Faustregel vom „ten-minute build“ ist keine Nostalgie, sondern eine psychologische Grenze: Dauert der Build länger, hört das Team auf, häufig zu integrieren, und die Batches wachsen wieder. Eine schnelle, breite Basis aus Unit-Tests und eine schmale Spitze aus langsamen End-to-End-Tests – die klassische Testpyramide – hält den Build schnell, ohne Deckung zu verlieren.

Branches kurz halten. Trunk-Based Development mit kurzlebigen Feature-Branches und Feature Flags entkoppelt „Code ist gemerged“ von „Feature ist an“. Das ist der Punkt, an dem production durch ein Feature-Flag gated wird, nicht durch das Alter eines Branches. Lang lebende Branches sind der klassische Weg, wie sich Integrations-Wartezeit unsichtbar aufstaut, bis der Merge zum Tagesprojekt wird.

Umgebungen on demand. Wenn provision_env ein Ticket an ein anderes Team ist, ist Ihre Lead Time keine technische, sondern eine organisatorische Größe. Ephemere, per Skript erzeugte Umgebungen nehmen diese Kante aus der Warteschlange.

Und der Punkt, der am meisten Konflikt auslöst: Messen Sie das System, nicht die Person. Die vier DORA-Metriken sind Team- und System-Outcome-Metriken. Als individuelles Entwickler-Ranking missbraucht, erzeugen sie sofort Goodhart-Effekte – man optimiert die Zahl statt die Sache. Wer an „Deployments pro Entwickler“ gemessen wird, produziert Micro-Deploys; wer an der Change Failure Rate gemessen wird, deklariert Incidents um. Forsgren und Kollegen haben explizit vor solchen Vanity- und Individual-Metrics gewarnt. Die Metriken zeigen die Gesundheit eines Flusses, nicht die Leistung eines Einzelnen.

Fazit

Produktivität in der Softwareentwicklung ist keine Frage der geleisteten Stunden. Sie ist das Produkt aus kurzen Feedbackschleifen und Qualität – und der Engpass, der die Schleifen verlängert, ist fast nie das Tippen. Es ist das Warten: auf den Build, auf die Review, auf die Umgebung. Die Accelerate-Daten zeigen, dass Tempo und Stabilität zusammen steigen, wenn man es richtig macht; die DORA-Lead-Time macht die innere Schleife messbar; Contract-Tests, Stability Patterns und Fitness Functions machen Qualität ausführbar, statt sie in Reviews zu vertagen; und die Discovery-Schleife sorgt dafür, dass man das Richtige schnell lernt.

Mein pragmatischer Rat, wenn Sie morgen anfangen wollen: Zeichnen Sie Ihre innere Schleife auf und schreiben Sie an jede Kante die reale Wartezeit. Der dickste Balken ist Ihr nächstes Projekt – meistens nicht dort, wo alle vermuten. Und behalten Sie die Formel im Kopf: kurze Zyklen mal Qualität. Beides. Das eine ohne das andere ist entweder langsam oder kaputt. Einfach und elegant ist nicht der Prozess mit den meisten Gates, sondern der mit den kürzesten Wartezeiten bei intaktem Netz.

Weiterführende Quellen

Kommentare