Wir wollen in loser Folge die Fragen aus unserem Flow Check, 15 Schritte zum besseren Software-Lieferprozess aufgreifen und konkrete Schritte zur Verbesserung aufzeigen.

Frage 1 lautet: “Liefern Sie regelmäßig, mindestens einmal pro Monat, Software?”

Um es nochmal klar zu sagen: mit Liefern meinen wir die Auslieferung in den Produktivbetrieb, nicht etwa nur “Diese Iteration ist fertig und abgenommen”. Und regelmäßig heißt: in einem festen Rhythmus, also z.B. ein Release alle 4 Wochen, so dass die nächsten Release-Termine absolut vorhersehbar sind.

Sie würden gern in einem festen Rhythmus liefern, aber es kommt immer wieder etwas dazwischen?

Bevor Sie anfangen, den Release-Zyklus zu verkürzen, sollten Sie erstmal in der Lage sein, regelmäßig zu liefern. Die häufig vorkommenden Probleme und praktikable Lösungsmöglichkeiten haben wir hier zusammengestellt.

Grund 1: Es dauert immer wieder länger, als wir dachten

Schon die erste Umsetzung der Features dauert länger als erwartet, da muss eben das Release warten, bis alle versprochenen Features (oder Bugfixes, oder sonstigen Anforderungen) fertig sind. Vielleicht erleben Sie auch diese Variante: Wir merken im Laufe des Releases, dass wir nicht fertig werden. Dann verhandeln wir über eine Verringerung das Scopes. Aber auch nachdem wir depriorisiert haben, werden wir innerhalb des geplanten Release-Zeitraums nicht fertig.

Machen Sie den Release-Termin zum Feature Nummer 1. Die fertigen Features verdienen es nämlich, so früh wie möglich in Produktion zu kommen.

Geben Sie Schätzungen statt Versprechen ab. Sagen Sie: “Wir schätzen, dass wir Features A, B, C und D im nächsten Release fertig haben” statt: “Das nächste Release wird A, B, C und D enthalten”. Dahinter steht der Gedanke, den Scope variabel zu machen:

• Zeit ist fest (z.B. vier Wochen)
• Kosten sind fest (Kosten für das Team über vier Wochen)
• Qualität ist fest (hoch)
• Scope (Funktionsumfang) ist variabel

Die gesamte Unsicherheit der Schätzung wird im Faktor Scope konzentriert, damit man bei den anderen drei Faktoren verlässliche Zusagen machen kann.

Oft wird der Release-Termin auch geopfert, weil einige Features noch nicht ganz fertig sind. Sie haben also z.B. zum geplanten Release-Termin nur 5 von 10 Features fertig. Die restlichen fünf hängen alle irgendwo zwischen 80% und 100%, etwa so:

Also werden Sie “noch ein bißchen mit dem Release warten”, statt nur die ersten 5 Features auszuliefern. Daraus werden leicht wochenlange Verzögerungen, weil immer etwas anderes schief geht. Unter Zeitdruck (wir sind ja spät dran mit dem Release) werden Kompromisse bei der Qualität oder der Vollständigkeit gemacht.

Der Rat ist einfach: Bearbeiten Sie weniger Dinge gleichzeitig, dann gibt es auch weniger unfertige Features. Die Anzahl an unfertigen Features zu begrenzen, entspricht dem Lean-Prinzip: Limit WIP (work in process). Im obigen Beispiel könnten Sie etwa 9 von 10 Features zum geplanten Release-Termin fertig haben (100%):

In der Umsetzung dieses Ratschlags werden Sie merken, dass Sie auf substanzielle (d.h. auch schwierige) Verbesserungen in Ihrem Software-Lieferprozess stoßen. Dafür werden Sie u.a. mit besserer Qualität belohnt.

Unfertige Features (WIP) entsteht auch durch das Arbeiten in großen Stapeln (Batches). So wird manchmal zunächst alles entwickelt, gefolgt von einer Test-und-Fix-Phase, die alle Features gemeinsam durchlaufen. Diese Phase findet natürlich erst gegen Ende des Release-Zyklus statt. Zerlegen Sie besser das Release in mehrere kleinere Stapel, oder testen Sie ein Feature gleich im Anschluss an die Entwicklung. Noch besser (aber schwieriger): entwickeln Sie automatisierte Akzeptanztests vor der eigentlichen Implementation.

Man könnte natürlich auch versuchen, das Problem “Es dauert immer wieder länger als gedacht” zu bewältigen, indem man zuverlässiger schätzt. Manchmal können Sie Unterschätzungen vermeiden, indem Sie das Feature in kleinere Einheiten zerlegen. Insgesamt ist zuverlässig schätzen ziemlich aufwändig, weswegen einige Teams auf Schätzungen ganz verzichten, oder nur grobe Skalen wie T-Shirt-Größen (S, M, L, XL) benutzen.

In Scrum werden unzuverlässige Schätzungen kompensiert, indem in festen Timeboxes gearbeitet wird (eine Iteration), an deren Ende potenziell lieferbare Software steht. Die Menge an unfertigen Features (WIP) ist im Wesentlichen begrenzt auf den Inhalt einer Iteration. Man kann sich auch nur maximal um den Aufwand für eine Iteration verschätzen.

Kanban bzw. Lean Software Development begrenzt WIP in allen Phasen der Entwicklung. Der “Überhang” an unfertigen Features kann dann nicht größer werden als die Summe der WIP-Limits in den relevanten Phasen. Kanban legt einen Schwerpunkt auf den gleichmäßigen Fluß (flow) von Features durch den Entwicklungsprozess. Wenn das richtig gemacht wird, ist man quasi jederzeit Release-fähig; man liefert zum Termin das, was fertig ist. Vorhersagen zum Inhalt des Releases kann man anhand von Statistiken zur Durchlaufzeit machen.

Grund 2: Einige Features dauern einfach so lange

Was ist, wenn einige Features einfach objektiv länger dauern als der Release-Zyklus?

Versuchen Sie zunächst, das Feature kleiner zu machen. Man kann z.B. einzelne User Stories erst ein Release später machen. Oder Teile der Geschäftslogik, wie etwa Rabattberechnung, in eine Engine auslagern. Im ersten Release wird dann der Rabatt nur für die einfachen Fälle berechnet, aber das Drumherum (Anzeige des Rabatts, Besteuerung) kann schon fertig sein. Die komplizierteren Rabattberechnungen kommen ein Release später.

Wenn das Feature dann immer noch zu groß ist, helfen Feature Switches. Das heißt, man macht ein ganzes Feature per Konfiguration an- und abschaltbar. Auch ein unfertiges Feature kann dann ausgeliefert werden, es ist nur abgeschaltet. Für Tests, und um Feedback einzusammeln, kann man das Feature für einzelne User oder auch zeitweise aktivieren. Je kürzer Ihre Release-Zyklen werden, desto wichtiger ist es, solche Abschaltmöglichkeiten zu haben.

Verringern Sie die Ende-zu-Ende Zeit für die Entwicklung des Features. Es ist eher unwahrscheinlich, dass der Entwickler derzeit 40 Stunden die Woche an diesem Feature arbeitet. Versuchen Sie, die Unterbrechungen zu minimieren, es sollte also keine weiteren Aufgaben neben dem großen Feature geben. Wartezeiten, z.B. auf Feedback aus der Fachabteilung, oder Testergebnisse, sollten für solche langlaufenden Features offensiv verringert werden.

Schließlich können Sie die Parallelität der Abarbeitung erhöhen, also mehrere Leute gleichzeitig an demselben Feature arbeiten lassen. Wenn Sie Sorge wegen des Koordinations-Aufwandes haben, können Sie zwei Entwickler per pair-programming arbeiten lassen.

Matthias Berth