Warteschlange

Schneller Software entwickeln – nur wie? Teil 1: Über Warteschlangen

Die meisten Organisationen stecken heute in irgendeiner Form von Transformation, hin zu schnellerer (Software-)Produktentwicklung und kürzerer Time-to-Market. Damit verbunden ist stets auch der unausgesprochene Wunsch, doch irgendwie auch mehr zu schaffen. Heißt es nicht in einem populären Buch über ein noch populäreres Framework „die doppelte Arbeit in der halben Zeit”? Ein verführerischer Gedanke, nicht wahr? Dennoch müssen wir festhalten, dass die meisten dieser Initiativen keines der expliziten Ziele erreichen, geschweige denn uns dem impliziten Ziel „mehr Business Agility” näherbringen (wie mein Freund und Kollege Pascal in seinem Artikel aufzeigt). 

Aber woran liegt das? Warum können Frameworks ihre vollmundigen Versprechen in den meisten Organisationen nicht einlösen? In dieser Artikelserie möchte ich den Blick auf Dinge lenken, die normalerweise bei der Einführung eines Frameworks nicht im Fokus sind – die aber entscheidend sind für die in sie gesetzten Erwartungen. Zuguterletzt werde ich verschiedene Ansätze und Praktiken aufzeigen, deren konsequente Anwendung die Entwicklung tatsächlich beschleunigen können.

Also, fangen wir an: Jeder möchte gerne, dass seine Software-Entwicklungs-Organisation a) schneller und b) vorhersehbarer wird. Ich glaube auch, für die meisten Organisation ist dies grundsätzlich möglich. Jedoch müssen wir unsere Denkweise in einigen entscheidenden Dingen verändern, um dies zu ermöglichen. 

Zuerst müssen wir den Blick weg von den am Prozess beteiligten Menschen abwenden und ihn stattdessen auf die am Prozess beteiligte Arbeit richten. Wenn wir das tun, werden zwei wichtige Systembedingungen sichtbar: Warteschlangen und Schleifen

Diese sind die wesentlichen Parameter, die entscheidend für die Geschwindigkeit (und damit Time-to-Market) Ihrer Organisation sind. Warum ist das so? Schauen wir uns einen typischen Software-Entwicklungsprozess an, wie er meistens gepflegt wird. 

In Details unterscheiden sich die Prozessschritte je Organisation, die Basis-Aktivitäten sind jedoch annähernd identisch. Zuerst wird man sich klar darüber, was man erreichen möchte und dokumentiert diesen Wunsch (je nach Organisation in Prosa oder in einer it-näheren Syntax). Danach transformieren Entwickler:innen diese Gedanken und Wünsche in ein nutzbares Produkt, in dem sie Code generieren. Der eingegebene Code wird dann in verschiedenen Stufen auf Richtigkeit, Vollständigkeit und Nähe zum Kundenwunsch überprüft, bevor er seinen Eingang in das Produktivsystem findet.

Zumeist sind unterschiedliche Menschen in verschiedenen Rollen an diesem Prozess beteiligt, z.B. Business Analysten, Softwarearchitekten, Entwickler:innen, Tester:innen oder Verantwortliche fürs Deployment.

Kann Arbeit reibungslos durch dieses kreierte System fließen, dann könnten es 2-3 Tage Entwicklung sein, gefolgt von wenigen Minuten automatisierter Tests, einem zügigen Merge des Entwicklungs-Branch in die Hauptlinie, gefolgt von ein oder zwei Tagen Integrations-oder E2E-Tests, dazu ein wenig Sicherheits- und Lasttests und einem Deployment!

Diesem Plan zu folgen scheint ziemlich einfach, und vor allem: er ist vorhersehbar: unser neues Feature sollte in weniger als einer Woche am anderen Ende des Prozesses erscheinen.

Dem ist oft nicht so.

Konzentrieren wir uns auf den ersten Punkt, noch unsichtbar im schön linearen Prozess von oben: Die Warteschlange.

Jedes Mal, wenn Sie einen Auftrag an eine Person geben ist dies eine Übergabe – und, weil alle im System beteiligten Menschen viel zu tun haben, ist das unmittelbar verbunden mit einer unvermeidlichen Warteschlange. Das bedeutet, die Arbeit muss warten, bis die betreffenden Personen verfügbar werden.

Wir halten fest: Wo immer es eine Übergabe gibt, gibt es auch eine Warteschlange. 

Die bekannteste Form der Warteschlange ist die

  • Eingangs-Warteschlange: Um Arbeit an eine beschäftigte Person zu übergeben, müssen Sie die Arbeit in ihre Eingangs-Warteschlange stellen. In physischen Büros geschah dies früher mit einem „Posteingangskörbchen”, in der Neuzeit geschieht dies normalerweise über ein elektronisches System (das kann ein Ticketing-Tool wie Jira sein, aber auch E-Mail oder Anrufe sind zur Übergabe von Arbeitsaufträgen nach wie vor verbreitet).

In den meisten Organisationen wird Entwickler:innen als Gruppe Arbeit zugewiesen. Normalerweise übergibt z.B. ein Product Owner die Arbeit in einem Planning formal an eine Entwickler:in. 

Wir erinnern uns: Wo immer es eine Übergabe gibt, gibt es eine Warteschlange. Dieses Mal die

  • Entwicklungs-Warteschlange: Entwickler:innen sind normalerweise beschäftigt, so dass die zu erledigende Arbeit warten muss, bis Entwickler:innen verfügbar sind.

Wie groß ist nun diese Warteschlange und wie lange warten Aufträge im Durchschnitt? Oft werden 2 Wochen Arbeit zugewiesen. Einige Arbeiten können in diesem Setup sofort begonnen werden, andere jedoch möglicherweise erst am letzten Tag. Die durchschnittliche Zeit, die ein Auftrag in der Warteschlange steht, ist etwa 5 Werktage.

(Übrigens: Wir Menschen sind nicht multitasking-fähig. Jedes Mal, wenn Sie laufende Arbeit unterbrechen (egal für wie lange) stellen Sie sie, bildlich gesprochen, zurück in die Warteschlange.) 

Erst wenn wir die Arbeit an einem Auftrag konkret beginnen, startet die Netto-Arbeitszeit: und wir stellen fest, sie ist hoch-variabel: Einige der Arbeiten können Minuten oder Stunden dauern, andere einen Tag oder eine Woche.

Der Grund für die Variabilität liegt in verschiedenen Aspekten, einschließlich der spezifischen Schwierigkeit jeder Aufgabe, Unsicherheiten in Bezug auf Plattform und Sprache, das Risiko, vorhandene Softwarefunktionen zu beschädigen, wie leicht oder schwer der Code zu ändern ist, die Gewohnheiten und Fähigkeiten des Entwickelnden, u.v.m. 

Für unsere Zwecke nehmen wir an, dass der Aufwand für unsere Änderung durchschnittlich 2 Tage beträgt. 

In unserem Beispiel haben wir also 5 Tage Wartezeit bei 2 Tagen Netto-Entwicklung:

Der entwickelte Code muss nun wie oben beschrieben zur Überprüfung auf Vollständigkeit, Richtigkeit (und auch, wie sehr er dem Kundenwunsch tatsächlich entspricht) übergeben werden. Wir erinnern uns, wo immer es eine Übergabe gibt, gibt es eine Warteschlange, diesmal die 

  • Inspektionswarteschlange: Es wird davon ausgegangen, dass einige Änderungen schlechte Änderungen sind, daher erscheint es ratsam, jede Änderung am System von anderen überprüfen zu lassen.

Bei einem Team wurde z.B. entschieden, am Ende des Sprints mehrere Tage für manuelle Tests zu reservieren – im Sinne der Effizienz. In diesen Tagen wurden viele Überprüfungen gemacht, die Wartezeit betrug etwas weniger als 3 Tage im Durchschnitt. 

Wir haben also eine durchschnittliche Wartezeit von 5 Tagen, um mit der Arbeit zu beginnen, 2 Tage Arbeit, 3 Tage warten auf die Überprüfung und dann (in Summe) 3 Tage Inspektion. Wir können also davon ausgehen, dass ein Auftrag dieser Art etwas mehr als 10 Werktage in Anspruch nehmen wird.

Unsere ursprüngliche Idee, mindestens ein Feature pro Woche zu veröffentlichen, ist schon jetzt sehr unwahrscheinlich geworden. Aber schauen wir uns den Rest des Prozesses an.

  • Merge-Warteschlange: Nachdem der Code der Entwickler fertiggestellt und überprüft war, muss er mit anderen Änderungen zusammengeführt werden, die ebenfalls vorher einzeln überprüft und akzeptiert wurden. Häufig wird überprüfter Code dabei zur Genehmigung durch eine besondere Rolle (z.B. Lead Developer oder Architekt) übergeben. Wo immer es eine Übergabe gibt, gibt es eine Warteschlange.

Das Merging läuft manchmal nicht gut und erfordert menschliches Eingreifen. Glücklicherweise erfolgt die Zusammenführung meistens am selben Tag wie die Überprüfung, also addieren wir nur einen Tag hinzu.

Das Merging hat nun eine einzigartige neue Version des Gesamt-Codes generiert, die noch nie zuvor existiert hat. Die verschiedenen Änderungen, die einzeln getestet wurden, können mit unbeabsichtigten Folgen verbunden sein. Es erscheint sinnvoll, eine besondere Form von Test hinzuzufügen, um subtile Fehler, die durch die Zusammenführung verursacht werden, zu erkennen und zu korrigieren.

Im Regelfall wird dieser Test von anderen Personen erledigt als von denjenigen, die die Änderungen vorgenommen, überprüft, genehmigt und zusammengeführt haben. Wir erhalten die

  • Integrations- oder E2E-Warteschlange: Die Integrationstestumgebung muss vorbereitet werden und wird oft auch von anderen Testern verwendet. Die Arbeit muss warten, bis die Umgebung mit Testdaten und der aktuellsten Codeversion versehen wurde – und dann, bis wir auf die Umgebung zugreifen dürfen. Wo immer es eine Übergabe gibt, gibt es eine Warteschlange.

Nehmen wir dafür 3 Tage. Danach dauert es noch 2 Tage bis wir genügend Sicherheit haben, dass die Gesamthaftigkeit aller neuen Änderungen keine Probleme verursachen werden.

Mit dieser Ergänzung klingen 19 Werktage für unser Feature ziemlich vernünftig. (Ich vermute, viele Leser:innen, die in Scrum-Umgebungen arbeiten, rutschen nun unruhig auf ihren Plätzen hin und her. Ein typischer Sprint beträgt 10 Arbeitstage. Unser Standard-Prozess hat eine finale Lieferung zum Kunden innerhalb eines Sprints unmöglich gemacht.)

Aber gehen wir weiter.

Möglicherweise gibt es noch Sicherheits-, Last- oder Performancetests durchzuführen, vielleicht auch finale User Acceptance Tests des Gesamtsystems vor einem Deployment. Auch hier wird die Arbeit wieder für einige Tage warten müssen, auch wenn die aktive Zeit nur einen Tag benötigt. Fügen wir für beide Test-Schritte noch einmal je 2 Tage Warten und 1 Tag aktive Arbeit hinzu (das Deployment können wir vernachlässigen).

Wir erhalten einen Gesamt-Prozess von 25 Werktagen.

Natürlich, die Anzahl der Schritte im Prozess variiert je Unternehmen – eines ist fast allen gemein: wir sehen n Warteschlangen.

Diese Gesamt-Durchlaufzeit verursacht ein gerüttelt Maß Unbehagen in Unternehmen – und mit viel Verve generiert man in der Folge Ideen, wie man Entwickler:innen dabei helfen kann, schneller zu werden. Schließlich will jeder seine Änderungen früher erhalten.

Nur: Wenn das netto 2-tägige Development in Summe brutto 25 Tage benötigt, um das ganze System zu durchlaufen, wie viel schneller wäre es dann abgeschlossen, wenn die Entwickler:in zu Beginn doppelt so schnell wäre? Richtig. Es wären 24 statt 25 Tage. Niemand würde den Unterschied bemerken. Wäre sie umgekehrt doppelt so langsam, wären es 27 Tage, was ebenfalls kaum ins Gewicht fällt.

Das Problem liegt nicht in der Geschwindigkeit der Entwickler:innen, sondern im Arbeitsfluss durch das System als Ganzes. Don Reinertsen verwendet dazu die Metapher „auf den Staffelstab achten, nicht auf die Läufer“. 

Auch nicht übersehen werden sollte die Organisationskultur, denn eine Ausrichtung auf „Stop starting, start finishing“ (siehe den Artikel von Fabian Biebl) kann sich auch darauf auswirken und damit Konflikte verursachen.

Wenn Sie ähnliche Muster in Ihrer Organisation erkennen, was sollten Sie jetzt tun: ermitteln Sie in Ihrer Organisation den Anteil der Wartezeit an der Durchlaufzeit und setzen Sie beide Werte ins Verhältnis. Oder nehmen Sie Kontakt zu uns auf.

Ausblick: Von Schleifen und der Möglichkeit zur Reduktion

In Teil 2 der Reihe „Schneller Software entwickeln“ werfen wir gemeinsam einen Blick auf den nächsten systemischen Kern-Parameter: Schleifen.

In Teil 3 zeige ich, an welchen Stellen weniger mehr ist und mit welchen Praktiken und Verfahrensweisen Reduktion gelingt.

(Hinweis: Die Artikelserie borgt Gedanken von Tim Ottinger von Industrial Logic, Verwendung mit Genehmigung.)

Ähnliche Beiträge

Ein Kommentar

  1. Ich hab’s gegoogelt: für „systemischer Kern-Parameter“ kannst du ein Copyright anmelden. Cool!

    Etwas deprimierend wenn man Worktime und Waittime im Valuestream in Beziehung setzt.

    Spannende Frage: bleibt das selbst so wenn man die Batchsize runterfährt? Nur wenn man eine Valuestreamvariante mit reduzierter Waittime nutzt, oder?

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert