5 Wege, Entwicklungszyklen zu verkürzen

Um es gleich vorweg zu nehmen: Den Wasserfall gibt es längst nicht mehr. Die Entwicklung findet heute iterativ, in Zyklen statt. Bei der Länge der Entwicklungszyklen gibt es gravierende Unterschiede: Ein Zyklus kann viele Monate lang sein, oder eine Woche und weniger.

Auch der Scope des Zyklus kann sich erheblich unterscheiden: Bei manchen Entwicklungen schließen nur wenige Zyklen am Ende ein funktionierendes Produkt ein, bei anderen gibt es schon am Ende der ersten Iteration ein minimales, funktionierendes Product (MVP, Minimal Viable Product).

In diesem Artikel wird analysiert, warum kurze Entwicklungszeiten wünschenswert sind, und wie wir diese verkürzen können.

Warum kurze Entwicklungszyklen wünschenswert sind

Lange Entwicklungszyklen haben eine Reihe von Nachteilen:

• Die Systementwicklung als Ganzes dauert länger
• Lange Reaktionszeiten bei Änderungen
• In der Entwicklung gefundene Probleme verzögern die Entwicklung
• Während der Entwicklung entdeckte Verbesserungen und Anforderungen werden aus Zeitgründen spät oder gar nicht umgesetzt

Diese Nachteile können zur Folge haben, dass ein Mitbewerber einen mal eben überholt, und können dementsprechend existenzgefährdend sein.

Entwicklungszyklen verkürzen

Leider lassen sich oft Entwicklungszyklen nicht einfach „mal eben“ verkürzen. Neben kulturellen Problemen (auf die ich gleich noch zu sprechen komme), gibt es die folgenden zwei Probleme:

• Umgang mit Änderungen: Auch bei einfachen Produkten gibt es in der Entwicklung viele Abhängigkeiten, die sauber verwaltet werden müssen: Die Implementierung hängt von den Systemanforderungen ab, diese wiederum von den Nutzeranforderungen. Weiterhin bestehen Abhängigkeiten zu Tests, und Testergebnisse können veraltet sein. Beim Wasserfall vermeidet man diese Problematik vermeintlich, indem jede Stufe nur einmal durchlaufen wird. Ohne ein vernünftiges Anforderungsmanagement wird das Team versuchen, so wenige Iterationen wie möglich zu durchleben.
• Compliance: In Entwicklungen mit funktionalen Sicherheit müssen zur Compliance Nachweise bezüglich Risiken und Sicherheit erstellt werden. Das kann nicht erst zum Schluss gemacht werden, denn die Risiken müssen ja schließlich von Anfang an berücksichtigt werden. Da der Aufwand für einen Nachweis in der Regel groß ist, wird versucht, diesen durch lange Zyklen so selten wie möglich durchzuführen.

Kulturelle und Menschliche Aspekte

Aus dem eben gesagten können wir schon ahnen, was eines der großen Probleme für die Menschen ist: Menschen wollen produktive Arbeit machen – oder besser gesagt: Sie möchten Produkte entwickeln, und nicht Änderungen Pflegen oder wiederholt Analysen durchführen. Es wird zwar erkannt, dass diese Arbeiten wichtig sind; Spaß machen sie aber trotzdem nicht.

Menschen wollen produktive Arbeit machen! Twittern

Und damit kommen wir schon zu einer Antwort der Frage: Um die Zyklen zu kürzen, muss der Aufwand für die „langweilige“ Arbeit minimiert werden (es wäre nicht fair, diese Arbeit als „nicht-produktiv“ zu bezeichnen). Das ist ein guter Kompass – hier nun die konkreten Ansätze, wie dies realisiert werden kann:

Um kompetent auf Änderungen reagieren zu können, muss feingranular gearbeitet werden. Das bedeutet, dass jedes Element (Anforderung, Designelement, Test, etc.) eigenständig sein muss. Dann können diese Elemente sinnvoll miteinander verknüpft werden, wie oben beschrieben. Diese Strukturen ermöglichen es erst, auf Änderungen von einzelnen Elementen überhaupt reagieren zu können. Dazu wird ein professionelles Werkzeug verwendet. So ein Werkzeug muss die Möglichkeit haben, Baselines zu ziehen und zu vergleichen, die Auswirkungen von Änderungen zu analysieren (Impact Analysis) und vieles mehr.

Wichtig ist, ein Werkzeug nicht überzubewerten, es muss entsprechende Methoden und Prozesse geben. Jedoch können ohne entsprechende Werkzeugunterstützung diese kaum effizient gelebt werden.

Ein Problem bei iterativem Arbeiten ist es, wenn für jede Iteration kopien angelegt werden: Es muss immer klar sein, was „die Wahrheit“ ist. Wichtig: Wahrheit bedeutet nicht unbedingt „aktueller Stand“. Das ist ja genau das Problem mit dem Wasserfall: Dieser wird oft nur deshalb praktiziert, da dieser erlaubt, dass aktueller Stand und Wahrheit das Selbe sind. Nur wenn wir erlauben, auch mit potentiell veralteten Daten zu arbeiten, können wir ohne zu warten weiterarbeiten. Dank einem feingranularen Datenmodell müssen dann möglicherweise nur einzelne Elemente nachgebessert werden. Gefährlich wird es jedoch, wenn auf veralteten Daten gearbeitet wird, ohne sich dessen bewusst zu sein.

Um in kurzen Iterationen arbeiten zu können ist es wichtig, die Entwicklung zu verstehen. Dazu müssen wir kommunizieren. Für Änderungen gibt es einen Grund, und nichts ist frustrierender, als diesen Grund nicht zu verstehen. Wenn also bspw. entschieden wird, die Kapazität der Batterie, dann muss nachvollziehbar sein, warum das so ist: War die Laufzeit zu kurz, oder ist ein großer Verbraucher dazugekommen? Die Antwort auf diese Frage sollte nicht in irgendeiner E-Mail vergraben sein. Das wäre übrigens auch für Compliance ein Problem, da die Dokumentation von Entscheidungen oft gefordert wird. Statt dessen sollte die Entscheidung Teil der Datenhaltung sein („Single Source of Truth“).

Das Datenmodell muss so einfach wie möglich sein und nur so kompliziert wie nötig. Als Berater im Anforderungsmanagement habe ich Systeme gesehen, bei denen Anforderungen duzende von Attributen hatten. Das ist ein echtes Problem, wenn diese nicht gepflegt werden. Denn veraltete (falsche) Informationen können gefährlicher sein als nicht vorhandene. Das betrifft übrigens nicht nur Attribute, sondern auch die Anzahl von Elementtypen und die Beziehungen zwischen diesen.

Eine nicht gepflegte Information ist schlimmer als eine fehlende Information Twittern

Wenn das Datenmodell zu kompliziert ist, kommt schnell die Angst auf (zu Recht!), die Auswirkungen von Änderungen nicht zu verstehen. Und dann schrecken wir vor kurzen Entwicklungszyklen zurück.

Wie bereits gesagt, machen wir ungern Tätigkeiten, die mit unserer „eigentlichen“ Arbeit nichts zu tun haben. Eben wurden bereits Ansätze beschrieben, diese so schmerzlos wie möglich zu machen. Aber noch besser ist es, diese vollständig zu vermeiden.

Vorreiter bei der Automatisierung ist die Softwareentwicklung, die schon seit vielen Jahren mit „Build-Automatisierung“ arbeitet. Doch auch in der Systementwicklung lässt sich viel automatisieren, und das wiederum verkürzt die Dauer von Entwicklungszyklen und erhöht die Akzeptanz, diese zu verkürzen.

Wie dies in der Praxis aussieht hängt vom konkreten Projekt (und Industrie) ab. Wichtig ist auch, nicht über Bord zu gehen: Der Nutzen der Automatisierung muss klar erkennbar sein. Die Transparenz in der Entwicklung darf dadurch nicht verloren gehen.

Fazit

Die fünf hier beschriebenen Taktiken lassen sich in vielen Situationen einsetzen. Und was fast wichtiger ist: Wenn bereits ein vernünftiges Werkzeug eingesetzt wird, lassen sie sich in kleinen Schritten anwenden, um Stück für Stück die Systementwicklung zu beschleunigen.

Bildquelle: Michael Jastram