Ich habe schon oft gehört, dass Aufgaben im Grunde Teilmengen von User Storys sind und von User Storys abgeleitet sind, also ist eine Aufgabe in Bezug auf den Arbeitsaufwand, der zu ihrer Fertigstellung erforderlich ist, immer kleiner als eine User Story.
Ich bin jedoch neugierig, ob es Fälle geben könnte, in denen eine Aufgabe nicht von einer User Story abgeleitet ist und daher eine größere Menge an Arbeit enthalten kann als einige User Stories im Product Backlog?
Wird Task immer aus User Story zerlegt?
NEIN.
Aufgaben werden oft von einer User Story getrennt, aber das bedeutet nicht, dass eine Aufgabe nur als Teil von User Storys existieren kann und sie daher immer eine kleinere Größe haben. Aufgaben können eigenständig existieren.
Sie haben die Frage Scrum markiert. User Stories sind keine Scrum-spezifische Sache. Ihr Product Backlog besteht nicht nur aus User Stories. Sie können Epics, Stories, Bugs, Tasks, Spikes oder was auch immer Ihr Produkt braucht haben. Scrum nennt allgemein all diese Product Backlog Items .
Bei der Arbeit mit User Stories ziehen es einige Teams vor, sie in Aufgaben aufzuteilen, aber das ist nicht zwingend, sondern eine Präferenz. Manchmal ist es sogar problematisch, weil sie die Geschichte horizontal in Dinge wie „Erstellen der Datenbankabfragen“, „Erstellen des Backends“, „Erstellen des Frontends“, „Codeüberprüfung“, „Testen“ usw. aufteilen können, was sie erstellen können Entwicklungssilos innerhalb des Teams, anstatt dass alle einen Weg finden, an der Geschichte zusammenzuarbeiten und gleichzeitig die richtige Balance finden, um individuell zu arbeiten. Ich mag es zum Beispiel nicht, Geschichten in Aufgaben aufzuteilen. Einige argumentieren, dass Aufgaben es Ihnen ermöglichen, den Fortschritt innerhalb des Sprints und Ihres Burndown-Diagramms besser zu sehensieht besser aus, aber ich finde das nicht nützlich, denn wenn Sie eine Geschichte in 5 Aufgaben aufgeteilt haben, wenn Sie nur 4 davon erledigen, ist die Geschichte so oder so nicht fertig. Aber ich schweife ab...
Um auf die Aufgabe zurückzukommen , die größer ist als eine Geschichte, ja, es ist möglich . Wie gesagt, eine Aufgabe kann ein Product Backlog Item sein, genau wie eine User Story. Sie könnten einige technische Aufgaben im Backlog haben, die größer sind als einige Storys.
Angenommen, Sie haben eine Geschichte für die Anmeldung. Das Team könnte das in einem halben Tag erledigen. Aber sie haben auch die technische Aufgabe, die Framework-Bibliotheken zu aktualisieren, und einige ihrer Methoden wurden zwischen den Versionen als veraltet markiert. Jetzt muss das Team hier und da kleine Änderungen vornehmen, und das dauert den ganzen Tag. Die Framework-Aufgabe in diesem Beispiel ist doppelt so groß wie die Login-User-Story.
Sie können den Unterschied spüren, indem Sie den Grund für die Existenz der User Story verstehen.
Die User Story stellt den vom Kunden zu liefernden Geschäftswert dar und ist das grundlegende Element im Product Backlog. Die User Story wird in der Phase der Erfassung der Anforderungen geschrieben und später in einen bestimmten Sprint eingefügt, danach muss das Scrum-Team diese Story implementieren. Die Implementierung erfolgt durch Untersuchung der erforderlichen technischen Aufgaben für diese Story.
Ich denke, die Aufgabe ist nur eine Aufgabe, es ist eine technische Aktivität, aber User Story ist ein Benutzerwunsch. Finden Sie mehr Scrum.org
Denken Sie daran: "User(!) Stories" sind genau das ... eine Geschäfts-/Softwareanforderung, ausgedrückt aus der Sicht des Benutzers.
"Benutzer" haben jedoch das volle Recht, "von einem System zu erwarten, dass es 'funktioniert', ohne sich Gedanken darüber zu machen, wie es funktioniert". Sie haben keine Ahnung, wie die Systeme, die sie verwenden, intern aufgebaut sind ... und das sollte auch nie von ihnen erwartet werden. Daher muss es eine Übersetzung von „der benutzerzentrierten Domäne“, ausgedrückt durch eine „Geschichte“, und der „technologiezentrierten Domäne“, die zu ihrer Implementierung erforderlich ist, geben .
Dieser Übersetzungsschritt besteht aus der Formulierung von Aufgaben, Testplänen usw. Alles wird von technischen Experten durchgeführt, die mit dem zugrunde liegenden System bestens vertraut sind. Es wird sicherlich rein technische Erwägungen beinhalten, die "dem Benutzer weder bekannt sind, noch ihn interessieren". Schließlich ist es sein Job, das Auto zu fahren , nicht es zu bauen . Seine „Geschichten“ sind daher lediglich Eingaben.
Der Wert der „User Story“-Idee besteht darin, dass sie danach strebt, die Eingaben des Benutzers den Designern „in ihren eigenen Begriffen“ bereitzustellen. Denn sonst verliert ein Designer sehr leicht die Perspektive des Nutzers aus den Augen. Aber die Idee sollte nie suggerieren, dass der Endbenutzer irgendwie ein technischer Experte für die „Eingeweide“ eines Systems geworden ist.
Daniel
Bankik