Wie verwaltet man sehr kleine, einfache Aufgaben in Agile?

Angenommen, Sie haben einen Fehler auf Ihrer Website. Ihr Entwickler muss etwas CSS oder so etwas reparieren. Er schätzt, dass er eine Minute brauchen wird, um es zu reparieren.

Wie bewältigt man solche Aufgaben am besten? Erstellen Sie eine User Story dafür und erstellen Sie eine Aufgabe dafür? Die Aufgabe ist so winzig und winzig, dass es eigentlich mehr Arbeit ist, Geschichten und Aufgaben dafür zu erstellen, als sie tatsächlich zu erledigen. Dies scheint sehr ineffizient zu sein, obwohl es wichtig ist, die Entwicklung kleiner Korrekturen zu verfolgen und zu verwalten.

Wie gehen Sie am besten mit kleinen, einmaligen Aufgaben um, die nicht lange dauern?

Antworten (8)

TL;DR

Selbst wenn die Änderung scheinbar geringfügig ist, kann sie Auswirkungen haben. Die „Ein-Minuten-Korrektur“ für eine CSS-Klasse kann sich auf die Benutzeroberfläche (UI) auf einer anderen Seite auswirken, an die der Entwickler nicht denkt, oder wichtige Regressionstests beeinträchtigen. Das ist die eigentliche Definition von Cowboy-Codierung.

Noch wichtiger ist, dass das Umgehen des vereinbarten Arbeitsablaufs ein Rezept für Produktivitätsverluste ist, wodurch unsichtbare Arbeit das Projekt bremst und die Gesamtproduktqualität verringert. „Nur dieses eine Mal“ schafft technische Schulden, aber eine Kultur des „Nur dieses eine Mal“ wird Ihren Prozess schließlich unterbrechen. Lassen Sie das nicht zu.

Keine unsichtbare Arbeit, niemals

Nehmen wir an, Sie haben einen Fehler auf Ihrer Website. Ihr Entwickler muss etwas CSS oder so etwas reparieren. Er schätzt, dass er 1 Minute brauchen wird, um das Problem zu beheben.

Dein Entwickler liegt falsch. Es kann so einfach zu beheben sein oder nicht, wie er denkt – Entwickler sind dafür bekannt, Aufgaben zu unterschätzen, besonders wenn sie nicht darüber nachdenken, wie „kleine“ Änderungen andere Dinge im System beeinflussen könnten – aber jede Aufgabe trägt die reale Welt Gemeinkosten wie:

  1. Task-Switching-Overhead. Die Wissenschaft sagt uns, dass Unterbrechungen oft durchschnittlich 23 Minuten und 15 Sekunden benötigen , bis der Ausführende der Aufgabe wieder in Fluss kommt.

  2. Prozess-Overhead wie Refactoring, Unit-Tests, Integrationstests und Regressionstests.

  3. Anderer Prozessaufwand im Zusammenhang mit Ihrer Definition of Done, einschließlich (aber nicht beschränkt auf):

    • Peer-Review

    • Kontinuierliche Integration (CI)

    • Benutzerakzeptanztests (UAT)

  4. Overhead-Arbeitsverfolgung, die unerlässlich ist, um sicherzustellen, dass es niemals unsichtbare Arbeit gibt .

Am wichtigsten ist vielleicht, dass dem aktuellen Sprint niemals ungeplante Arbeit hinzugefügt werden sollte. Einige Teams handhaben dies, indem sie Kapazitäten für ungeplante Arbeiten reservieren oder eine generische „Minor Bugs“-Story haben, aber die Best Practice besteht darin, sicherzustellen, dass alle nicht kritischen Bugs vom Product Owner in einem zukünftigen Sprint priorisiert werden.

Winzigen Geschichten können Story-Point-Größen von 0 oder 1/2 zugewiesen werden, oder sie werden mit anderen kleineren Fehlern in einen Topf geworfen. Ich bin eher ein Fan davon, Geschichten in einen Topf zu werfen als Null-Punkt-Geschichten, aus dem einfachen Grund, dass keine Arbeit jemals wirklich „kostenlos“ ist und die Kosten für ein Dutzend Null-Punkt-Geschichten definitiv nicht null sind.

Wenn Sie die Lumping-Technik verwenden, könnte Ihr nächster Sprint „Ausstehende CSS-Fehler beheben, die in Jira protokolliert wurden“ als Product Backlog Item (PBI) enthalten, dessen Größe der Anzahl und Komplexität der Fehler und dem damit verbundenen Aufwand für deren Test entspricht . Sofern Cowboy-Programmierung kein Projektziel ist, sollten selbst „geringfügige“ Änderungen dieselbe Entwicklungs-/Testpipeline durchlaufen wie jede andere Änderung, um die Produktqualität aufrechtzuerhalten und technische Schulden zu vermeiden.

Betreff: "Task-Switching-Overhead" - was ist, wenn der Entwickler bereits unterbrochen wurde? Bsp.: Wir haben einen Slack-Channel und dort werden Prod-Fehler ausgespuckt. Ich sehe einen Prod-Fehler und bin daher bereits unterbrochen und habe nicht genügend Informationen, um das Problem zu diagnostizieren, da die Protokollierung in diesem Codebereich schwach ist. Ich möchte eine Codeänderung vornehmen, um eine robustere Protokollierung hinzuzufügen. Jetzt muss ich ein Ticket mit dem Titel „Protokollierung hinzufügen“ einreichen, es schätzen lassen, ein Gespräch mit dem Team führen, um es einzuziehen, die Änderung vornehmen, die Bereitstellung durchlaufen usw., und das alles für eine buchstäblich einzeilige Änderung extrem geringes Risiko?

Solche Sachen sollten in der Arbeitsvereinbarung des Teams stehen. Es gibt keine richtige Antwort darauf, wie man mit der Situation umgeht, aber es gibt Vor- und Nachteile beim Erstellen der Geschichte/des Fehlers und/oder der zugrunde liegenden Aufgabe.

Vorteile: Schafft Sichtbarkeit für den Rest des Teams Hinterlässt ein Artefakt, dass die Arbeit erledigt wurde

Nachteile: Verwaltungsaufwand im Zusammenhang mit der Erstellung/Verwaltung des Artefakts.

Als Faustregel gilt:

Je weniger ausgereift das Team ist, desto besser ist es, es dazu zu bringen, Artefakte für all die Arbeit zu erstellen, die es erledigt, egal ob es sich um 5 Minuten oder 5 Tage handelt. Dies trägt dazu bei, Disziplin zu schaffen und die Transparenz zu fördern, während sich das Team bildet.

Je reifer das Team ist, desto akzeptabler wird es, Arbeiten, die nur wenige Minuten dauern, unter dem Radar verschwinden zu lassen. Das Team hat möglicherweise eine Arbeitsvereinbarung, dass für Arbeiten von weniger als X Minuten keine Karte erforderlich ist. Ausgereifte Teams sollten in der Lage sein, über diese Elemente zu kommunizieren und zurückzublicken (wenn sie häufig genug auftreten, um Bedenken zu rechtfertigen), ohne dass sie in jedem Fall ein Artefakt benötigen, auf das sie sich beziehen können.

Es hängt also wirklich von den Problemen ab, die Sie lösen möchten, ob die Arbeit explizit verfolgt wird oder nicht.

Die meisten Teams, mit denen ich zusammengearbeitet habe, erstellen eine Karte und geben ihnen eine Größe von 0, hauptsächlich zu Referenz-/Protokollierungszwecken.

Ich würde im Stand-up-Meeting eine Karte dafür erstellen und mit dem Team abschätzen. Wenn es wirklich 1 Minute dauert und es den Fokus der Iteration nicht stört, tun Sie es, aber stören Sie die Entwickler nicht, während sie an etwas anderem arbeiten. Dies macht auch „zusätzliche“ Arbeit sichtbar, die später während der Retrospektive verwendet werden könnte, wenn die Sprintziele nicht erreicht werden, insbesondere wenn es sich um viele kleine Änderungen handelt.

Wenn Sie viele ähnliche triviale Änderungen haben, würde ich sie für die nächste Iteration in einer etwas größeren Gruppe zusammenfassen. Fragen Sie sich, brauchen wir das jetzt wirklich? Denn was wie eine kleine Änderung aussieht, kann etwas größer sein, wenn der Entwickler tatsächlich damit beginnt. Stellen Sie sicher, dass es zeitlich begrenzt ist und verschoben wird, wenn es länger dauert.

Denken Sie daran, dass kleine Änderungen enorme Auswirkungen auf andere Disziplinen im SDLC haben können . Ein einfaches Beispiel könnte sein, dass viele automatisierte Tests aktualisiert oder Übersetzungen angewendet werden müssen. Lesen Sie mehr über die Auswirkungen kleiner 5-Minuten-Codeänderungen bei Microsoft: https://blogs.msdn.microsoft.com/ericlippert/2003/10/28/how-many-microsoft-employees-does-it-take-to-change -eine Glühbirne/

Wie würden Sie viele kleine Aufgaben wie diese gruppieren, wenn sie alle nichts miteinander zu tun haben? Als hätten sie nichts miteinander zu tun. Das sind alles 5-Minuten-Aufgaben, die erledigt werden müssen? Erstellen Sie eine generische User Story mit dem Namen „Allgemeine Aufgaben“ oder so? Das scheint nicht richtig zu sein.
Nicht, wenn sie nicht zusammenhängen, aber ich habe in diesem Fall mehrere kleine CSS-Fehler erwartet. Vielleicht legen Sie die Karten einfach nahe beieinander. Wenn Sie ihm keinen eindeutigen Namen geben können, gruppieren Sie sie nicht. Um ehrlich zu sein, gruppiere ich selten Probleme. Es ist nicht zu viel Aufwand, während einer Planungssitzung viele kleine Aufgaben zu erledigen, da sie einfach und leicht abzuschätzen sind.

Erstellen Sie ein Ticket dafür, gibt dem Rest des Teams Einblick und es bedeutet auch, dass es in den Rückstand gehen kann - es gibt keine Garantie dafür, dass der Entwickler, der es auf nur eine Minute geschätzt hat, dieses Problem an Ort und Stelle behebt - also muss es sein um eine Aufzeichnung davon zu sein - sonst könnte es wieder vergessen werden.

es kann dann sein, dass ein Teammitglied mehrere der winzigen Tickets auf einmal abholt

Ich weiß nicht, ob das hilft, aber ich verwalte agile und Wasserfallprojekte in meiner Organisation. Wir behandeln Fehler separat. Wenn also ein Fehler entdeckt wird, wird er vom Tester in Inflectra Spira gemeldet. Es wird nicht wieder in die User Story eingefügt, sondern einfach als separater Fehler behandelt, der behoben werden muss. Alle Entwickler haben einige Notfallfunktionen eingebaut, um Fehler zu beheben. Bugs sind Teil der Entwicklung und sollten meiner Meinung nach nicht als zusätzliche User Stories in Scrum oder agiles Projektmanagement einfließen. Andernfalls wird das Projekt überlaufen.

Ist Sichtbarkeit durch andere Disziplinen/Personen erforderlich?

  • Wenn ja - Erstellen Sie ein Ticket.
  • Wenn nein - tun Sie es einfach.

Individuen und Interaktionen über Prozesse und Tools

Halte es einfach. Lösen Sie ein Problem nicht zu sehr. Verarbeite nicht um des Prozesses willen.

Wie verwaltet man sehr kleine, einfache Aufgaben in Agile?
AntwortenHierDatenschutz-Bestimmungen1y, 0v