Pivotal Tracker rät dringend davon ab, Velocity-Punkte für Bugs und Aufgaben zu schätzen – Sie müssen eine Einstellung ändern und eine Warnung akzeptieren, um dies tun zu können.
Sie erklären hier warum , aber ich verstehe es einfach nicht. Hier ein Auszug:
Indem die Geschwindigkeit nur in Bezug auf Funktionen gemessen wird, kann Tracker abschätzen, wie viel echte, geschäftlich wertvolle Arbeit in zukünftigen Iterationen erledigt werden kann, sodass Sie vorhersagen können, wann Projektmeilensteine erreicht werden könnten
Aufgaben und Bugs brauchen Zeit. Wie kann es Ihnen helfen , wenn Sie dies ignorieren , um vorherzusagen, wann ein Meilenstein erreicht wird?
Angenommen, Sie müssen drei weitere Funktionen abschließen, um zum nächsten Meilenstein zu gelangen, und Sie müssen auch eine Aufgabe abschließen (weil eine der Funktionen nicht gestartet werden kann, bis diese Aufgabe erledigt ist) ... Wie könnte die dafür benötigte Zeit abgezinst werden? hilft Ihnen die Aufgabe einzuschätzen , wann der Meilenstein erreicht wird?
Ich weiß, dass dieser Thread jetzt etwas alt ist, aber als Entwickler bei Pivotal stimme ich keiner der vorhandenen Antworten vollständig zu.
Die Philosophie hinter dem Nichtschätzen von Fehlern ist nicht, dass das Beheben von Fehlern keinen geschäftlichen Nutzen bringt, sondern dass das Einführen eines Fehlers in die App und das anschließende Beheben keine Netto-Fortschrittsdynamik darstellt.
Stellen wir uns beispielsweise vor, dass zwei Teams denselben Funktionssatz auf iOS und Android implementieren. Das iOS-Team hat die Fehler-/Aufgabenschätzung deaktiviert, während das Android-Team sie aktiviert hat.
Die iOS- und Android-Teams schätzen beide die gleiche Geschichte auf 2 Punkte. Beide beenden die Geschichte in der gleichen Zeit, aber in der nächsten Iteration stellt sich heraus, dass die beiden Teams Fehler bei ihrer Implementierung eingeführt haben.
Das iOS-Team hat nur einen Fehler eingeführt. Sie reparieren es in einer Stunde.
Das Android-Team hat drei Bugs eingebracht und weist ihnen jeweils einen Punkt zu. Sie brauchen anderthalb Tage, um sie zu reparieren.
Das iOS-Team bewegt sich schneller als das Android-Team, aber die Geschwindigkeit von Android ist jetzt höher. Dies wirft die Planung zukünftiger Iterationen durcheinander und lässt den Anschein erwecken, als ob sich das Android-Team schneller auf eine brauchbare Veröffentlichung zubewegt, obwohl sie in Wirklichkeit Fehler schneller in ihre Implementierung einführen als das iOS-Team und daher ihre Umsetzung erreichen Ziele langsamer.
Manchmal gibt es jedoch Mängel, die nicht von Ihrem Team eingebracht wurden. Vielleicht ist es eine Legacy-Codebasis, und der Fehler ist so alt wie die Hügel. In diesem Fall macht es keinen Sinn, dass diese Geschichte Ihre Geschwindigkeit verringert, und Sie sollten sie wahrscheinlich als neues Feature und nicht als Fehler in Tracker eintragen.
Natürlich liegt es letztendlich an Ihnen, wie Sie die Story-Schätzung durchführen möchten. Ich habe mit einigen Teams zusammengearbeitet, die die Fehler-/Aufgabenschätzung aktiviert hatten, obwohl ich persönlich es vorziehe, sie deaktiviert zu haben. Tracker wird Sie nicht beurteilen!
Pivotal Labs trifft mit dieser Designentscheidung eine Marketingentscheidung. Indem sie sich auf den „Geschäftswert“ als Schlüsselkennzahl berufen, vernachlässigen sie implizit die Bedeutung der Verfolgung der Teamkapazität oder der Projektplanung im weiteren Sinne.
Eine andere Sichtweise ist, dass sie versuchen, ein Dashboard für Managementziele zu verkaufen, anstatt Iterationsplanung. Die Pivotal Tracker FAQ sagt (Hervorhebung von mir):
Indem die Geschwindigkeit nur in Bezug auf Funktionen gemessen wird, kann Tracker abschätzen, wie viel echte, geschäftlich wertvolle Arbeit in zukünftigen Iterationen erledigt werden kann, sodass Sie vorhersagen können, wann Projektmeilensteine erreicht werden könnten[.]
Ihre Idee ist also, dass Bugs und Hausarbeiten keine "echte" Arbeit sind und keinen Mehrwert bringen. Ich bin anderer Meinung, aber das ist der Punkt, den sie mit ihrer Zielgruppe ansprechen. Sie scheinen auch die Vorstellung abzulehnen, dass Bugs und Aufgaben die Teamkapazität verbrauchen, und gehen davon aus, dass sich die Kosten dieser nicht wertvollen Aufgaben im Laufe der Zeit amortisieren können, sodass sich das Management auf die Festlegung von Zielen für Meilensteine konzentrieren kann.
Sie sagen auch:
Im Gegensatz zu Funktionen treten Bugs und Aufgaben im Laufe der Zeit auf, und obwohl sie ein notwendiger Teil Ihres Projekts sind, können sie als ständige Belastung für den geschäftlich wertvollen Output angesehen werden – als laufende Kosten für die Geschäftstätigkeit.
Mit anderen Worten, anstatt die Kosten von Fehlern und Aufgaben für das Projekt explizit sichtbar zu machen, werden sie nicht berücksichtigt, um ein Management-Dashboard bereitzustellen, das sich mehr auf die Bereitstellung von Funktionen als auf eine kapazitätsbasierte Planung konzentriert. Meiner Meinung nach verhindert dies eine ordnungsgemäße Kontrolle des Projektbudgets und der Teamressourcenbeschränkungen, aber es gibt eindeutig Leute, die anderer Meinung sind.
Um Pivotal Labs gegenüber fair zu sein, erlauben sie Ihnen , diese Fehlfunktion zu deaktivieren. Sie können Fehlern und Hausarbeiten Punkte zuweisen, mit dem Vorbehalt (drohende Warnung?), dass dies eine unumkehrbare Entscheidung für das Projekt ist.
Obwohl davon abgeraten wird, ist es möglich, die Schätzung für Fehler und Aufgaben in den Projekteinstellungen zu aktivieren. Es ist jedoch nicht möglich, diese Einstellung rückgängig zu machen, sobald Ihr Projekt geschätzte Fehler oder Aufgaben aufweist.
Ich persönlich empfehle generell, alle Aufgaben, die gegen das Budget eines Projekts verrechnet werden oder die Teamkapazität verbrauchen, gut sichtbar zu machen und ordnungsgemäß zu verbuchen. Mit Pivotal Tracker haben Sie die Wahl.
Anstatt die genauen Zitate und Links oben für ungültig zu erklären (Sie können wahrscheinlich immer noch das Original in verschiedenen Internetarchiven finden), sind hier die aktualisierten Pivotal Tracker-Links, die mehr oder weniger die gleichen Konzepte enthalten, aber mit unterschiedlichen Formulierungen und aktualisierten Anweisungen zum Ändern des Systems verhält sich von seinen Voreinstellungen.
Ich kenne Pivotal Tracker nicht. Sieht jedoch so aus, als wäre Ihre Frage allgemeiner:
Meiner Meinung nach sollten Sie diese schätzen. Pivotal Tracker scheint die Ansicht zu vertreten, dass nur "Features" den Kunden einen Mehrwert bieten. Ich würde argumentieren, dass das Beheben von Fehlern in der Produktion die Benutzererfahrung verbessert und einen Mehrwert liefert. Siehe hier für mehr. Die Ausnahme hiervon ist, wenn Fehler in abgeschlossenen Geschichten in den Funktions-/Regressionstests oder sogar in den Post-Release-Phasen gefunden werden, sollten sie von den Entwicklern behoben werden, die sie eingeführt haben, ohne dass dafür Punkte gutgeschrieben werden.
Wenn Sie die Leistung, Stabilität oder Sicherheit verbessern, verbessert dies auch die Benutzererfahrung und liefert einen Mehrwert. Siehe hier für mehr.
Indem Sie diese nicht schätzen, kehren Sie sie unter den Teppich und laufen Gefahr, Bugs und technische Schulden anzuhäufen.
Ein weiterer interessanter Punkt ist, dass Sie, um einen Fehler einzuschätzen, verstehen müssen, warum er nicht funktioniert, und das ist normalerweise die längste Arbeit.
Es kann also viel Zeit und Spekulation für die Schätzung in Anspruch nehmen.
Was wir ohne Pivotal Tracker gemacht haben, war das Berechnen und "Durchschnittswert" (basierend auf der Zeit, die zum Beheben des Fehlers benötigt wurde, umgewandelt in Punkte), also würden wir diesen Wert immer Fehlern geben (und manchmal große Unterschiede zur Realität haben, aber Sie kompensieren sich mit der Zeit, da wir den Fehlerwert bei jedem Sprint neu anpassen.
wrhall