Letztes Mal haben wir über unregelmäßige Releases gesprochen und warum sie passieren. Lassen Sie uns also ohne Umschweife dort weitermachen, wo wir aufgehört haben.
Sprint-Strategie fortgesetzt
Manchmal ist es verlockend, eine Art Code-Freeze einzuführen, d.h. ein Datum, nach dem kein neuer Code mehr in die Sprint-Version aufgenommen werden darf (nur noch Fehlerbehebungen sind erlaubt). Obwohl diese Idee im Allgemeinen nicht schlecht ist, schränkt die Festlegung eines festen Datums den Handlungsspielraum eines Teams ein und behindert oft die Effektivität. Feste Code-Freezes sind ein wasserfallartiger Versuch, ein Gefühl der Kontrolle zu vermitteln. Natürlich ist dies oft nicht die Idee des Entwicklungsteams selbst, sondern eher ein Prozess des Unternehmens. Das Einfrieren von Code beraubt das Team eines der wichtigsten Werte von Agile - der Anpassungsfähigkeit und der Möglichkeit, kreative Wege zu finden, um effektiver zu werden.
Die Risiken in den Elementen müssen für jeden Sprint Backlog einzeln bewertet werden (je nach Größe, Komplexität, technischem Anspruch usw.). Das Team muss dann den spätesten angemessenen Zeitrahmen für den Beginn der abschließenden Tests festlegen. Das bedeutet zum Beispiel, dass dieser Zeitrahmen für ein großes Element etwa in der Mitte des Sprints liegen könnte, während für eine kleine Änderung ein halber Tag vor Ende des Sprints ausreicht. Nach diesem Zeitpunkt ist es riskant, dieses Element in das Produktinkrement des Sprints aufzunehmen. Auch hier muss das Team individuell bewerten, wie hoch das Risiko zusätzlicher Arbeit ist, nachdem es die Implementierung einer Story abgeschlossen und mit den abschließenden Tests begonnen hat, und dies entsprechend einplanen. Der Versuch, ein einheitliches Datum für das Einfrieren des Codes festzulegen, führt in der Regel dazu, dass das Datum für Elemente von geringer Komplexität zu früh und für komplexere Elemente viel zu spät ist.
Das Schöne an häufigen Releases
Am Ende des Sprints entscheidet der Product Owner, ob er die Version des Sprints tatsächlich veröffentlichen will oder nicht. Es mag aus vielen Gründen nicht notwendig sein, aber er muss immer die Möglichkeit haben, dies zu tun. Im Allgemeinen ist es von Vorteil, so oft wie möglich zu veröffentlichen. Durch die häufige Freigabe kleinerer Stapel von Funktionen ist das Risiko, dass etwas Wichtiges schief geht, viel geringer und ein möglicher Rollback ist nicht so schmerzhaft. Auch für die Planung ist dies von Vorteil, da es in der Regel keine „unsichtbaren“ Schulden gibt, die sonst vor einer größeren Veröffentlichung gemacht werden müssten.
Typische Symptome für die Anhäufung technischer oder geschäftlicher Schulden sind so genannte Härtungssprints, Release-Sprints, Bugfix-Sprints oder wie auch immer man sie nennen möchte. Ihr Ziel ist es, alle Schulden zu beseitigen, bevor eine Version erstellt werden kann, die potenziell freigegeben werden kann. Dies ist ein starker Geruch, da er auf die Unfähigkeit hinweist, regelmäßig funktionierende Versionen zu erstellen. Es heilt zwar die Symptome, aber das zugrundeliegende, gewohnheitsmäßige Problem ist immer noch da. Es bedeutet im Grunde, dass das Team bis zum Härtungssprint nie wirklich eine funktionierende, potenziell veröffentlichungsfähige Version des Produkts hatte. Wäre dies der Fall, wären die Fehler (oder Schulden jeglicher Art) bereits beseitigt, und es bestünde keine Notwendigkeit für eine zusätzliche Auszeit, um Dinge zu beheben.
Meiner Meinung nach geschieht dies oft aufgrund eines unkonstruktiven Drucks, der auf das Entwicklungsteam ausgeübt wird, um neue Dinge schneller zu liefern, und der durch einen externen Faktor entsteht. Ich habe erlebt, dass Product Owner und sogar Scrum Master Teams dazu drängen, mehr Dinge für einen Sprint zu planen, ohne dass dies durch die bisherige Geschwindigkeit des Teams gerechtfertigt wäre. Dadurch entsteht ein falsches Gefühl des Fortschritts, das jedoch mit einer großen Unsicherheit verbunden ist. Es führt zu übermäßigem Engagement und naiver Planung, wobei die Tatsache ignoriert wird, dass es „unsichtbare“ Arbeit gibt, die immer wieder anfällt: gefundene Fehler, klitzekleine Optimierungen, Refactoring hier und da, kleine Änderungen, Analysen, Verfeinerung des Backlogs. Dies zu ignorieren, führt zum Hamsterrad-Effekt.
Es gibt keinen Grund, sogenannte Härtungssprints vor der Freigabe durchzuführen, wenn man bewusst keine Schulden vor sich herschiebt. Wie kann man überhaupt eine Release-Planung durchführen, wenn man nicht weiß, wie viele Probleme auftauchen werden, wenn man nach vielen Monaten der Entwicklung tatsächlich versucht, eine releasefähige Version zu erstellen? Es ist immer wertvoller (und natürlich stressfreier), nach jedem Sprint regelmäßig eine funktionierende, schuldenfreie Version zu haben (mit scheinbar weniger neuen Funktionen), aber zu wissen, dass sich keine Leichen im Keller verbergen. Probleme so früh wie möglich zu erkennen, um zu wissen, wie weit man gekommen ist und wie weit man noch gehen muss, darum geht es bei agilem Vorgehen. Das ist die Transparenz, von der alle reden, oder?
Was ist mit Fehlern?
Das Scrum-Team sollte verstehen, dass „fertig“ bedeutet, dass das Team einigermaßen überzeugt ist, dass an der neuen Lieferung nichts mehr zu tun ist. Keine To-Dos. Keine Bugs. Keine technischen Schulden. Keine Formulierungen, die noch überarbeitet werden müssen, keine Grafiken, die nur provisorisch sind. Aber realistisch betrachtet ist Software nie fehlerfrei. Es kann vorkommen, dass kurz vor der Veröffentlichung eines Sprints ein Fehler entdeckt wird. Es ist verlockend, deswegen die ganze Version zu blockieren.
Es wird demnächst einen Artikel über den Umgang mit Fehlern in der agilen Produktentwicklung geben, aber kurz gesagt ist es immer eine gute Idee, sich zu fragen, ob der entdeckte Fehler eine Regression im Vergleich zur letzten produktiv genutzten Version ist. Wenn dies nicht der Fall ist (d. h. der Fehler existiert bereits in der aktuellen Live-Version), gibt es selten einen Grund, ein Update nicht zu veröffentlichen, auch wenn der Fehler dadurch nicht behoben wird. Und dieser entdeckte Fehler wird dann im Backlog genauso priorisiert wie jeder andere Punkt auch.
Es ist ein langer Weg
Ich behaupte nicht, dass es einfach ist, regelmäßige Veröffentlichungen zu erreichen. Meine Erfahrung zeigt, dass es nicht einfach ist, aber das bedeutet nicht, dass das Scrum-Team aufgeben sollte.
Die Übernahme dieser Gewohnheit und dieser Werte gibt dem Product Owner ein hohes Maß an Vorhersehbarkeit für die künftige Planung, da er weiß, dass er regelmäßig etwas veröffentlichen kann. Es nimmt auch den Druck, wenn etwas auf ein späteres Datum als geplant verschoben wird, weil jeder weiß, dass es in kurzer Zeit sowieso veröffentlicht wird. Die Dinge werden plötzlich viel aufgeräumter.Letztes Mal haben wir über unregelmäßige Releases gesprochen und warum sie passieren. Lassen Sie uns also ohne Umschweife dort weitermachen, wo wir aufgehört haben.
Sprint-Strategie fortgesetzt
Manchmal ist es verlockend, eine Art Code-Freeze einzuführen, d.h. ein Datum, nach dem kein neuer Code mehr in die Sprint-Version aufgenommen werden darf (nur noch Fehlerbehebungen sind erlaubt). Obwohl diese Idee im Allgemeinen nicht schlecht ist, schränkt die Festlegung eines festen Datums den Handlungsspielraum eines Teams ein und behindert oft die Effektivität. Feste Code-Freezes sind ein wasserfallartiger Versuch, ein Gefühl der Kontrolle zu vermitteln. Natürlich ist dies oft nicht die Idee des Entwicklungsteams selbst, sondern eher ein Prozess des Unternehmens. Das Einfrieren von Code beraubt das Team eines der wichtigsten Werte von Agile - der Anpassungsfähigkeit und der Möglichkeit, kreative Wege zu finden, um effektiver zu werden.
Die Risiken in den Elementen müssen für jeden Sprint Backlog einzeln bewertet werden (je nach Größe, Komplexität, technischem Anspruch usw.). Das Team muss dann den spätesten angemessenen Zeitrahmen für den Beginn der abschließenden Tests festlegen. Das bedeutet zum Beispiel, dass dieser Zeitrahmen für ein großes Element etwa in der Mitte des Sprints liegen könnte, während für eine kleine Änderung ein halber Tag vor Ende des Sprints ausreicht. Nach diesem Zeitpunkt ist es riskant, dieses Element in das Produktinkrement des Sprints aufzunehmen. Auch hier muss das Team individuell bewerten, wie hoch das Risiko zusätzlicher Arbeit ist, nachdem es die Implementierung einer Story abgeschlossen und mit den abschließenden Tests begonnen hat, und dies entsprechend einplanen. Der Versuch, ein einheitliches Datum für das Einfrieren des Codes festzulegen, führt in der Regel dazu, dass das Datum für Elemente von geringer Komplexität zu früh und für komplexere Elemente viel zu spät ist.
Das Schöne an häufigen Releases
Am Ende des Sprints entscheidet der Product Owner, ob er die Version des Sprints tatsächlich veröffentlichen will oder nicht. Es mag aus vielen Gründen nicht notwendig sein, aber er muss immer die Möglichkeit haben, dies zu tun. Im Allgemeinen ist es von Vorteil, so oft wie möglich zu veröffentlichen. Durch die häufige Freigabe kleinerer Stapel von Funktionen ist das Risiko, dass etwas Wichtiges schief geht, viel geringer und ein möglicher Rollback ist nicht so schmerzhaft. Auch für die Planung ist dies von Vorteil, da es in der Regel keine „unsichtbaren“ Schulden gibt, die sonst vor einer größeren Veröffentlichung gemacht werden müssten.
Typische Symptome für die Anhäufung technischer oder geschäftlicher Schulden sind so genannte Härtungssprints, Release-Sprints, Bugfix-Sprints oder wie auch immer man sie nennen möchte. Ihr Ziel ist es, alle Schulden zu beseitigen, bevor eine Version erstellt werden kann, die potenziell freigegeben werden kann. Dies ist ein starker Geruch, da er auf die Unfähigkeit hinweist, regelmäßig funktionierende Versionen zu erstellen. Es heilt zwar die Symptome, aber das zugrundeliegende, gewohnheitsmäßige Problem ist immer noch da. Es bedeutet im Grunde, dass das Team bis zum Härtungssprint nie wirklich eine funktionierende, potenziell veröffentlichungsfähige Version des Produkts hatte. Wäre dies der Fall, wären die Fehler (oder Schulden jeglicher Art) bereits beseitigt, und es bestünde keine Notwendigkeit für eine zusätzliche Auszeit, um Dinge zu beheben.
Meiner Meinung nach geschieht dies oft aufgrund eines unkonstruktiven Drucks, der auf das Entwicklungsteam ausgeübt wird, um neue Dinge schneller zu liefern, und der durch einen externen Faktor entsteht. Ich habe erlebt, dass Product Owner und sogar Scrum Master Teams dazu drängen, mehr Dinge für einen Sprint zu planen, ohne dass dies durch die bisherige Geschwindigkeit des Teams gerechtfertigt wäre. Dadurch entsteht ein falsches Gefühl des Fortschritts, das jedoch mit einer großen Unsicherheit verbunden ist. Es führt zu übermäßigem Engagement und naiver Planung, wobei die Tatsache ignoriert wird, dass es „unsichtbare“ Arbeit gibt, die immer wieder anfällt: gefundene Fehler, klitzekleine Optimierungen, Refactoring hier und da, kleine Änderungen, Analysen, Verfeinerung des Backlogs. Dies zu ignorieren, führt zum Hamsterrad-Effekt.
Es gibt keinen Grund, sogenannte Härtungssprints vor der Freigabe durchzuführen, wenn man bewusst keine Schulden vor sich herschiebt. Wie kann man überhaupt eine Release-Planung durchführen, wenn man nicht weiß, wie viele Probleme auftauchen werden, wenn man nach vielen Monaten der Entwicklung tatsächlich versucht, eine releasefähige Version zu erstellen? Es ist immer wertvoller (und natürlich stressfreier), nach jedem Sprint regelmäßig eine funktionierende, schuldenfreie Version zu haben (mit scheinbar weniger neuen Funktionen), aber zu wissen, dass sich keine Leichen im Keller verbergen. Probleme so früh wie möglich zu erkennen, um zu wissen, wie weit man gekommen ist und wie weit man noch gehen muss, darum geht es bei agilem Vorgehen. Das ist die Transparenz, von der alle reden, oder?
Was ist mit Fehlern?
Das Scrum-Team sollte verstehen, dass „fertig“ bedeutet, dass das Team einigermaßen überzeugt ist, dass an der neuen Lieferung nichts mehr zu tun ist. Keine To-Dos. Keine Bugs. Keine technischen Schulden. Keine Formulierungen, die noch überarbeitet werden müssen, keine Grafiken, die nur provisorisch sind. Aber realistisch betrachtet ist Software nie fehlerfrei. Es kann vorkommen, dass kurz vor der Veröffentlichung eines Sprints ein Fehler entdeckt wird. Es ist verlockend, deswegen die ganze Version zu blockieren.
Es wird demnächst einen Artikel über den Umgang mit Fehlern in der agilen Produktentwicklung geben, aber kurz gesagt ist es immer eine gute Idee, sich zu fragen, ob der entdeckte Fehler eine Regression im Vergleich zur letzten produktiv genutzten Version ist. Wenn dies nicht der Fall ist (d. h. der Fehler existiert bereits in der aktuellen Live-Version), gibt es selten einen Grund, ein Update nicht zu veröffentlichen, auch wenn der Fehler dadurch nicht behoben wird. Und dieser entdeckte Fehler wird dann im Backlog genauso priorisiert wie jeder andere Punkt auch.
Es ist ein langer Weg
Ich behaupte nicht, dass es einfach ist, regelmäßige Veröffentlichungen zu erreichen. Meine Erfahrung zeigt, dass es nicht einfach ist, aber das bedeutet nicht, dass das Scrum-Team aufgeben sollte.
Die Übernahme dieser Gewohnheit und dieser Werte gibt dem Product Owner ein hohes Maß an Vorhersehbarkeit für die künftige Planung, da er weiß, dass er regelmäßig etwas veröffentlichen kann. Es nimmt auch den Druck, wenn etwas auf ein späteres Datum als geplant verschoben wird, weil jeder weiß, dass es in kurzer Zeit sowieso veröffentlicht wird. Die Dinge werden plötzlich viel aufgeräumter.
