Code Freezes: Sind sie für agile Produktmanager noch relevant?

Es scheint ein Auf- und Zu-Fall zu sein.

Code Freezes sind ein Relikt. Ein Überbleibsel aus der Zeit, als starre Wasserfallmethoden die einzige Option für die Produktentwicklung und -veröffentlichung darstellten. Das ganze Konzept, die Produktion zu stoppen und die Veröffentlichung zu verzögern — nur um auf Fehler und andere funktionale Probleme zu testen — hat im modernen, agilen Produktmanagement keinen Platz.

Zumindest scheint das der Konsens vieler Agile Gurus zu sein.

Aber hält es? Wenn Sie einmal an der Oberfläche der häufigsten Argumente gegen die Einbeziehung von Code Freezes in das agile Produktmanagement kratzen, werden sie dann noch archaisch erscheinen?

In diesem Artikel werden wir die drei Hauptargumente gegen die Einbeziehung von Code Freezes in Ihr agiles Produktmanagement untersuchen und aufschlüsseln, wo diese Argumente auseinanderfallen, um Ihnen zu helfen, eine bessere Entscheidung darüber zu treffen, ob Sie Code Freezes in Ihr Agiles Produktmanagement integrieren sollten oder nicht.

Argument 1: Code Freezes sind irrelevant und unnötig

Dieses Argument ist ziemlich einfach und konkret – moderne Agile Methoden und Tools haben die Notwendigkeit eines dedizierten QS- und Testfensters beseitigt.

Agile Methoden wie Peer-Code-Reviews, Pair-Programming und die ständige Überwachung des Systemzustands geben Ihnen einen viel besseren Einblick in die Leistung einer Anwendung oder eines Features während der Entwicklung. Fehler und Probleme werden leichter und wahrscheinlicher während der Entwicklung selbst erkannt und vor speziellen Test- und QS-Aktivitäten behoben.

Neue Tools haben auch viele Tests automatisiert. Sie bewerten den Code ständig, um sicherzustellen, dass er jederzeit sauber und produktionsbereit ist. Probleme werden in Echtzeit identifiziert, und Warnungen werden sofort gesendet, um sie so schnell wie möglich zu beheben. Die Anzahl der Tests, die automatisiert wurden, ist bereits weitreichend und wächst weiter, wodurch das Volumen der manuellen Tests, die durchgeführt werden müssen, drastisch reduziert wird.

Das Ergebnis dieser neuen agilen Methoden und Tools ist leicht zu erkennen. Die meisten Kerntests und QA-Aktivitäten, die während eines Code-Freezes durchgeführt werden, werden entweder während der Entwicklung oder von Software durchgeführt. In Agile verlassen Software und Features die Entwicklung jetzt mit einem viel höheren Vertrauensniveau als früher, was es immer schwieriger macht, einen dedizierten Code-Freeze zu rechtfertigen.

Argument 2: Code friert ein, um ein agiles Kernprinzip zu brechen

Dieses zweite Argument ist etwas höher. Grundsätzlich wird argumentiert, dass Code-Freezes in der agilen Methodik kein Zuhause haben, da sie gegen eines der Kernprinzipien der agilen Methodik verstoßen — die Verkürzung der Zeit zwischen Entwicklung und Veröffentlichung.

Je verfeinerter Ihr Ansatz für Agile ist, desto mehr werden Sie versuchen, dieses Zeitfenster zu verkleinern. Die raffiniertesten aktuellen Ansätze für Agile sind Continuous Integration und Continuous Development (CICD), und sie zielen darauf ab, die Entwicklung in kleine, inkrementelle Änderungen aufzuteilen, um Änderungen am Code so schnell wie möglich zu „veröffentlichen“. In der reinsten Anwendung von CICD existieren Entwicklung und Release kaum als getrennte Phasen — neuer Code wird fast sofort nach Fertigstellung in die Anwendung integriert.

Im Gegensatz dazu müssen Sie unterschiedliche Entwicklungs- und Release-Phasen beibehalten, wenn Sie Code-Freezes bereitstellen möchten. Schließlich lebt dort der Code Freeze – zwischen diesen beiden verschiedenen Phasen. Anstatt zu versuchen, dieses Zeitfenster zwischen Entwicklung und Release zu minimieren oder zu eliminieren, wie es bei den meisten agilen Methoden der Fall ist, zwingt Sie das Einfrieren von Code, dieses Fenster so weit zu formalisieren, dass Sie Ihre Entwicklungs- und Release-Zeitpläne darauf aufbauen müssen.

Wenn das Einfrieren von Code nicht mit den agilen Kernprinzipien übereinstimmt, ist es schwierig, den Fall zu vertreten, dass sie immer noch in die Methodik gehören.

Argument 3: Code-Einfrierungen führen zu langsameren Releases von geringerer Qualität

Dieses letzte Argument ist groß und enthält einige verschiedene Blickwinkel.

Zunächst wird argumentiert, dass das Einfrieren von Code Ihrer Roadmap viel Komplexität und zusätzliche bewegliche Teile hinzufügt und natürlich die Wahrscheinlichkeit erhöht, dass etwas schief geht und Ihre Zeitleiste abwirft. Selbst wenn nichts schief geht, ist die Arbeit, die mit dem Einfrieren von Code verbunden ist, zeitaufwändig und unvorhersehbar (da Sie nicht wissen, welche Fehler Sie finden oder wie lange es dauern wird, sie zu beheben).

Als nächstes wird argumentiert, dass das Einfrieren von Code die Produktivität Ihres Entwicklungsteams verringert. Während Agile im Allgemeinen und CICD im Besonderen Ihre Entwickler ständig in einer ununterbrochenen Produktivitätskette arbeiten lassen, zwingen Code-Einfrierungen Ihre Entwickler, die Arbeit in vordefinierten Intervallen einzustellen. Auf diese Weise brechen Sie ihren Rhythmus und zwingen sie, Ihre Code-Freeze-Richtlinien zu umgehen, anstatt den Fluss zu finden und aufrechtzuerhalten, der sie am produktivsten macht.

Schließlich wird argumentiert, dass das Erstellen dedizierter Fenster, in denen Sie keine Geschäftsanforderungen mehr erhalten, die Features und Funktionen Ihrer Releases auf das beschränkt, was vor dem Einfrieren abgeschlossen werden kann, was zu minderwertiger, weniger umfassender Software und Anwendungen führt.

Der Fall für Code friert ein: Ein verlorener Kampf?

An diesem Punkt sieht es ziemlich düster aus für alle, die immer noch Code-Freezes in die Agile Methodik einbeziehen möchten. Kritiker dieser Praxis machen einige sehr überzeugende Argumente und einen insgesamt soliden Fall dafür, dass Code seit der Entwicklung der modernen agilen Methodik eingefroren wurde:

1. Veraltet und irrelevant
2. Falsch ausgerichtet an modernen Entwicklungspraktiken
3. Ein Hindernis für schnelle, qualitativ hochwertige Veröffentlichungen

Aber während diese Argumente überzeugend sind und viele genaue Informationen enthalten, sind sie nicht kugelsicher. Und es gibt grundlegende Mängel in jedem, die diskutiert werden müssen, bevor das Buch über Code Freezes als nützliches Element des agilen Produktmanagements geschlossen wird.

Das Problem mit Argument 1: Automatisiertes Testen ist nicht umfassend

Automatisierte QA- und Agile Entwicklungspraktiken haben die Qualität des erzeugten Codes erhöht, das ist eine Tatsache. Aber nur weil ein Stück Code Unit-Tests bestanden hat, bedeutet das nicht, dass es tatsächlich produktionsbereit ist. Selbst die raffiniertesten CICD-Ansätze beinhalten nicht immer kritische Schritte – wie Regressionstests -, die sicherstellen, dass ein Code fehlerfrei ist. Wenn es darauf ankommt, gibt es nur einige Dinge, die Sie nicht testen und lösen können, während sich ein Code in Produktion befindet.

Wenn Sie sich für Code Freezes entscheiden, werden Sie nicht auf die Vorteile von automatisierter Qualitätssicherung und agilen Best Practices verzichten. Sie und Ihr Team fangen einfach die kleineren, trivialeren Probleme Ihres Codes während der Produktion ab und räumen die Decks frei, um sich auf größere, schwerwiegendere Probleme während des Einfrierens zu konzentrieren, z. B. die allgemeine Stabilität und Zuverlässigkeit Ihrer neuen Software oder Funktion.

Das Problem mit Argument 2: „Reduzieren“, nicht „Eliminieren“

Agile soll die Zeit zwischen Entwicklung und Release verkürzen, das ist auch eine Tatsache. Aber es gibt einen großen Unterschied zwischen dem Versuch, dieses Fenster zu reduzieren, und dem Versuch, es vollständig zu beseitigen. Dies wäre vor allem bei größeren Projekten nahezu unmöglich.

Das Einfrieren des Codes kann in CICD sehr kurz sein — oder nur für einen bestimmten Zweig gelten, während die Entwicklung in anderen Zweigen fortgesetzt wird -, aber es existiert immer noch. Egal wie verfeinert Agile wurde, es wird fast immer einen Punkt in allen Entwicklungs- und Release-Roadmaps geben, an dem eine neue Software oder Funktion in einem festen Zustand bewertet wird, bevor sie an reale Benutzer ausgegeben wird.

Das Problem mit Argument 3: Geschwindigkeit und Qualität überdenken

Wenn Sie Code Freezes verwenden, fügen Sie Ihrem Entwicklungs- und Release-Zyklus einen neuen Schritt hinzu. Daran besteht kein Zweifel. Und jedes Mal, wenn Sie einem Prozess einen neuen Schritt hinzufügen, verlangsamen Sie diesen Prozess und erstellen einen neuen potenziellen Fehlerpunkt. Code Freezes sind keine Ausnahme.

Es ist jedoch wichtig, einen Schritt zurückzutreten und die Verlangsamung und den Produktivitätsverlust breiter zu betrachten.

Wenn Ihre Funktion Fehler aufweist, müssen Sie diese beheben, unabhängig davon, ob Sie diese Fehler während eines Code-Einfrierens festgestellt haben oder ob sie sich nach der Veröffentlichung bekannt gemacht haben. Aus reiner Entwicklungsperspektive ist der Zeitaufwand für die Behebung in beiden Szenarien ungefähr gleich.

Wenn Sie jedoch mit Fehlern in einer Live-Umgebung zu tun haben, haben Sie eine Vielzahl anderer Probleme, mit denen Sie sich die Zeit nehmen müssen, darunter:

• Entscheiden Sie, ob Sie die Buggy-Funktion zurücksetzen oder live lassen möchten.
• Nehmen Sie Ihre Entwickler von ihren neuen Projekten ab, nachdem sie mit der Arbeit begonnen haben.
• Es liegt an Ihren realen Benutzern, die von den Fehlern betroffen waren.
• Beantwortung und Verwaltung Ihrer internen Stakeholder, die über Ihre problematische Veröffentlichung nicht allzu glücklich sind.

Die Liste geht weiter. Es gibt nichts Komplizierteres, Zeitaufwändigeres und Zerstörerischeres für die Produktivität – für Sie und Ihr Team — als die Freigabe einer fehlerhaften Funktion oder eines fehlerhaften Produkts. Code-Einfrierungen minimieren die Wahrscheinlichkeit, dass dies geschieht.

Und was das Argument betrifft, dass Code-Einfrierungen zu weniger Qualitätsmerkmalen und Produkten führen, weil sie die Menge an Geschäftsanforderungen reduzieren, die Sie sammeln können? Ihre Geschäftsanforderungen sind immer nur eine „beste Vermutung“, wie Ihr Produkt oder Ihre Funktion funktionieren soll. Die wertvollsten Anforderungen kommen immer von realen Benutzern, die Ihr Produkt oder Ihre Funktion in realen Szenarien bereitstellen. Und Sie können diese Anforderungen nur erfassen, indem Sie Ihren Benutzern funktionale Releases zur Verfügung stellen, die sie so flüssig und fehlerfrei wie möglich bereitstellen können.

Sollten Sie Code Freezes in Ihrem agilen Produktmanagement einsetzen?

Letztendlich spielen Code Freezes für viele Agile Produktmanager immer noch eine wichtige Rolle.

Nun gibt es Fälle, in denen sie eine weniger kritische Rolle spielen. Sehr kleine Projekte benötigen möglicherweise keine speziellen Code-Freeze-Perioden. Neue Funktionen, die relativ geringe Konsequenzen haben, wenn sie unvollständig ausgeliefert werden, sind das Einfrieren möglicherweise nicht wert. Das Gleiche gilt für Phased—Release—Pläne – wie Canary Releases – wenn Sie nur neue Funktionen mit einem warmen Publikum testen möchten, das Sie darauf vorbereitet haben, ein fehlerhaftes, unvollkommenes Erlebnis zu erwarten.

In den meisten Fällen lohnt es sich jedoch, sich die Zeit zu nehmen — auch nur einen sehr kurzen Zeitraum —, um sicherzustellen, dass Ihre neuen Funktionen so perfekt sind, wie Sie denken, bevor Sie sie in die Hände der wichtigsten Personen legen: Ihrer realen Benutzer.

Dieser Artikel wurde ursprünglich veröffentlicht am flagship.io