Pivotal Tracker Chore: Sollen Hausarbeiten geschätzt werden oder nicht?

Um einen Hintergrund zu geben: Wir sind ein Web-Automobilunternehmen mit einem Portal für Neu- und Gebrauchtwagen, so etwas wie Autotrader USA

Wir haben viele technische Schulden, die anstehen, z. B. die Umstellung unserer Seiten auf eine neue Backend-Technologie, die Aktualisierung der Versionen verschiedener Open-Source-Module, die wir integriert haben, die Modularisierung des Javascript usw.

Das Problem ist, sollen wir diesen Punkte geben oder nicht?

Warum das Team einen Punkt für Hausarbeiten will:

  1. Es gibt eine Menge Legacy-Code, der laut Team jetzt als Feature betrachtet werden sollte, da die Mehrheit der Teammitglieder zu dem Zeitpunkt, als dieser Legacy-Code in Produktion ging, nie gearbeitet hat.
  2. Sie sagen, Velocity misst, "wie schnell das Team liefert", warum sollten wir Dinge wie die Erforschung neuer Technologien wie ein Unit-Testing-Framework oder ein neues UI-Framework wie React, das Upgrade bestehender Software auf höhere Versionen, den Wechsel zu besserer Technologie nicht in die Velocity des Teams einbeziehen, sind diese Dinge in der schnelllebigen technischen Welt nicht würdig genug?
  3. Oft schlägt PO vor, eher eine Abkürzung als einen idealen technischen Ansatz zu wählen, entweder aufgrund des geschäftlichen Drucks oder um schnell die Ergebnisse zu sehen. Wenn das Experiment erfolgreich ist, muss das Gleiche in der richtigen Weise durchgeführt werden. Das ist technische Schuld, warum sollten wir das nicht in der Geschwindigkeit zählen?
  4. Freigabeprozess automatisieren – dies wirkt sich nicht auf das Leben der Kunden aus, daher sollte es idealerweise eine lästige Pflicht sein. Aber es spart dem Team Zeit und Kopfschmerzen. Warum sollten wir keine Punkte dafür geben?

Warum es keine Punkte geben sollte:

  1. Ich glaube, wenn das Team schlau genug ist, von Zeit zu Zeit die richtigen Aufgaben auszuwählen, würde sich dies automatisch in zukünftigen Sprints in der Geschwindigkeit zeigen. Wenn sie beispielsweise anfangen, ein Unit-Testing-Framework zu verwenden (als lästige Pflicht ohne Punkte), würde es in Zukunft weniger Fehler geben und das Team könnte mehr liefern.
  2. Wenn ein Team in den nächsten 3 Monaten 300 Punkte liefern muss und PO im ersten Monat um die Bereinigung technischer Schulden bittet, würde das Team im ersten Monat 0 Punkte liefern. Aber das Team sollte Geschichten auswählen, die alle technischen Hürden überwinden würden, damit das Team jetzt in den nächsten 2 Monaten 300 Punkte liefern kann. Dies würde das Team dazu motivieren, die auf das Geschäft ausgerichteten technischen Schulden auszuwählen und nicht zufällige Dinge, um ihren Lebenslauf zu dekorieren.
Wie unterscheidet sich Ihre Frage von Warum rät Pivotal Tracker davon ab, Punkte für Fehler und Aufgaben zu schätzen? , und warum hilft diese Antwort in Ihrer Situation nicht?
@CodeGnome: Die akzeptierte Antwort in diesem Thread behandelt nur Fehler. Meine Frage bezieht sich nur auf die Hausarbeit und ich habe dafür mehrere Situationen angegeben.

Antworten (2)

Die einfache Antwort wäre, wenn das Team an einem Element arbeitet, sollte es geschätzt werden. Wenn der PO beispielsweise beschließt, einen Sprint für technische Schulden durchzuführen, bei dem keine neuen Funktionen angesprochen werden, warum sollte es am Ende des Sprints keine Geschwindigkeit für diesen Sprint geben, wenn Software veröffentlicht wurde?

Arbeit ist schließlich Arbeit.

Das einzige Problem entsteht, wenn ein technisches Team auf eine neue Technologie upgraden möchte ... aber der PO sieht den Wert darin nicht. Es ist manchmal in Ordnung, alten Code auszuführen, solange die zugrunde liegenden Geschäftsprozesse ausgeführt werden und Geschäftswert generieren. (Und die Wartung ist nicht übermäßig)

Also würde ich die Aufgaben bemessen, es spiegelt besser wider, was das Team während eines Sprints tatsächlich tut.

Es gibt eine Denkschule, die sagt:

Schätzen Sie nicht Bugfixes, Aufgaben und Spikes.

Denn Punkte sollten nur für Arbeiten vergeben werden, die einen Mehrwert für das Unternehmen darstellen.

Entwickler sollten einen Anreiz erhalten, die wertvollste Arbeit zu vollenden. Sie erhalten Lob für das Abbrennen von Story Points, weil diese Storys einen direkten Geschäftswert darstellen.

Im Gegensatz dazu werden sie ermutigt, Fehlerkorrekturen, Aufgaben und Spikes so schnell wie möglich abzuschließen, da diese Aktivitäten keinen direkten Mehrwert bringen und sie nicht so viel Anerkennung für die Erledigung dieser Art von Arbeit erhalten.

Es soll eine gesunde Spannung zwischen dem Unternehmen und den Entwicklern geben, und dieses System formalisiert sie.

Quellen:

Pivotal Tracker Chore: Sollen Hausarbeiten geschätzt werden oder nicht?
AntwortenHierDatenschutz-Bestimmungen1y, 0v