Welche Strategien kann ich anwenden, um Tickets während eines Scrum-Sprints zu bearbeiten?

Planen Sie Zeit für solche Triage-Arbeiten für Produktionsfehler ein

Das ist nicht sehr ungewöhnlich. Die meisten Softwareentwicklungsteams müssen darauf vorbereitet sein, Produktionsfehler vorrangig zu beheben, falls welche gemeldet werden. Es ist auch ganz normal, dass Fehlerberichte zuerst gesichtet werden müssen, auch wenn sich herausstellt, dass einige von ihnen überhaupt keine Fehler sind. Ihr Team scheint jedoch mehr von ihnen mit strengeren SLAs zu haben.

So gehe ich in Ihrer Situation vor:

1. Halten Sie zum Zeitpunkt der Sprint-Planung Bandbreite für solche Bug-Triage-Arbeiten bereit. Sie können sich den Prozentsatz der Zeit ansehen, die in den letzten Wochen/Monaten für solche Arbeiten aufgewendet wurde, und sich darauf stützen. Wenn es viele solcher Arbeiten gibt, prüfen Sie, ob einer der 4-Mann-Teams für diese Arbeit dediziert werden muss.
2. Halten Sie auch einige Stories vollständig bereit und geplant, aber nicht im Sprint-Backlog, sondern oben auf dem Backlog. Eines davon kann eingezogen werden, wenn es während des Sprints so aussieht, als wäre es möglich, es zu übernehmen.
3. Wenn das Fehlerticket eintrifft, schätzen Sie es genau wie die anderen Geschichten. Auf diese Weise haben Sie eine Aufzeichnung darüber, wie viel Arbeit während des Sprints erledigt wurde.
4. Verwendet diese engagierte Person ein Kanban-Board, um kommerzielle Tickets und einfache Probleme zu handhaben? Wenn nicht, erwägen Sie die Verwendung eines.

Ich denke, Sie können den folgenden Artikel interessant lesen: Applying Agile in a Mixed-Feature Development and SLA-Bound Bug-Fixing Team

Ich glaube, dass es eine gute Lösung für das SLA-Problem ist, ein engagiertes Teammitglied zu haben, das sich um Tickets kümmert. Auf diese Weise können die anderen drei Teammitglieder die Sprints ohne Unterbrechung aufrechterhalten .

Die meisten Entwickler arbeiten nicht gerne ausschließlich an Support-Problemen. Damit die Moral des „Support-Entwicklers“ nicht darunter leidet, haben Sie sich richtigerweise für das Round-Robin-Prinzip entschieden. Es ist auch aus einem anderen Grund ratsam, dies zu tun. Ohne Rotation in dieser Aufgabe werden viele Bugs nur vom selben „Support-Entwickler“ behandelt, und die verbleibenden Entwickler könnten beginnen, weniger auf die Codequalität zu achten.

Der „Support-Entwickler“ könnte mit Kanban Support-Tickets schneller lösen und neue Releases erstellen, ohne auf das Ende eines Sprints warten zu müssen .

Sie haben geschrieben, dass der "Support-Entwickler" manchmal bestimmte Fragen/Probleme nicht alleine bewältigen kann. Eine andere Lösung kann darin bestehen, den Tickets im Voraus Zeit zuzuweisen. Um mehr darüber zu erfahren, wie Sie einen gewissen Prozentsatz Ihrer Geschwindigkeit als Interrupt-Puffer reservieren können, können Sie sich das Scrum-Muster ansehen, das als „ Illegitimus Non Interruptus “ bekannt ist.

Wenn die Geschwindigkeit Ihres Teams durch Tickets beeinflusst wird, ist es wichtig, diese Auswirkungen in Ihrer Sprintplanung zu berücksichtigen. Dazu gibt es mindestens zwei Möglichkeiten.

Option eins: Wenn es nicht möglich ist, Tickets Story Points zuzuweisen, lassen Sie Ihre Geschwindigkeit sinken. Betrachten Sie eine reduzierte Geschwindigkeit nicht als eine schlechte Sache. Der Zweck der Geschwindigkeit besteht darin, einem Team zu helfen, zu verstehen, wie viel Arbeit es innerhalb eines bestimmten Zeitraums leisten muss. Ein Team mit niedriger Geschwindigkeit, das seine Verpflichtungen erfüllt, ist einem Team mit hoher Geschwindigkeit vorzuziehen, das in seinen Verpflichtungen höchst unzuverlässig ist.

Option 2: Wenn es möglich ist, Tickets mit Story Points zu versehen, zählen Ticket-Abschlüsse zur Velocity des Teams. Achten Sie auf den Prozentsatz der Velocity des Teams, der durch das Schließen von Tickets beigesteuert wird. Reservieren Sie bei der Planung eines Sprints (einer neuen Arbeitsperiode) eine angemessene Menge an Kapazität für Tickets, die das Team während des Sprints erwartet. Wenn die Geschwindigkeit beispielsweise 100 beträgt und Tickets 40 beitragen, dann verpflichten Sie sich nur zu 60 Punkten Nicht-Ticket-Arbeit. Wenn das Team während des Sprints Nicht-Ticket-Arbeit abschließt und nicht die erwartete Menge an Ticket-Arbeit erhält, kann das Team zusätzliche Nicht-Ticket-Storys in den Sprint ziehen.

Option zwei ist der bevorzugte Ansatz. Denken Sie daran, dass der Zweck der Geschwindigkeit darin besteht, Teams bei der Planung eines Sprints dabei zu helfen, zu vermeiden, dass sie sich auf mehr Arbeit festlegen, als während eines Sprints erledigt werden kann. Sobald Zusagen erfüllt wurden, ist es für ein Team immer in Ordnung, zusätzliche Arbeit in einen Sprint zu ziehen.

Wie @Depressive_Bore erwähnt hat, werden Ihnen die Antworten zur Softwarewartung wahrscheinlich hilfreich sein.

Wie oben gesagt, ist dies ein allgemeines Szenario.

In unserem 4-köpfigen Team haben wir ein engagiertes Teammitglied für die Behandlung der Produktionsfehler. Seine Geschwindigkeit ist für diesen Sprint null (wir verfolgen die Anzahl der Tickets, die von ihm/ihr geschlossen wurden). Diese Rolle wird im Round-Robin-Verfahren ausgeführt.

Die verbleibenden Teammitglieder werden als Geschwindigkeit für diesen Sprint verwendet.

Automatisiertes Testen.

Wie Sie anmerken, handelt es sich bei den meisten dieser Probleme nicht um Fehler, und die meiste Zeit, an ihnen zu arbeiten, besteht wahrscheinlich darin, „Dinge herauszufinden“, anstatt den Code zu ändern.

Obwohl es wie ein Zeit-/Ressourcenmanagement-Problem erscheinen mag, besteht Ihr Problem tatsächlich darin, den Kundensupport als eine Reihe technischer Aufgaben zu behandeln, die Ihrem Sprint hinzugefügt werden müssen. Techies neigen nicht dazu, die besten Kundenbetreuer zu sein!

Um dies zu vermeiden, benötigen Sie einen schnellen und effizienten Test, um zu entscheiden, ob das Problem eine Codeänderung erfordert, um es zu beheben, und wenn ja, welche Anforderungen diese Änderung erfüllen sollte.

Idealerweise stellt eine automatisierte Testsuite fest, ob das Produkt wie vorgesehen funktioniert und vor und nach jeder Version ausgeführt werden kann.

Sie können aber auch eine Reihe manueller Tests aufbauen, indem Sie jedes Mal, wenn ein Fehler gemeldet wird, Schritte und erwartetes Verhalten sowie häufige Korrekturen aufschreiben. Sobald Sie einen großen Satz davon haben, können sie an ein weniger technisch versiertes Kundensupport-Team übergeben werden, um es durchzugehen, bevor das Problem eskaliert