Umgang mit Fehlern im Scrum-Prozess?

Wohin gehören technische Schulden?

Sollten diese Themen unter User Stories/Child Tech Tasks gruppiert und innerhalb des Sprint-Prozesses berücksichtigt werden?

Nein. Oh, es gibt einige Fälle, in denen einige kleine Aufgaben zum Sprint-Backlog hinzugefügt werden müssen, um das Sprint-Ziel zu erreichen, aber nur Geschichten, die vom Team aus dem Product-Backlog akzeptiert werden, weil sie glauben, dass sie in den aktuellen Sprint passen sollten Aufgaben im Sprint Backlog generieren. Technische Schulden, insbesondere technische Schulden aus vergangenen Iterationen, gehören immer in das Product Backlog.

Kleiner Vorbehalt: Technische Schulden, die innerhalb des aktuellen Sprints entstanden sind und innerhalb desselben Sprints korrigiert werden können, ohne das Sprintziel zu gefährden, können dem Sprint Backlog hinzugefügt werden. Unvollendete Geschichten (einschließlich Geschichten über technische Schulden) gehen jedoch am Ende jedes Sprints zurück in das Product Backlog.

Was verursacht technische Schulden?

Tech-Schulden entstehen am häufigsten, wenn Abkürzungen gemacht werden oder Geschichten impliziert statt explizit gemacht werden. Einige Beispiele könnten sein:

1. Die „Definition of Done“ ermöglicht es, Stories als erledigt zu markieren, selbst wenn es bekannte Fehler und/oder Geschäftsrisiken gibt, wie z. B. teilweise implementierte Features.
2. Sie wussten damals nicht, was Sie heute über die Codebasis, die Architektur oder die Kundenanforderungen wissen.
3. Es fehlten Storys im Product Backlog, wie zum Beispiel die Storys zur Bereinigung aller Verweise auf „foo“, als Ihre Organisation alle Widgets in „bar“ umbenannte.
4. Der Product Owner hat das Geschäftsrisiko akzeptiert, weil er dem Backlog keine Tech-Debt-Storys hinzugefügt hat.

Es gibt sicherlich andere Möglichkeiten, wie sich technische Schulden einschleichen können. Der Punkt ist jedoch, dass technische Schulden nicht nur das Team betreffen, sondern das gesamte Projekt .

Warum Technical Debt ins Product Backlog gehört

Das Ziel von Scrum ist nicht, eine bestimmte Geschwindigkeit beizubehalten; Ziel von Scrum ist es, den Entwicklungsprozess in der gesamten Organisation transparent zu machen. Als direkte Folge davon müssen technische Schulden in dem einzigen Artefakt sichtbar gemacht werden, das organisationsweit zählt: dem Product Backlog.

Neben der Sichtbarkeit verlangsamen technische Schulden normalerweise die Entwicklung. Dies geschieht, indem neue Änderungen erschwert oder die Geschwindigkeit neuer Funktionen verringert wird, indem Ressourcen (sichtbar) für die Korrektur von Fehlern oder Fehlfunktionen aufgewendet werden müssen. Wenn Sie die Fehler nicht unter den Teppich kehren (Tipp: Tun Sie das nicht!), wird sich Ihre Geschwindigkeit wahrscheinlich nicht wesentlich ändern, es sei denn , Ihr Product Owner weigert sich, technische Schuldgeschichten zum Product Backlog hinzuzufügen.

Denken Sie daran, dass das Product Backlog dem Product Owner gehört. Das bedeutet nicht, dass das Team nicht empfehlen kann, Stories zum Product Backlog hinzuzufügen und zu priorisieren; es bedeutet lediglich, dass der Product Owner das letzte Wort darüber hat, was im Product Backlog steht und wie jede Story priorisiert wird.

Ebenso ist das Team die einzige Einheit, die Storys schätzen und bestimmen kann, was in jeden Sprint passt. Das bedeutet, dass ein Team, das eine genaue Schätzung vornimmt , die Schulden in seine Story-Schätzungen einbeziehen wird , wenn sich nicht adressierte technische Schulden häufen . Dadurch wird die Geschwindigkeit (korrekterweise) verlangsamt, wodurch die Organisation die Auswirkungen der Schulden auf das Projekt erkennen kann.

Konkretes Beispiel

Angenommen, Sie haben einen leistungsschwachen Continuous Integration-Server. Dies verlangsamt das Testen neuer Funktionen und Fehlerbehebungen, was dazu führt, dass sich die Geschwindigkeit des Teams verlangsamt, da es immer länger dauert, jede neue Geschichte abzuschließen. Nehmen wir auch an, dass der Aufbau einer neuen CI-Infrastruktur etwas ist, das erhebliche Anstrengungen erfordern würde.

Richtig wäre es, eine User Story zum Upgrade der CI-Infrastruktur zu erstellen. Es können zusätzliche Aufgaben und Geschichten damit verbunden sein, also erfassen Sie sie alle. Diese Geschichten sollten an den Product Owner zur Aufnahme in das Product Backlog weitergeleitet werden.

Wenn der Product Owner dies nun zu einer Priorität macht, dann wird dies ein Schluckauf sein, der im nächsten Sprint geglättet wird. Der Product Owner kann jedoch sagen: „Nein, das ist nicht wichtig genug, um Prioritäten zu setzen. Ich werde die Kosten für das Projekt mit geringerer Geschwindigkeit akzeptieren, um andere Funktionen zu priorisieren, die für die Stakeholder wichtiger sind.“

Das ist okay! Es bedeutet nicht mehr Arbeit für das Team, es bedeutet nur eine geringere Leistung des Teams im Austausch für die Priorisierung anderer Geschäftsanforderungen, die vom Product Owner festgelegt wurden. Dies ist sowohl legitim als auch transparent und beweist daher den Wert des Frameworks.

Beziehen Sie Schulden in Ihre Schätzungen ein

Wenn Sie Storys während der Sprint-Planung schätzen, werden ausstehende technische Schulden die Story-Schätzungen sichtbar belasten. Etwas, das ohne die Schulden eine 1-Punkte-Geschichte gewesen sein mag, kann zu einer 5-Punkte-Geschichte werden, weil die Schulden unbezahlt bleiben.

Denken Sie daran, dass Story Points ein Maß für den relativen Aufwand sind. Da der Aufwand zur Bereitstellung von Funktionen zunimmt, sollten auch die Schätzungen steigen. Infolgedessen ändert sich die tatsächliche Geschwindigkeit des Teams selten aufgrund technischer Schulden , es sei denn, Sie missbrauchen die Geschwindigkeit oder erlauben anderen außerhalb des Teams, Schätzungen abzugeben. Das einzige, was sinken wird, ist die Rate neuer Funktionen, und die Priorisierung von Debt Stories zur Verbesserung der Bereitstellungsrate ist die Aufgabe des Product Owners.

Ihre Aufgabe als Scrum Master ist es, sicherzustellen, dass sowohl der Product Owner als auch das Entwicklungsteam ausreichende Informationen darüber geben, wie der Scrum-Prozess verwendet werden kann, um effektiv über diese Probleme zu kommunizieren. Das Product Backlog ist das richtige Werkzeug, um technische Schulden anzugehen, aber Kommunikation ist der wesentliche Mechanismus, durch den technische Schulden von einer unsichtbaren Blockade zu einem umsetzbaren Element bewegt werden.

Jede Aufgabe, die das Team ausführen wird, sollte in jedem Sprint dokumentiert und berücksichtigt werden. Egal, ob es sich um eine User Story, einen Fehler oder eine technische Schuld handelt, jedem Element sollten die entsprechenden Punkte zugewiesen werden, damit das Team weiterhin die richtige Geschwindigkeit überwacht. Ein weiterer Vorteil davon ist, dass alle Beteiligten wissen, was getan wird und warum.

Für die Probleme, auf die Sie gestoßen sind, sollten neue Storys / technische Schuldenaufgaben erstellt und zum Sprint-Backlog hinzugefügt werden (gemäß der Geschwindigkeit des Teams). Diese können dazu führen, dass einige User Stories (vielleicht Funktionsanfragen) in zukünftige Sprints verschoben werden, was in Ordnung ist, solange die Beteiligten zustimmen, dass die Tilgung technischer Schulden mehr Wert bietet als Funktionsanfragen.

Sollten diese Themen unter User Stories/Child Tech Tasks gruppiert und innerhalb des Sprint-Prozesses berücksichtigt werden?

es kommt darauf an (wie groß und wie kritisch diese Bugs sind)

Wenn das Objekt groß genug ist (kritische Fehler und die Behebung erfordern eine Menge Code zu ändern), sieht es aus wie eine Geschichte (oder sogar episch).

Auf der anderen Seite - Sie haben möglicherweise eine Menge kleinerer unabhängiger Elemente - legen Sie sie einfach alle in die Box "Aktive Fehler" und arbeiten Sie daran, wenn Sie Zeit haben