Wir haben Scrum vor kurzem bei der Arbeit angenommen und stoßen auf Probleme mit einer Reihe von kleinen Fehlern, die nach dem Akzeptieren des Codes auftreten. Dazu gehören Dinge wie Rechtschreibfehler und andere Single-Line-Fixes. Für jede Kleinigkeit Geschichten der Größe 0,5 zu schaffen, scheint Zeitverschwendung. Es braucht mehr Zeit, um die Geschichte zu schreiben und darauf hinzuweisen, als um das Problem zu lösen. Wenn es nur einen oder zwei davon pro Sprint gäbe, wäre es einfach, sie einfach zu reparieren und sich keine Sorgen zu machen, Geschichten für sie zu erstellen. Wenn es jedoch 10 oder 20 oder mehr gibt, weil die Anwendung groß ist, kann dies zu erheblichen Mengen an Entwicklerzeit führen, die nicht über Scrum berücksichtigt werden. Während es leicht sein kann zu sagen, dass die QA-Mitarbeiter und Produktbesitzer gründlicher sein sollten, bevor die ursprüngliche Geschichte überhaupt akzeptiert wird, bin ich der Entwickler, so dass es im Wesentlichen nicht in meinen Händen liegt.
Ein paar unvollkommene Ideen, auf die wir bisher gekommen sind:
Irgendwelche Vorschläge?
Ihre dritte Antwort ist die beste Methode. Ein Sprint ist einfach eine Verpflichtung des Teams, eine bestimmte Menge an Arbeit in einem definierten Zeitraum zu erledigen. Wenn du mitten im Sprint zusätzliche Arbeit akzeptierst, weicht du von dieser ursprünglichen Verpflichtung ab, indem du an Dingen arbeitest, die zu Beginn des Sprints nicht vom Team übernommen wurden.
Folgendes machen wir:
Hier ist das Problem mit Ihren anderen Lösungen:
Erzählen Sie eine Geschichte, die besagt, dass 90% der Fehler in der App behoben wurden. Dann raten Sie, wie viele Fehler in diesem Sprint auftreten und wie viele Fehler behoben werden können. stark>
Noch einmal, siehe oben. Sie wollen leere Arbeitseimer vermeiden, die während des Sprints gefüllt werden können. Dies vereitelt den Zweck einer definierten Verpflichtung des Teams. Wie kann sich das Team zu etwas verpflichten, was sie nicht wissen oder nicht geschätzt haben?
Außerdem kann dies leicht zu einem Product Owner werden, der "Design by Defect" erstellt, indem er diesen Bucket mit nice-to-have Funktionalität füllt, die sich wirklich als Defekte tarnt.
Haben Sie eine Geschichte von Größe, sagen wir, 8, die IMMER am Ende des Sprints akzeptiert wird, wo Sie so viele Fehler wie möglich beheben können. Dies erfordert offensichtlich viel Vertrauen, dass jeder tatsächlich eine Arbeit im Wert von 8 macht.
Das klingt seltsam. Das Team sollte die Arbeit zu Beginn der neuen Sprint-Planung akzeptieren, nicht am Ende des vorherigen Sprints. Darüber hinaus wird dies Ihre Geschwindigkeit auf lange Sicht verfälschen. Scrum bezieht sich auf Product Backlog Items, nicht nur auf Stories, also gibt es nichts zu sagen, dass Sie keine Defekte als PBIs hinzufügen können.
Zeichne Bugs auf, arbeite aber erst im nächsten Sprint daran. Sie können einzeln oder als Gruppe gezeigt werden. Dies hat den Vorteil, dass es mehr "Scrummy" ist, aber eine dreiwöchige Verzögerung verursacht, die im Wesentlichen 1 Stunde dauert.
Sie machen einen interessanten Punkt und wir hatten auch einige Bedenken. Allerdings ist diese 1-Stunden-Korrektur (unabhängig davon, wie schnell sie ist) nicht zeitaufwendig, wenn sie sich gegen die anderen Dinge im Rückstand stapelt. Die Quintessenz ist, dass Sie diese Entscheidungen an den Product Owner weitergeben und ihnen die Freiheit geben möchten, ALLES zu priorisieren, worauf sich das Team konzentriert.
Ich bin fest davon überzeugt, dass ein Prozess nur so gut ist wie die Fähigkeit, eine Situation zu verbessern. Der Prozess sollte für Sie arbeiten, nicht umgekehrt.
Wenn der Agile-Scrum-Prozess dem "T" in dieser Situation mehr schadet als nützt, dann ist es an der Zeit, eine bessere Lösung außerhalb des Scrum-Prozesses zu finden.
Wir haben einen Mini-QA-Sprint erstellt, der bis zum Ende jedes Sprints angehängt wird. Es ist nach dem Code abgeschlossen, aber vor der Veröffentlichung. In diesem kurzen Zeitraum werden die Probleme sorgfältig geprüft und können auf der Grundlage von Risiko und Kritikalität zur Aufnahme zugelassen werden. In diesem Zeitraum behobene Probleme haben eine zusätzliche Ebene eines benutzerdefinierten Überprüfungsprozesses, arbeiten jedoch weitgehend außerhalb des definierten Scrum-Prozesses.
Haben Sie in Ihrer Retrospektive die Ursache für diese Fehler identifiziert? Verwenden Sie technische (XP) Praktiken, d. H., TDD - testgetriebene Entwicklung, automatisch gestützte Funktionstests werden täglich vollständige Regressionstests zusammen mit Pairing und Story Cards mit Akzeptanzkriterien durchgeführt.
Wenn ein Defekt gefunden wird, wird die Wurzel identifiziert und ist eine automatisierte Einheit und ein Funktionstest zu Ihren Testkabeln hinzugefügt, um einen solchen Defekt zu erfassen, sollte er erneut auftreten?
Aus meiner Sicht ist Ihre Fehlerrate zu hoch. Wenn man TDD und voll funktionsfähige Regressionstests mindestens täglich durchführt, ist es nicht ungewöhnlich, während der UAT Null-Fehler zu erreichen.
Kurzfristig können Sie dem Team x Anzahl von Einheiten / Arbeitspunkten berechnen, um die Fehler zu beheben (schauen Sie sich Ihre letzte Iteration an und wenn es x Stunden pro Iteration braucht, um die kleinen Fehler zu beseitigen, subtrahieren Sie diese Zeit von der Kapazität Ihres Teams.) Längerfristig, konzentrieren Sie sich auf die Ursache und verbessern Sie die Engineering-Praktiken Ihres Teams.
Aus der Messung der Kosten von Fehlerbehebungen haben wir die folgende Beziehung gesehen. Wenn ein Defekt während der Entwicklung 1x kostet, kostet es 2x beim Funktionstest, 3x bei UAT und 4x bei der Produktion. Durch das Schreiben von Story Cards mit Akzeptanzkriterien, Pair-Entwicklung, testgetriebener Entwicklung und automatischem Funktionstest mit mindestens täglichen vollständigen Regressionstests verbessern Sie die Qualität und senken die Kosten erheblich. Daher müssen Sie keine Zeit mehr von der Kapazität Ihres Teams abziehen, was die Geschwindigkeit erhöht.
Dies ist ein gutes Beispiel für den starken Bedarf an guten technischen Praktiken in Scrum-Projekten.
"[wir] haben Probleme mit einigen kleinen Fehlern, die erscheinen, nachdem der Code akzeptiert wurde"
Dies deutet darauf hin, dass Ihre "Definition von done" nicht stark genug ist.
"Dazu gehören Dinge wie Rechtschreibfehler"
Werden diese Rechtschreibfehler auf der Benutzeroberfläche angezeigt? Wer sie erkennt, nachdem der Code akzeptiert wurde, sollte sie vor dem Akzeptieren des Codes erkennen.
Die Sache, die mit Defekten zu tun hat, ist 1) sie sofort zu beheben, 2) das System so zu instrumentieren, dass ähnliche Defekte früher beim nächsten Mal aufgefangen werden und 3) Ihren Prozess so zu verbessern, dass die Art des Fehlers zum Defekt führt weniger wahrscheinlich in der Zukunft auftreten. Dies sind alles technische Probleme.
Ich hatte die folgenden Richtlinien in meinen Projekten erfolgreich:
Die Fehlerkorrektur hat immer Vorrang vor der Feature-Entwicklung. Das Ziel besteht darin, zu jeder Zeit null offene Defekte zu haben, wobei 100% Arbeitsmerkmale gegenüber fast funktionierenden Merkmalen bewertet werden.
Defekte können und sollten behoben werden, sobald sie gefunden werden. Ein Ticket muss nur archiviert werden, wenn der Fehler von einem Nicht-Entwickler gefunden wird oder wenn der Entwickler feststellt, dass der Fehler nicht sofort behoben werden kann.
Fehler, die Änderungen auf der Architekturebene an der Codebasis erfordern, haben den Architektur-Optimierungsteil als Geschichte protokolliert und geschätzt & amp; zu einem bevorstehenden Sprint geplant. Der Fehlerstatus wird bei der Story-Implementierung als ausstehend festgelegt.
Sprint Backlog ist vor externen Änderungen geschützt, aber das Team selbst kann neue Sachen in der Mitte eines Sprints einführen, die erforderlich sind, um die Null-Fehler zu jeder Zeit Ziel zu treffen.
Wenn sich ein Fehler nicht lohnt (basierend auf einer rudimentären Kosten-Nutzen-Analyse), wird er einfach ignoriert, um offene Fehler zu vermeiden, die den Issue Tracker verschmutzen.
Das Priorisieren von Fehlerbehebungen über die Story-Implementierung wird von Zeit zu Zeit Ihre Geschwindigkeit beeinflussen, aber es ist in Ordnung. Auf lange Sicht wird Ihre Effizienz bei der Umsetzung von Geschichten steigen, da die Codebasis nur wenig technische Schulden hat.
Was wir normalerweise tun, falls der Bug nichts mit dem zu tun hat, was Sie entwickeln, oder sagen wir irgendeine andere "nicht zusammenhängende" Aktivität, die während eines Sprints passiert, ist ein "Kontingent" zu erstellen.
Es ist im Grunde genommen eine gewisse Zeit, die von Ihrer "Kapazität" für einen Sprint entfernt wird, und wird auf Anfrage für Aktivitäten außerhalb des Sprintziels reserviert. Dies funktioniert folgendermaßen:
Täglich konzentriert sich das Team auf das Sprint-Ziel, hat aber einen "Puffer" an Zeit (das Kontingent), um sich um externe Probleme zu kümmern. Beim Täglichen Aufstehen kann die PO täglich eingehende Probleme anzeigen, und die Teammitglieder, die eine Sprint-Aufgabe abgeschlossen haben (so dass es keine Unterbrechung gibt), werden eventuell eines der Probleme beheben.
Es ist die Zeit, die für das Kontingent gebucht wurde, dass, wenn es zu Ende geht, geschlossen werden muss.
Das Team hat das Recht, dem Product Owner mitzuteilen, dass die Zeit im Kontingent abgelaufen ist und dass er, wenn er möchte, dass er die Sprint-Verpflichtung einhält, entscheiden muss, ob er dies wünscht , oder laufe nach täglichen Problemen weiter und gib einen gewissen Wert aus dem Sprint heraus.
Es hat immer funktioniert, ein fairer Deal zu sein; -)
Wir verwenden es für Folgendes: Bug und Wartung des Live-Produkts (5-15%), Vorbereitung des bevorstehenden Sprints (10%) ...
HTH
Wer kümmert sich um die Unterstützung für den Code, den Sie in Produktion bringen? Wenn Ihr Team Supportanfragen bearbeitet, fallen diese Tippfehler und andere kosmetische Probleme in diese Kategorie und werden entsprechend behandelt. Wenn nicht, dann muss der gelegentliche Sprint vielleicht wie ein "Flick" -Sprint sein, bei dem keine neue Funktionalität hinzugefügt wird, aber viele alte Dinge behoben sind und technische Schulden auf ein vernünftiges Maß reduziert werden. Oder kombinieren Sie einen Bug der kleinen Bugs in eine Geschichte von "Fixing alle Tippfehler auf der Website" für eine Idee.
Wenn Sie sich bei "technischen Schulden" anmelden oder "zerbrochene Fenster" mit Scrum, um zu sehen, wie andere mit diesen Dingen umgehen, gibt es vielleicht noch andere Ideen.