Wie werden Aufgaben, die nicht in einen Sprint passen, in Scrum gehandhabt?
Ich sehe den Vorteil darin, in jedem Sprint einen inkrementellen Wert zu liefern, aber ich sehe nicht, wie alle Aufgaben so reduziert werden können, dass sie nicht länger als ein oder zwei Wochen dauern (und ich nehme an, eine einzelne Story in einem Sprint ist ein Antimuster).
Betrachten Sie die folgenden Aufgaben:
Jede dieser Aufgaben kann für ein oder mehrere Teammitglieder wochenlang den größten Teil der Zeit in Anspruch nehmen. Jede vernünftige Definition of Done, die in einer Woche erreicht werden kann, wird keinen zusätzlichen Wert liefern.
In Kapitel 8 von „Scrum: The Art of Doing Twice the Work in Half the Time“ schreibt Jeff Sutherland:
Es kann schwierig sein, sich inkrementelle Veröffentlichungen [...] vorzustellen, die keinen [...] Wert zu haben scheinen, bis sie vollständig sind
[...]
Versuchen Sie zu denken ... Was ist das absolut Mindeste, was ich aufbauen und einem Kunden dennoch einen Mehrwert bieten kann?
Ich bin der Meinung, dass einige Teile der von mir gebauten Systeme zwar einen enormen Wert bieten, aber nicht in kleinen Schritten geliefert werden können.
Wie passen solche Aufgaben in Scrum?
(Obwohl ich den Begriff Aufgabe verwendet habe, denke ich, dass „Story“ für Scrum eher markentypisch wäre, obwohl meiner Meinung nach das Konzept der Geschichten eine Hilfe ist, um Aufgaben zu kommunizieren. Auch wenn Sie argumentieren möchten, dass meine Beispiele Epics sind , oder etwas anderes, behaupte ich, dass sie dem Projekt keinen kleinen zusätzlichen Wert verleihen)
Bearbeiten Sie als Antwort auf Thomas Owens
Ich bin auch nicht davon überzeugt, dass jede Arbeit groß ist oder nicht auf etwas reduziert werden kann, das innerhalb eines Sprints erledigt werden kann.
Das ist die Antwort auf die Frage, die ich hätte stellen sollen. So wie ich Scrum verstehe, muss jede Aufgabe klein genug sein, um in einen Sprint aufgenommen zu werden, und immer einen inkrementellen Wert liefern.
Das ist meiner Erfahrung nach nicht möglich. Es scheint auch eine sehr starke Behauptung zu sein. Ich arbeite hauptsächlich an eingebetteten Systemen, und meiner Erfahrung nach treten solche lang laufenden Aufgaben eher auf der eingebetteten Seite von IoT-Systemen als in der Cloud oder im Frontend auf.
Ich werde erwägen, eine spezifischere Frage für einen bestimmten Fall zu formulieren, obwohl es für mich schwierig ist, sicherzustellen, dass ich keine privilegierten Informationen preisgebe. Dies scheint ein spezifischeres Beispiel zu sein, bei dem ich annehmen würde, dass es schwierig wäre, jeden Wert in kleinen Schritten bereitzustellen.
Ich bin nicht davon überzeugt, dass das, was Sie beschreiben, zum Begriff "große, nicht reduzierbare Aufgaben" passt. Bisher bin ich auch nicht davon überzeugt, dass eine Arbeit groß ist oder nicht auf etwas reduziert werden kann, das innerhalb eines Sprints erledigt werden kann.
Behebung eines kritischen Fehlers, der schwer zu lokalisieren und zu beheben ist
Die Schritte hier sind ziemlich einfach: Holen Sie sich Reproduktionsschritte. Reproduzieren in einer Entwicklungs-/Testumgebung. Schreiben Sie fehlgeschlagene Testfälle. Fix. Stellen Sie den Fix in einer Testumgebung bereit und überprüfen Sie ihn. In der Produktion bereitstellen.
Ich erinnere mich an einen kritischen Fehler, der wegen fehlender Protokollierung schwer zu beheben war. Die Reproduktionsschritte waren vorhanden, aber unter bestimmten Bedingungen haben sie den Fehler nicht reproduziert. Daher haben wir durch Protokollierung zusätzliche Beobachtbarkeit in der Produktionsumgebung bereitgestellt. Da die Überwachung und Protokollierung der Anwendungsleistung an einen zentralen Dienst gingen, konnten wir warten, bis es erneut fehlschlug, und es dann wirklich lösen.
Nur weil ein Fehler kritisch ist, bedeutet das nicht, dass Sie ihn sofort beheben können. Der nächstmögliche Schritt in Richtung einer Lösung sollte wahrscheinlich das Wichtigste sein, was Sie tun, aber manchmal müssen Sie sich auf das Sammeln von Informationen vorbereiten, auf die Informationen warten und dann fortfahren. Definieren Sie die Arbeit zur Verbesserung der Beobachtbarkeit im System, liefern Sie diese und fahren Sie dann mit der eigentlichen Fehlerbehebung fort, wenn Sie können.
Follow-up mit einem externen Partner während einer Sicherheits- oder Sicherheitsüberprüfung
Ich sehe nicht, wie groß das ist. Sie senden eine E-Mail oder telefonieren. Basierend auf den Ergebnissen kann es zu Iterationen kommen. Möglicherweise hat die Sicherheitsüberprüfung Probleme ergeben. Verfolgen Sie jeden Schritt. Es ist wichtig, sich darüber im Klaren zu sein, dass diese Art von Arbeit externe Abhängigkeiten hat und diese möglicherweise nicht im selben Takt wie das Team sind, das die Arbeit erledigt. Aber Sie können die Arbeit in kleinere Stücke zerlegen.
Ersetzen einer handelsüblichen Komponente durch eine selbstgebaute Komponente, nachdem die selbstgebaute Komponente die Parität erreicht hat
Es ist möglicherweise nicht möglich oder wünschenswert, dies in Teilen zu liefern, aber die Arbeit kann schrittweise entworfen, entwickelt, integriert und demonstriert werden. Dies ist eine gute Gelegenheit für eine risikobasierte Priorisierung der Arbeit. Finden Sie den Ersatz, der das größte Risiko oder die größte Unsicherheit mit sich bringt, tun Sie dies zuerst und bauen Sie Vertrauen auf, dass Ihr Ersatz funktionieren wird.
Einige Leute mögen argumentieren, dass dies kein „echtes Scrum“ ist, aber es gibt mehrere Aspekte von Scrum, die nicht immer mit realen Kontextsituationen übereinstimmen.
Die Implementierung einer Funktion, die aus Sicht des Benutzers so einfach wie ein einziger Tastendruck erscheinen mag, obwohl eine bloße Minimalimplementierung, die die vom Benutzer beabsichtigte Aufgabe ausführt, sehr komplex ist
Ich müsste mehr über den Kontext verstehen, aber ich war oft in der Lage, diese in dünne End-to-End-Stücke zu schneiden. Dies ist jedoch eine gute Gelegenheit für Feature-Flags. Einige dünne Schnitte ermöglichen möglicherweise keine volle Robustheit oder Fehlerbehandlung. In der Lage zu sein, die Funktionalität in dünnen Scheiben zu implementieren, die Funktionalität in Demo- und Testumgebungen zu aktivieren, um Feedback zu erhalten, während sichergestellt wird, dass sie in den Rest des Systems integriert ist, und die Funktion dann zu aktivieren, wenn sie ausreichend robust ist, ist eine gute Strategie.
Benutzer1380
Thomas Owens