it-swarm.com.de

Sollte eine User Story zwischen Entwicklern geteilt werden?

Ich sehe häufig Geschichten, die Back-End- und Front-End-Entwicklung haben. Betrachten Sie beispielsweise einen großen Dialog mit einigen Tabellen und einigen dynamischen Steuerelementen. Wir werden mehrere Geschichten schreiben (vielleicht eine für jeden Tisch und eine für das dynamische Steuerungssystem).

Das Entwicklerteam teilt sich dann mit einer Person im Backend und einer anderen Person im Frontend auf. Dies erleichtert es der Back-End-Person, sich nur um die Struktur der SQL-Ebene zu kümmern, während sich die Front-End-Person auf Dinge wie das Layout konzentriert. Nachdem die anfängliche Schnittstelle zwischen Back- und Front-End vereinbart wurde, können die beiden Entwickler ihre Aufmerksamkeit darauf richten, ihren Teil bis zum Ende des Sprints zu erledigen.

Dann kommt das Chaos. Wem "gehört" welche Geschichte? Was bedeutet "in Bearbeitung" oder "erledigt"? Sollten wir zwei separate Geschichten für Backend und Frontend erstellen? Wenn ja, bricht das nicht die Idee von User Stories, die auf Funktionen basieren? Unser System hat eine Vorstellung von "Unteraufgaben", die einige dieser Probleme lösen. Unteraufgaben erhöhen jedoch die Komplexität. Gibt es einen besseren Weg? Ist dies eine "schlechte" Art, Scrum zu verwenden?

Ich habe in den letzten Jahren an einigen Stellen irgendeine Form von Agile verwendet. Ich habe noch keine offizielle Ausbildung, bitte verzeihen Sie falsche Terminologie oder Ideologie. Ich versuche nur, praktische Wege zu lernen, um unseren Prozess zu verbessern.

21
User1

Eine "Geschichte" wird so genannt, weil sie aus Kundensicht eine vollständige, gut Geschichte darstellt. Ohne das Front-End oder Back-End gibt es keinen Anwendungsfallpfad, den der Kunde ausführen kann.

In Ihrem Fall denke ich, dass sowohl Front-End als auch Back-End eine einzige Geschichte sein sollten. Teilen Sie es in Aufgaben. Die Entwickler besitzen ihre verschiedenen Aufgaben. Diese Aufgaben können einzeln in ihren Phasen verfolgt werden - In Bearbeitung, Codierung abgeschlossen, Modultest abgeschlossen usw.

Stellen Sie sicher, dass Sie QS-zugewiesene Aufgaben in dieselbe Story aufnehmen - ohne Validierung ist eine Story nutzlos. Die Qualitätssicherung testet die durchgängige integrierte Story, die ein Kunde sehen wird. Nur dann sollte die gesamte Geschichte als Fertig markiert werden. In einer idealen agilen Umgebung probiert ein echter Kunde oder ein Kundenproxy die Story auch in einer laufenden Anwendung aus und markiert die Story als akzeptiert, wenn sie die vereinbarten Anforderungen erfüllt.

Wenn Sie schnellere Rückkopplungsschleifen wünschen, versuchen Sie, den Anwendungsfall in kleinere End-to-End-Funktionen zu unterteilen. Anstelle eines Anwendungsfalls wie "Ein Kunde kann Dinge mit einem Einkaufswagen kaufen" teilen Sie ihn beispielsweise in "Ein Kunde kann ein Produkt einem Einkaufswagen hinzufügen" usw. auf. Führen Sie dann jeden kleineren Anwendungsfall aus Ende zu Ende wie oben beschrieben.

EDIT: Ich wollte die obigen Punkte mit einigen Quellen belegen. Die Merkmale einer guten User Story werden mit einem Akronym namens " INVEST " kurz dargestellt. Es wurde von Bill Wake erstellt und von der Scrum-Bewegung populär gemacht. Beachten Sie insbesondere die Elemente in Geschichten, die unabhängig und vertikal sind.

Weitere Informationen hier und hier .

16
metacubed

Wem "gehört" welche Geschichte?

Wer auch immer die Geschichte packt. Der Schlüssel aus organisatorischer Sicht ist eine Person ist für die Arbeit verantwortlich. Sobald Sie zwei Personen haben, ist es zu einfach, das Geld zu geben.

Sollten wir zwei separate Geschichten für Backend und Frontend erstellen? Wenn ja, bricht das nicht die Idee von User Stories, die auf Funktionen basieren?

Es hängt davon ab, ob. Ich habe gesehen, wie beide Wege funktionieren. Wenn die Geschichte groß genug ist, damit zwei Entwickler Vollzeit daran arbeiten können, sollte sie möglicherweise aufgeteilt werden. Wenn die beiden Entwickler Teil von zwei verschiedenen Teams sind, sollte es vielleicht aufgeteilt werden. Wenn die beiden Entwickler während verschiedener Sprints daran arbeiten, sollte es vielleicht aufgeteilt werden.

Ist dies eine "schlechte" Art, Scrum zu verwenden?

Der Schlüssel zum Erinnern ist, dass der Prozess dazu da ist, Ihnen zu dienen, nicht umgekehrt. User Stories sind eine Möglichkeit für technische und nichttechnische Mitarbeiter, die Kommunikation zu erleichtern. Sie formulieren, was sie möchten, jeder verhandelt, und dann geben Sie in der Geschichte Feedback über den Fortschritt.

Solange der Prozess für Sie funktioniert, kann es nicht so schlimm sein.

5
Telastyn

Wie andere vorgeschlagen haben, unterteilt mein Team unsere User Stories auch in Aufgaben. Dies ist im Allgemeinen einfach, wenn Sie Ihre User Stories über Software (wie JIRA oder Rally) verwalten. Dann ist es leicht zu sagen, welche Teile der Geschichte sich bewegen.

Eine Alternative für Aufgaben wäre jedoch, das Eigentum einfach neu zuzuweisen, wenn jede Person ihren Teil erledigt hat. Die Geschichte wird also herumgereicht - vielleicht beginnt Entwickler 1 sie mit der Backend-Arbeit und gibt sie dann an Entwickler 2 weiter, um die Benutzeroberfläche zu erstellen. Anschließend wird es zur Überprüfung an Ihren QS-Tester weitergeleitet. Diese Methode sollte in Umgebungen gut funktionieren, in denen Sie tatsächliche Karten an der Wand verwenden oder wenn Ihre Software keine Aufgaben verfolgt.

Auf jeden Fall empfehle ich, eine Geschichte niemals als "erledigt" zu bezeichnen, bis das Team zustimmt, dass sie fertig ist, einschließlich Tests. Auf diese Weise hat jeder die Möglichkeit, seinen Beitrag zu leisten. Und wenn Sie dies mit Ideen über kollektiven Codebesitz und Codeüberprüfungen kombinieren, dann ist jede Geschichte sowieso wirklich "im Besitz" des Teams. Es kann auf dem Weg verschiedenen Personen "zugewiesen" werden, aber wenn jemand unterwegs ist (krank/Urlaub/zu viele Besprechungen?/Andere), kann die Arbeit trotzdem erledigt werden.

Mein Team akzeptiert häufig User Stories als Teil unseres morgendlichen Stand-up/SCRUM-Meetings. Auf diese Weise kann jeder leicht erkennen oder bestreiten, ob es wirklich "getan" ist. In anderen Fällen lassen wir unsere QS-Ingenieurin das einfach tun. Wenn sie zufrieden ist, dass es getestet wurde und funktioniert und alle Aufgaben erledigt sind, nennen wir es erledigt.

3
Allan

Wenn wir Scrum-Modelle implementiert haben, ist zu erwarten, dass mehrere Entwickler an einer einzelnen User Story beteiligt sind. Möglicherweise gibt es Arbeit für Datenschicht, Integration, Front-End-CSS, Infrastruktur usw. Das Team kann die verschiedenen Unteraufgaben für eine Story zusammenfassen, um sie zu erledigen.

Davon abgesehen ist eine Person besitzt die Geschichte und ist dafür verantwortlich, den Fortschritt zu aktualisieren und sicherzustellen, dass alle ihr Stück gemacht haben und dass es zusammenarbeitet. Dies ist die Person für uns, die berichtet, dass eine Geschichte "fertig" ist.

3
Jay S

Wo ich heute bin, nennen wir dieses größere Projekt ein "Epos". Ein Epos besteht aus mehreren Geschichten und kann mehrere Sprints/Iterationen umfassen. Eine Geschichte wird für uns immer einem einzelnen Entwickler gegeben und sollte in einen einzelnen Sprint passen. Eine einzelne Geschichte wird dann in Aufgaben unterteilt. Jede der Aufgaben wird von demselben Entwickler für diese Story ausgeführt. Die Aufgaben sollen einen Einblick in den Fortschritt der Geschichte während des Sprints/der Iteration geben. Wenn jede Geschichte von jedem Entwickler abgeschlossen ist, zeigt das Epos den Fortschritt.

Der Sinn des Epos ist es, ein größeres Ziel zu haben, das nicht unbedingt in einen einzelnen Sprint/eine einzelne Iteration passt. Im Laufe der Zeit sind alle Geschichten fertig und das Epos ist fertig. Epen werden in eine Veröffentlichung gestellt.

Dann kommt das Chaos. Wem "gehört" welche Geschichte? Was bedeutet "in Bearbeitung" oder "erledigt"?

Wir führen alle zwei Wochen einen Demo-Code durch, bei dem die Storys für diesen Sprint/diese Iteration den Stakeholdern gezeigt und genehmigt werden müssen. In diesem Zusammenhang bedeutet "erledigt" für eine Geschichte, dass ich Ihnen zeigen kann, was sie tut. Ein Entwickler besitzt seine Geschichte und ist dafür verantwortlich, sie zu zeigen (dieser Teil ist eine Art Übervereinfachung, aber gut genug für diese Antwort; wir koordinieren unsere Demos durch eine einzelne Person). "Fertig" bedeutet, dass es erfolgreich demonstriert werden kann. "In Bearbeitung" bedeutet, dass ich noch offene Aufgaben habe und die Geschichte nicht vollständig ist. Ein Epos ist abgeschlossen, wenn alle Geschichten für dieses Epos erfolgreich demonstriert wurden.

Dies ist der perfekte Fallverlauf. Wir haben Geschichten und Demos, die fehlschlagen, Benutzer, die etwas anderes wollen usw. Oben ist das Ziel und zum größten Teil funktioniert es.

1
jmq