Kann ich eine vertikale Story in horizontale Aufgaben aufteilen?

Mein Team und ich implementieren Scrum in unserem Projekt. Wir befinden uns in der Phase der Aufteilung von User Stories in Aufgaben, die jedem Entwickler zugewiesen werden.

Ich verstehe das Konzept von „Slicing the Cake “, bei dem eine User Story einen vertikalen Schnitt darstellt, der alle technologischen Schichten durchquert (dh von der Benutzeroberfläche über die Middleware bis hin zur Datenbank).

Wenn ich jedoch meine vertikale User Story in Aufgaben unterteile, wird sie in horizontale Ebenen unterteilt. Am Ende weise ich jedem Entwickler eine Aufgabe auf horizontaler Ebene zu: Ein Entwickler würde am Teil der Geschichte mit der Benutzeroberfläche arbeiten, ein anderer an der Middleware und ein dritter an der Datenbank. Daher habe ich das Gefühl, dass ich damit das Konzept des vertikalen Schneidens durchbreche.

Warum weisen Sie dem Team Aufgaben zu, anstatt sie zur Zusammenarbeit an der Arbeit zu ermutigen?
@ToddA.Jacobs was meinst du? Soweit ich in Scrum verstanden habe, weise ich zunächst eine Gruppe von Entwicklern einer User Story zu, damit sie zusammenarbeiten. Aber dann unterteile ich die Geschichte weiter in Aufgaben, und hier bin ich verwirrt darüber, wie Entwickler an einer Geschichte, aber gleichzeitig an verschiedenen Aufgaben arbeiten sollten
Nein. Scrum Teams organisieren sich selbst . Sie kämpfen mit der Implementierung, weil Sie versuchen, Arbeiten zu erledigen, die das Team selbst erledigen sollte.

Antworten (3)

Kurze Antwort: Die Aufgabe besteht darin, dass das Team seine Arbeit so organisiert, wie es ihm am besten erscheint. Wenn das bedeutet, es in Front-End, Middleware und Datenbank aufzuteilen, ist das in Ordnung. Dies ist eigentlich ein normaler Teil des Fortschritts für funktionsübergreifende Teams.

Nur weil wir Leute mit allen Fähigkeiten in dasselbe Team gesteckt haben, heißt das nicht, dass sie diese anderen Fähigkeiten plötzlich kennen. Sie beginnen also mit einer horizontalen Gliederung wie dieser und isolieren wahrscheinlich immer noch bestimmte Arten von Aufgaben mit der Person, die in dieser Sache am geschicktesten ist. Normalerweise findet sich das Team bei dieser Arbeitsweise ziemlich früh in einer Situation wieder, in der es zu viele Aufgaben vom Typ X für das Teammitglied gibt, das dies normalerweise tut, und jemand anderes einspringen und aushelfen muss - normalerweise mit einigen der leichteren Aufgaben. Im Laufe der Zeit werden die Mitarbeiter ein breiteres Spektrum an Fähigkeiten erwerben und anfangen, Stellen zu sehen, an denen das Aufteilen der Aufgaben in horizontale Schichten nicht mehr der beste Weg zu sein scheint.

Die große Falle, auf die Sie achten müssen, ist, wenn das Team in diese Situation gerät und anstatt einzugreifen, um sich gegenseitig zu helfen, der Rest des Teams zu neuen Backlog-Elementen übergeht und Sie am Ende mit einem Haufen von Backlog-Elementen enden hat einen Aufgabentyp darauf. Ich sehe das am häufigsten bei Testaufgaben, aber gelegentlich taucht es auch bei anderen Typen auf.

Ich möchte den Teil hervorheben, in dem das Team seine Arbeit organisiert, es ist nicht die Aufgabe einer einzelnen Person, Geschichten in Aufgaben zu zerlegen.
@Erik könnten Sie bitte den Teil "das Team organisiert seine Arbeit" näher erläutern? Bedeutet das zum Beispiel, dass jeder Entwickler sich aussuchen wird, an welcher Aufgabe er arbeiten möchte? und sollte eine Aufgabe von nur einem Entwickler erledigt werden oder kann eine Aufgabe von mehreren Entwicklern geteilt werden?
@nader bedeutet, dass das Team die Geschichten in Aufgaben aufteilt und dann entscheidet, wie es diese Aufgaben erledigt. Ob sie sie einzeln oder gemeinsam bearbeiten, bleibt ihnen überlassen, welcher Weg ihnen am effektivsten hilft, sie zu vervollständigen. (Technisch gesehen liegt es sogar an ihnen, ob sie sie überhaupt in Aufgaben aufteilen wollen. Das Team ist für die Arbeit verantwortlich.)
@Erik Ja, und das Team ist auch dafür zuständig, zu prüfen, ob ihr derzeitiger „gefundener Weg“ weiterhin der effektivste Weg ist, um Ergebnisse für die Benutzer sicherzustellen. Und das OP (das die Rolle des Scrum Masters übernimmt) ist dafür verantwortlich, das Team dafür zur Rechenschaft zu ziehen.

Ich habe mit meinen Teams festgestellt, dass der schwierige Teil tatsächlich darin besteht, die Geschichten richtig aufzuteilen, nicht die Aufgaben, und ich finde diese Ressource von unschätzbarem Wert:

https://agileforall.com/resources/how-to-split-a-user-story/

  1. Bereiten Sie die Input-Story vor: Ist sie unabhängig, verhandelbar, wertvoll, schätzbar, klein, testbar
  2. Wenden Sie eines der Aufteilungsmuster an: z. B. Schnittstellenvariationen, Geschäftsregelvariationen usw
  3. Bewerten Sie die Aufteilung: sind sie ähnlich groß

Sobald Sie großartige kleine und unabhängige Geschichten haben, ist das Aufteilen dieser Geschichten in technische Aufgaben völlig optional, und einige Entwickler tun es gerne, andere müssen es nicht tun.

Der Punkt, den ich zu machen versuche, ist eher, die Geschichten klein zu halten und sich weniger um die technischen Aufgaben zu kümmern. Sie müssen sicherlich nicht verschiedene Entwickler mit technischen Aufgaben beauftragen.

Entwickler sollten einzeln oder paarweise „Storys“ ziehen und dann herausfinden, was getan werden muss und ob sie Dinge festhalten wollen, während die Aufgaben voranschreiten.

Vertikale Schnitte werden in Aufgaben zerlegt , die für jede Domäne spezifisch und natürlich horizontal sind. Sie verwenden dieses agile Konzept richtig – BOOM!

Das Einzige, was ich vorschlagen würde, wäre, dem Team die Wahl zu überlassen, an welchen Aufgaben es arbeitet. Dies wird Ihrem Team helfen, sachkundiger, effektiver, erfüllter und definitiv agiler zu werden.

Sie müssen Geschichten nicht in horizontale Aufgaben zerlegen – es scheint eine allgemeine Präferenz zu sein, aber keine Voraussetzung.
Kann ich eine vertikale Story in horizontale Aufgaben aufteilen?
AntwortenHierDatenschutz-Bestimmungen1y, 0v