Behandeln von "verwandten" Arbeiten innerhalb eines einzelnen agilen Arbeitselements

Ich bin in einem Projektteam von 4 Entwicklern, auch ich. Wir haben lange darüber diskutiert, wie mit zusätzlicher Arbeit umgegangen werden soll, die im Verlauf eines einzelnen Arbeitselements anfällt.

Diese zusätzliche Arbeit ist normalerweise etwas, das etwas mit der Aufgabe zu tun hat, aber nicht immer notwendig ist, um das Ziel des Gegenstands zu erreichen (das kann eine Meinung sein). Beispiele umfassen, sind aber nicht beschränkt auf:

• Refactoring des durch das Workitem geänderten Codes
• Refactoring-Code neben dem vom Artikel geänderten Code
• Neugestaltung des größeren Codebereichs um das Ticket. Wenn Sie beispielsweise für ein Element eine einzelne Funktion ändern, erkennen Sie, dass die gesamte Klasse jetzt erneuert werden kann, um diese Änderung besser zu berücksichtigen.
• Verbessern der Benutzeroberfläche in einem Formular, das Sie gerade geändert haben

Wenn diese zusätzliche Arbeit klein ist, macht es uns nichts aus. Das Problem besteht darin, dass diese zusätzliche Arbeit eine wesentliche Erweiterung des Elements über die ursprüngliche Merkmalspunktschätzung hinaus verursacht. Manchmal benötigt ein 5-Punkte-Gegenstand tatsächlich 13 Zeitpunkte. In einem Fall hatten wir einen Punkt mit 13 Punkten, der im Nachhinein 80 Punkte oder mehr hätte betragen können.

In unserer Diskussion gibt es zwei Möglichkeiten, wie wir damit umgehen sollen.

1. Wir können die zusätzliche Arbeit im selben Arbeitselement akzeptieren und als Fehleinschätzung abschreiben. Zu den Argumenten hierfür gehörten:

   • Wir planen, am Ende des Sprints "aufzufüllen", um dies zu berücksichtigen.
   • Lassen Sie den Code immer in einem besseren Zustand als Sie ihn gefunden haben. Checken Sie keine halbherzigen Arbeiten ein.
   • Wenn wir das Refactoring für später verlassen, ist es schwierig zu planen und wird möglicherweise nie fertig.
   • Sie befinden sich jetzt im besten mentalen "Kontext", um diese Arbeit zu erledigen, da Sie bereits hüfthoch im Code sind. Es ist besser, es jetzt aus dem Weg zu räumen und effizienter zu sein, als diesen Kontext zu verlieren, wenn Sie später wiederkommen.

2. Wir ziehen eine Linie für das aktuelle Arbeitselement und sagen, dass die zusätzliche Arbeit in ein separates Ticket fließt. Argumente umfassen:

   • Ein separates Ticket ermöglicht eine neue Schätzung, sodass wir uns nicht selbst belügen, wie viele Punkte die Dinge wirklich sind, oder zugeben müssen, dass alle unsere Schätzungen schrecklich sind.
   • Das Sprint "Padding" ist für unerwartete technische Herausforderungen gedacht, die direkte Hindernisse für die Erfüllung der Ticketanforderungen darstellen. Es ist nicht für Beilagen gedacht, die nur "nett zu haben" sind.
   • Wenn Sie das Refactoring planen möchten, platzieren Sie es einfach oben im Backlog.
   • Es gibt keine Möglichkeit für uns, dieses Zeug in einer Schätzung richtig zu berücksichtigen, da es etwas willkürlich erscheint, wenn es auftaucht. Ein Code-Prüfer könnte sagen: "Diese UI-Steuerelemente (die Sie in diesem Arbeitselement nicht geändert haben) sind etwas verwirrend. Können Sie das auch beheben?" Das ist wie eine Stunde, aber sie könnten sagen: "Nun, wenn dieses Steuerelement jetzt von derselben Basisklasse wie die anderen erbt, warum verschieben Sie nicht all diesen (Hunderte von Zeilen) Code in die Basis und verdrahten all dieses Zeug neu." , die kaskadierenden Änderungen usw.? " Und das dauert eine Woche.
   • Es "kontaminiert den Tatort", indem es dem Ticket nicht verwandte Arbeiten hinzufügt, wodurch unsere ursprünglichen Feature-Point-Schätzungen bedeutungslos werden.
   • In einigen Fällen verschiebt die zusätzliche Arbeit das Einchecken und führt zu einer Blockierung zwischen den Entwicklern.

Einige von uns sagen jetzt, dass wir uns für einen Cut-Off entscheiden sollten. Wenn das zusätzliche Material weniger als 2 FP beträgt, geht es in dasselbe Ticket. Wenn es mehr ist, machen Sie es zu einem neuen Ticket.

Da wir erst ein paar Monate mit Agile beschäftigt sind, wie beurteilen all die erfahreneren Agile-Veteranen hier, wie sie damit umgehen sollen?

Agile Planung und User Stories konzentrieren sich darauf, den Projektbeteiligten und Benutzern der Software Wert und Transparenz zu bieten. Dies ist eine gute Sache, aber sie sollte und sollte die Bedeutung guter architektonischer Richtlinien, Designverantwortung, guter Entwicklungspraktiken und der Aufrechterhaltung technischer Schulden nicht ersetzen, einschließen oder herabstufen.

Letzteres macht Agile nicht gut, weil es nicht als Antwort auf diese meist technischen Probleme und Probleme gedacht war.

Zu wissen, dass ich überhaupt nicht damit einverstanden bin, dass Refactoring-Aufgaben, technische Schuldenabwicklung und Designarbeiten separate User Stories in einem bestimmten Sprint berücksichtigen sollten. Dies sind lediglich Aufgaben, die ein Entwickler möglicherweise übernimmt, um die User Story für diesen Sprint zu erfüllen.

Denken Sie daran, dass eine Aufgabe eine Einheit zuweisbarer Arbeit ist, die dazu beiträgt, eine bestimmte User Story innerhalb der Architekturrichtlinien zum Abschluss zu bringen und die guten Design- und Entwicklungspraktiken der gesamten Software beizubehalten.

Aus diesem Grund sollte sich die Stundenschätzung auf Aufgaben und nicht auf User Stories beziehen. Aus diesem Grund sind einige Aufgaben für die Fertigstellung mehrerer User Stories von entscheidender Bedeutung.

Rot, Grün, Refactor. Das ist der Umfang eines einzelnen Arbeitselements. Schreiben Sie eine fehlerhafte Testsuite, die den Umfang der Änderungen abdeckt, codieren Sie die erforderliche Mindestmenge, um Ihren Test zu bestehen, und überarbeiten Sie sie dann, um die Codierungsstandards zu erfüllen, während Sie die Tests noch bestehen. Alle drei Schritte sind erforderlich. Sie können die Lösung erst codieren, wenn Sie das Problem definiert haben. Wenn Sie beim Schreiben der Codezeile einen Refactor durchführen, verstoßen Sie ausnahmslos gegen YAGNI. Wenn Sie jedoch nach dem Bestehen der Tests nicht hinter sich und Refactor treten, entstehen Ihnen per Definition technische Schulden dass Sie irgendwann zurückzahlen müssen.

Angesichts dieser Definition und der Befolgung war ein 5-Zeiger, der sich als 13-Zeiger herausstellte, eine Fehleinschätzung. Was Sie als Refactoring betrachten würden, war wahrscheinlich eher eine Umstrukturierung. Sie mussten einen ziemlich wichtigen Bereich der Codebasis neu organisieren, damit die neue Funktionalität auf verständliche und wartbare Weise aufgenommen werden konnte. Dies deutet normalerweise darauf hin, dass das Team den allgemeinen zukünftigen Entwicklungspfad nicht verstanden hat, was dazu führt, dass etwas sehr einfach in einer vorherigen Iteration implementiert wird, wenn es schließlich sehr fest sein müsste. Eine bessere Kommunikation zwischen den BAs und PM, die wissen, was sich weiter unten im Rückstand befindet, und dem Entwicklungsteam, das sich im Allgemeinen auf den aktuellen Sprint konzentriert, kann dies abmildern. Alternativ enthüllte diese Geschichte eine große Menge an technischen Schulden, die in der Vergangenheit entstanden sind. und es hat einfach das Team eingeholt. Bessere Codeüberprüfungsprozesse sowie eine bessere konzeptionelle Kenntnis der Entwurfsmuster und des allgemeinen zukünftigen Projektverlaufs können dazu beitragen, solche Vorkommnisse zu reduzieren.

Eine Sache zu beachten ist, dass Refactoring "nicht ideale" Arbeit ist. In Agile SCRUM werden Aufgaben in "idealen Stunden" geschätzt. Das heißt, die Anzahl der Stunden, die mit dem Head-Down-Schreiben von brandneuem Code verbracht wurden, der nie existiert hat, und die Funktionsbasis des Projekts fördert. Ein 8-Stunden-Entwicklertag kann realistisch gesehen nur 5 ideale Stunden haben. Manchmal kann man sich auf 6 verlassen, besonders in der "Strecke" eines Projekts, in dem das Team wirklich mitsummt. Refactoring oder das Zurückgehen und Vornehmen von Änderungen, die sich nicht auf die Funktionalität des Projekts auswirken, aber die Codebasis auf andere Weise verbessern, sind keine ideale Arbeit, ebenso wie Planung, Design, Kommunikation, Überprüfung, Pausen oder technische Ausfallzeiten. Abgesehen von technischen Ausfallzeiten ist eine nicht ideale Arbeit wichtig, macht jedoch in den Augen des Produktbesitzers keine Fortschritte.

Vorausgesetzt, dass das Refactoring nicht die tatsächlich aufgewendeten Stunden verdoppelt, ist eine gewisse Menge an Refactoring-Arbeit zu erwarten, wenn Sie die idealen Stunden schätzen. Nehmen wir an, weil ich nicht genau weiß, wie die Punkteskala Ihres Teams kalibriert ist, entspricht ein 5-Zeiger einer idealen Entwicklerwoche oder etwa 25 idealen Stunden. Diese 5, die sich in eine 13 verwandelte (mehr als zwei Entwicklerwochen in derselben Größenordnung), ist Anlass für eine Rückschau darauf, was die Komplexität in die Höhe getrieben hat. Vielleicht musste die Codebasis nicht so viel umgestaltet werden, wie tatsächlich durchgeführt wurde, vielleicht hatte sich eine große Menge technischer Schulden angehäuft, ohne dass das Team es wusste, das gelöst werden musste, damit die neuen Funktionen funktionierten.

Stellen wir uns in einem alternativen Universum vor, dass aus einer 5, die in idealen Stunden geschätzt wird, eine 7 (~ 35 Stunden) basierend auf den tatsächlichen Stunden wird, da Sie 10 Stunden zusätzliches Refactoring benötigten, um den neuen Code und einige vorherige Bits in ein richtig strukturiertes Muster zu setzen Design Architektur. In diesem Fall liegt das Extra innerhalb der "Lücke" zwischen idealen und Gesamtstunden während der Anzahl der Entwicklertage, die die Geschichte dauern sollte. Als Projektmanager würde ich eine 5, die zu einer 7 wurde, als vernünftige Schätzung bezeichnen und weitermachen.

Story Points sind eine Schätzung der relativen Komplexität einer bestimmten User Story. Es hört sich so an, als würden Sie Story Points verwenden, um zu sagen, dass dies X Mann Tage / Stunden dauern wird. Streben Sie stattdessen zwei Ziele an

1. Teilen Sie Geschichten auf, bis sie in einem konsistenten Bereich liegen (3, 5 oder 8 Punkte).
2. Angenommen, die Geschichte enthält alle erforderlichen Umgestaltungen

Mit der Zeit erhalten Sie eine Basis für die Geschwindigkeit. Jede 5-Punkte-Story benötigt nicht die gleiche Zeit wie die anderen, aber die durchschnittliche Geschwindigkeit pro Sprint (wie viele Story-Punkte das Team erreichen kann) ist konstant.

Sich Sorgen darüber zu machen, wie viel Zeit eine bestimmte Geschichte in Anspruch nehmen wird, ist kontraproduktiv. Die Schätzungen werden nur über das Volumen von Storys mit gleichbleibender Größe gemittelt (IE one 5-Zeiger können aufgrund von Refactoring etwas länger dauern, aber Sie nutzen den Vorteil dieser Bemühungen für ein verwandtes Storys).

Es sollte einen relativen Grenzwert dafür geben, wie viel sich im ursprünglichen Arbeitselement befindet und wie viel sich in etwas anderem befindet. User Stories sind Ausgangspunkte für Diskussionen und daher gibt es möglicherweise alle Arten von Scope-Elementen, die während eines Sprints während der Arbeit an einer Story festgenagelt werden müssen.

Es kann vorkommen, dass bei einer Sprint-Planung einer Story zusätzliche Kriterien hinzugefügt werden, um ein "Scope Creep" zu vermeiden, das auftreten kann, wenn ein Benutzer ein neues Formular wünscht und dann 101 zu diesem Formular wechselt, für das dies nicht realistisch ist Erledige manchmal einen 2-wöchigen Sprint.

Eine Kehrseite ist, wie viel Wert durch diese zusätzliche Arbeit gewonnen wird. Möglicherweise gibt es Unmengen möglicher Umgestaltungen, die durchgeführt werden könnten, aber wie viel Nutzen bringt es für all diese Arbeiten? Hier müssen einige Richtlinien vorhanden sein, damit das Team gut funktioniert, aber nicht verloren geht, wenn versucht wird, den Code perfekt zu machen.