Es scheint ein klarer Fall zu sein.
Code Freezes sind ein Relikt vergangener Tage. Ein Überbleibsel aus den Zeiten, in denen rigide Wasserfallmodelle die einzige Option für Produktentwicklung und Releases war. Das gesamte Konzept, eine Produktion zu stoppen und Releases zu verschieben – nur um Bugs und sonstige Funktionsprobleme zu testen – hat keinen Platz mehr im modernen agilen Produktmanagement.
Zumindest scheinen sich viele Gurus der Agilen Methodik darüber einig zu sein.
Aber hält dieses Konzept in der Praxis stand? Wenn man erst einmal an der Oberfläche der meist verbreiteten Argumente gegen Code Freezes im Agilen Produktmanagement kratzt, gehören sie dann immer noch auf das Abstellgleis?
In diesem Beitrag erläutern wir drei wichtige Argumente gegen Code Freezes in einem Agilen Produktmanagement und erklären im Detail, wo diese Argumente nicht zutreffen, damit Sie besser entscheiden können, ob Code Freezes in Ihr Agiles Produktmanagement eingebunden werden sollen oder nicht.
Argument 1: Code Freezes sind irrelevant und unnötig
Dieses Argument ist ziemlich simpel und handfest – aufgrund moderner Agile Methodiken und Tools sind dedizierte QAs und Testzeitfenster nicht mehr notwendig.
Agile Methodiken wie Peer-Code-Reviews, Paarprogrammierung und die konstante Überwachung der Systemgesundheit bieten einen deutlich größeren Einblick in die Applikation oder die Leistung einer Funktion, während sie sich noch in der Entwicklung befinden. Bugs und Probleme sind einfacher und vermutlich noch während der Entwicklung eher zu erkennen und vor bestimmten Tests und QAs zu lösen.
Neue Tools haben auch viele Tests automatisiert und evaluieren permanent den Code, um sicherzustellen, dass er fehlerfrei und jederzeit produktionsfähig ist. Probleme werden in Echtzeit identifiziert und Warnmeldungen werden sofort gesendet, damit die Probleme so schnell wie möglich gelöst werden. Die Anzahl automatisierter Tests ist bereits hoch und wächst weiterhin, während das Volumen manueller, notwendiger Tests drastisch reduziert wird.
Das Ergebnis dieser neuen Agilen Methodiken und Tools liegt klar auf der Hand. Die meisten Core Tests und QAs während eines Code Freeze werden entweder noch während der Entwicklung oder von einer Software durchgeführt. Bei der Agilen Methodik verlassen Software und Funktionen die Entwicklung jetzt mit einem deutlich höheren Maß an Vertrauen als zuvor, wodurch Code Freezes zunehmend schwerer zu rechtfertigen sind.
Argument 2: Code Freezes brechen ein agiles Code Prinzip
Dieses zweite Argument ist hier etwas höher einzuordnen. Im Grunde genommen wird hier behauptet, dass Code Freezes keinen Platz in der Agilen Methodik haben, weil sie gegen eines der Grundprinzipien dieser Methodik verstoßen — die Verkürzung der Zeit zwischen Entwicklung und Release.
Je präziser das Vorgehen in der Agilen Methodik, desto begrenzter dieses Zeitfenster. Die aktuell präzisesten Ansätze der Agilen Methodik sind Continuous Integration and Continuous Development (CICD), welche die Entwicklung in kleine, inkrementelle Änderungen unterteilen sollen, um Änderungen am Code so schnell wie möglich „freizugeben“. Bei der Anwendung von CICD in ihrer reinsten Form werden die Phasen Entwicklung und Release kaum voneinander getrennt. Sobald die Entwicklung des neuen Codes abgeschlossen ist, wird dieser in die Anwendung integriert.
Sie müssen jedoch auch weiterhin Entwicklung und Release getrennt halten, wenn Sie Code Freezes bereitstellen möchten. Im Grunde genommen erfolgt der Code Freeze genau an dieser Stelle – zwischen diesen beiden Phasen. Statt zu versuchen, das Zeitfenster zwischen Entwicklung und Release zu reduzieren oder zu beseitigen, wie es die Agile Methodik größtenteils verlangt, werden Sie von den Code Freezes gezwungen, dieses Fenster so zu formalisieren, dass die Zeitpläne für die Entwicklung und Release „drum herum“ erstellt werden müssen.
Wenn sich Code Freezes nicht mit den Grundprinzipien der agilen Methodik vereinbaren lassen, kann man nur schwer dafür plädieren, sich methodisch weiter an sie zu halten.
Argument 3: Code Freezes führen zu langsameren Releases minderer Qualität
Dieses letzte Argument ist wichtig und sollte unter verschiedenen Blickwinkeln betrachtet werden.
Als Erstes wird behauptet, dass Ihre Roadmap durch Code Freezes komplizierter wird. Code Freezes sorgen für zusätzliche bewegliche Komponenten und erhöhen naturgemäß potenzielle Störungen und die Eventualität, auf Zeitrahmen zu verzichten. Auch wenn alles reibungslos verläuft, ist der mit Code Freezes verbundene Aufwand zeitintensiv und unvorhersehbar (da Sie nicht wissen, welche Bugs Sie finden und wie lange es dauert, diese zu beheben). Wenn Sie Code Freezes Ihrer Roadmap hinzufügen, verlaufen Entwicklung und Release-Zyklen langsamer.
Dann wird gesagt, dass Code Freezes die Produktivität des Entwicklerteams reduzieren. Während Agile Methodiken im Allgemeinen und CICD im Besonderen Ihre Entwickler permanent in einer ungebrochenen Produktionskette „auf Trab halten“, zwingen Code Freezes Ihre Entwickler hingegen dazu, die Arbeit in bereits festgelegten Abständen abzubrechen. Dadurch unterbrechen Sie ihren Rhythmus und zwingen sie, die Code Freeze-Politik zu umgehen, statt genau den Arbeitsfluss zu suchen und aufrecht zu erhalten, der die größte Produktivität verspricht.
Und zu guter Letzt wird folgendes Argument angeführt: Durch die Erstellung eigener Zeitfenster, in denen Sie die fachlichen Anforderungen nicht mehr erhalten, werden die Funktionen und Funktionalitäten Ihrer Releases auf all das begrenzt, was vor dem Freeze abgeschlossen werden kann, mit der Folge, dass Software und Applikationen qualitativ minderwertiger und nicht mehr so umfangreich sind.
Sich für Code Freezes einsetzen: ein verlorener Kampf?
An dieser Stelle sieht es für jeden düster aus, der Code Freezes immer noch in die Agile Methodik integrieren möchte. Gegner dieser Praxis halten einige besonders überzeugende Argumente entgegen und vertreten allgemein die Meinung, dass Code Freezes seit der Entwicklung der modernen agilen Methodik:
- veraltet und irrelevant sind
- falsch auf die modernen Entwicklungspraktiken ausgerichtet werden
- eine Barriere für schnelle, qualitativ erstklassige Releases darstellen
Diese Argumente überzeugen und beinhalten eine Reihe exakter Informationen, sind aber nicht unerschütterlich. Und jedes weist fundamentale Mängel auf, die es zu diskutieren gilt, bevor das Kapitel über Code Freezes als nützliche Komponente des agilen Produktmanagements geschlossen wird.
Das Problem mit Argument 1: Automatisierte Tests sind nicht umfangreich
Automatisiertes QA und Entwicklungspraktiken nach der agilen Methode haben die Qualität des Quellcodes während seiner Produktion verbessert. Das ist Tatsache. Aber nur weil ein Teil des Codes einen Unit-Test durchlaufen hat, ist er noch lange nicht für die Produktion bereit. Selbst die präzisesten CICD-Ansätze enthalten nicht immer entscheidende Schritte – wie Regressionstests – die sicherstellen, dass ein Code-Teil fehlerfrei ist. Letzten Endes gibt es einfach einige Dinge, die Sie nicht testen und lösen können, während ein Code-Teil produziert wird.
Wenn Sie sich für Code Freezes entscheiden, geben Sie nicht die Vorteile eines automatisierten QAs und Best Practices der agilen Methodik auf. Sie und Ihr Team werden während der Produktion einfach die kleineren, trivialeren Probleme Ihres Codes erkennen, um die Lage zu sondieren und sich auf größere Probleme mit größeren Auswirkungen während des Freeze zu konzentrieren wie zum Beispiel die Gesamtstabilität und -zuverlässigkeit Ihrer neuen Software oder Funktion.
Das Problem mit Argument 2: “reduzieren”, nicht “beseitigen”
Bei der agilen Methode soll die Zeit zwischen Entwicklung und Release verkürzt werden. Auch das ist ein Fakt. Es gibt jedoch einen großen Unterschied zwischen dem Versuch, dieses Zeitfenster zu straffen oder es vollständig abzuschaffen. Letzteres ist nahezu unmöglich, vor allem bei größeren Projekten.
Der Code Freeze kann im Rahmen von CICD sehr kurz sein – oder nur für eine bestimmte Branche gelten, während in anderen Branchen die Entwicklung fortgeführt wird – existiert aber weiter. Egal wie präzise die agile Vorgehensweise auch ist, es wird in allen Roadmaps für Entwicklung und Releases fast immer einen Punkt geben, an dem ein neues Softwareteil oder ein neues Feature in einem korrigierten Zustand evaluiert wird, bevor es Usern in der realen Welt bereitgestellt wird.
Das Problem mit Argument 3: Geschwindigkeit und Qualität überdenken
Wenn Sie Code Freezes verwenden, wird die Entwicklung und Ihr Release-Zyklus um einen neuen Schritt erweitert. Daran besteht kein Zweifel. Und jedes Mal, wenn Sie einen neuen Schritt in einen Prozess einbinden, drosseln Sie diesen Prozess und verursachen eine neue potenzielle Schwachstelle. Code Freezes sind keine Ausnahme.
Es ist aber wichtig, einen Schritt zurückzugehen und das Thema „Entschleunigung“ und Verlust der Produktivität in einem breiteren Kontext zu betrachten.
Wenn Ihr Feature einen Fehler aufweist, müssen Sie ihn berichtigen, unabhängig davon, ob Sie diese Fehler während eines Code Freeze entdeckt haben oder ob sie erst nach der Release bekannt werden. Vom Standpunkt der reinen Entwicklung aus gesehen, ist für die Behebung der Fehler in beiden Szenarios dieselbe Zeit notwendig.
Wenn Sie sich aber mit Programmfehlern in einer Live-Umgebung befassen müssen, haben Sie eine Reihe anderer Probleme, für die Sie sich Zeit nehmen müssen. Zum Beispiel müssen Sie:
- entscheiden, ob Sie das defekte Feature zurückziehen oder aber lassen.
- Ihre Entwickler aus ihren neuen Projekten zurückholen, nachdem sie mit der Arbeit begonnen haben.
- diese Mängel bei den betroffenen Usern in der realen Welt, wiedergutmachen.
- sich gegenüber Ihren internen unzufriedenen Interessengruppen äußern und diese bedienen.
Die Liste ließe sich weiter fortsetzen. Nichts ist komplizierter, zeitraubender und destruktiver für die Produktivität – für Sie und für Ihr Team – als eine mangelhafte Funktion oder ein defektes Produkt zu veröffentlichen. Code Freezes minimieren die Wahrscheinlichkeit, dass dies passiert.
Und bezüglich des Arguments, dass die Qualität der Features und Produkte durch Code Freezes beeinträchtigt wird, weil sie den Umfang der fachlichen Ansprüche reduzieren, die Sie zusammentragen können? Ihre fachlichen Ansprüche werden immer etwas höher als die „besten Spekulationen“ sein, wie Ihr Produkt oder Ihr Feature funktionieren soll. Die nützlichsten Ansprüche werden von den Usern in der realen Welt gestellt, die Ihr Produkt oder Feature im konkreten Kontext verwenden. Und Sie können diese Ansprüche nur sammeln, wenn Sie Ihren Usern funktionsfähige Releases anbieten, die soweit wie möglich reibungslos implementiert werden können und fehlerfrei sind.
Sollten Sie Code Freezes in Ihr agiles Produktmanagement einbinden?
Im Endeffekt spielen Code Freezes für viele agile Produktmanager eine wichtige Rolle.
Nun gibt es aber auch Fälle, in denen sie eine weniger bedeutende Rolle spielen. Besonders kleine Projekte brauchen keinen eigens bestimmten Zeitraum für Code Freezes. Bei neuen Features mit relativ geringen Konsequenzen, falls sie nicht perfekt bereitgestellt werden, lohnt sich vermutlich kein Freeze. Dasselbe gilt für Release-Pläne, die in Phasen unterteilt werden – wie Canary Releases – wenn Sie neue Features nur bei einer warmen Zielgruppe testen möchten, die Sie auf ein verbuggtes, nicht perfektes Szenario vorbereitet haben.
Aber in den meisten Fällen lohnt sich der Zeitaufwand – auch wenn er noch so klein ist – um sicherzustellen, dass Ihre neuen Features so perfekt sind wie Sie erwarten, bevor Sie sie den Menschen in die Hand geben, die am wichtigsten sind: Ihre User in der realen Welt.
