Eine komplexe Geschichte zu Beginn des Projekts aufschlüsseln

Ich versuche, mich mit agilem Projektmanagement (mit Pivotal Tracker) auseinanderzusetzen, stoße aber immer wieder auf Wände, wenn ich versuche, die ersten Geschichten eines Projekts zu definieren. Nehmen Sie zum Beispiel diese sehr einfache Geschichte:

"Ein Benutzer sollte in der Lage sein, ein Produkt zu kennzeichnen"

Angenommen, ich habe "Produkt" bereits an anderer Stelle definiert, würde diese Geschichte möglicherweise das Schreiben eines polymorphen Markierungssystems unter die Haube beinhalten. Nach Abschluss dieser System-ID kann die Möglichkeit zum endgültigen Markieren eines Produkts hinzugefügt werden.

Mein Problem ist die Menge an Arbeit, die in dieser Geschichte verborgen ist. Ich kann Aufgaben definieren, um die Geschichte zu erledigen, aber Geschichten als Ganzes sollen 1-2 Tage Arbeit sein? Ich finde es nicht richtig, wenn die Geschichte nur die Spitze des Eisbergs enthüllt, aber das ist der einzige Teil, der sich auf den Benutzer bezieht.

Wie überwinden Sie so etwas? Was sind die Best Practices?

UPDATE 25/08 Vielen Dank an alle für Ihre Anleitung. Ich habe alle Ratschläge zur Definition von Geschichten berücksichtigt . Ich wechsle jetzt zu Jira Grasshopper, der Aufgaben innerhalb von Storys (Aufgaben, Schätzungen usw.) besser unterstützt und Entwicklungsaufgaben nach Beginn des Sprints nachverfolgt.

Wenn Ihre Storys jeweils 1 bis 2 Tage Entwicklerarbeit benötigen, sollten Sie jede Story in bestimmte Benutzeraufgaben aufteilen, die 1 bis 2 Tage Entwicklerarbeit umfassen.

Betrachten Sie die folgende "User Story":

Ein Benutzer sollte in der Lage sein, eine Rechnung von einem gekauften Produkt zu erhalten.

Überlegen Sie, worum es beim Datenbankdesign geht, und geben Sie dem Benutzer diese Funktion. Sie benötigen eine Kundentabelle, eine Rechnungskopftabelle und eine Rechnungspositionstabelle, und wir haben noch nicht einmal über das Akzeptieren von Zahlungen gesprochen.

In Wirklichkeit sind User Stories nicht so einfach. Vollständige User Stories enthalten eine exemplarische Vorgehensweise für die beteiligten User Steps:

• Der Benutzer legt das Produkt in den Warenkorb
• Benutzer gibt Menge an
• Benutzer gibt Versandart an

und so weiter. Kurz gesagt, Sie müssen Ihre User Stories in feinere Details zerlegen.

Geschichten sollen nicht "1-2 Tage Arbeit" sein. Unter Scrum werden Storys normalerweise mithilfe von Story Points geschätzt, einem relativen Größensystem. Wenn Sie Planungs-Poker- Storys verwenden, erhalten Sie einen Punktewert. Die Zeit, die für die Implementierung der Story benötigt wird, hängt von der Geschwindigkeit ab, die Ihr Team festgelegt hat.

Wenn Sie der Meinung sind, dass die Geschichte Komplexität verbirgt (Sie könnten es eine epische Geschichte nennen), sollten Sie sie in kleinere Geschichten aufteilen. Stellen Sie sicher, dass die neuen Storys den INVEST- Kriterien entsprechen.

Aber Sie können dies überentwickeln; Hier gilt das XP-Prinzip von YAGNI . Um explizit zu sein, sollten Sie kein "polymorphes Tagging-System unter der Haube" implementieren, es sei denn, Sie benötigen es wirklich. Selbst dann sollte es durch die Verbesserung des vorhandenen Systems entworfen werden, das Sie mit einer guten Reihe von Tests entwickelt haben.

Wenn Sie sicher sind, dass Sie dieses komplexe Tagging-System benötigen, sollten Sie die Komplexität in separaten Geschichten aufzeigen. Mike Cohn beschreibt den Designansatz als " absichtlich und doch aufstrebend ".

Es scheint, dass Sie Geschichten und Aufgaben verwirren.

Benutzer Geschichte

Eine User Story ist eine vollständige "Funktion", die dem Produkt mehr Wert verleiht, wenn sie dem Produkt hinzugefügt wird.

Eine User Story sollte nicht größer sein, als sie während eines Sprints implementiert werden kann . Im ersten Teil der Sprintplanung entscheiden Sie, an welchen User Stories Sie während des Sprints arbeiten möchten. Das Ziel des Sprints ist es, diese User Stories zu vervollständigen und so dem Produkt mehr Wert zu verleihen.

Aufgabe

Während des zweiten Teils der Planungsphase des Sprints teilen die Entwickler die Geschichte in Aufgaben auf . Die Aufgaben sind Entwicklungsaufgaben. Dies können beispielsweise "Spalte zur Datenbank hinzufügen", "Dienst x erweitern" usw. sein. Eine Aufgabe sollte nicht größer sein, als sie an einem Tag erledigt werden kann.

Während des täglichen Scrums bewerten Sie den Fortschritt dieser Aufgaben. Wenn eine Aufgabe mehr als ein tägliches Scrum ausgeführt wurde, dauert es zu lange, und Sie als Team sind dafür verantwortlich, diese Situation zu lösen.

Denken Sie daran, dass User Stories für die Stakeholder einen geschäftlichen Wert darstellen. Die Stakeholder sollten an der Fertigstellung der User Stories interessiert sein, nicht an Aufgaben.

Die Aufgabenteilung ist ein Werkzeug für das Entwicklungsteam, um den Sprint zu verwalten, den Fortschritt der User Stories während eines Sprints zu überwachen und potenzielle Probleme zu visualisieren.

Die Stakeholder sollten sich nicht mit diesen Entwicklungsaufgaben befassen. Leider ist es meine Erfahrung, die sie häufig machen, insbesondere für Organisationen, die neu in der agilen Entwicklung sind. Der Umgang mit dieser Situation ist jedoch eine andere Sache.

Epos

Wenn eine User Story größer ist als Sie denken, dass Sie sie in einem Sprint abschließen können, wird sie als Epos bezeichnet. Es muss in mehrere kleinere User Stories unterteilt werden, bevor Sie als Team damit beginnen können, daran zu arbeiten.

Denken Sie daran, dass eine User Story dem Endbenutzer einen Mehrwert bietet. Daher ist es nicht der richtige Weg, ein Epos in eine "Front-End" - und eine "Back-End" -Story aufzuteilen. Das Hinzufügen des Back-End für eine neue Funktion bietet den Endbenutzern an sich keinen Wert.

Es ist nicht immer einfach, ein Epos in User Stories zu unterteilen, die innerhalb des Zeitrahmens eines Sprints verwaltet werden können, wenn Sie nicht damit vertraut sind.

Verwenden von Pivotal Tracker

Ich denke, Pivotal Tracker ist ein großartiges Tool zum Verfolgen von User Stories. Aber es ist kein Scrum-Tool als solches, und die Art und Weise, wie Scrum lehrt, Geschichten in Aufgaben zu unterteilen, ist mit dem Pivot-Tracker nicht einfach zu handhaben. Sie können die Möglichkeit aktivieren, User Storys Aufgaben hinzuzufügen. Wenn Sie jedoch ein Projekt mit Scrum ausführen, würde ich empfehlen, eine weiße Tafel und Haftnotizen zu verwenden, um den Fortschritt von Aufgaben während eines Sprints zu verfolgen.

Das Entwurfsziel der Implementierung eines polymorphen Markierungssystems ist in Ordnung, aber Sie sollten sich weiterhin auf die Implementierung der vom Kunden gewünschten Funktionen konzentrieren. Dies kann bedeuten, dass sich Ihr System im Laufe der Zeit zu einem polymorphen Tagging-System entwickelt, eine feinkörnige User-Story für eine feinkörnige User-Story. Zu jedem Zeitpunkt auf dieser Reise sollten Sie jedoch ein System haben, das aus vielen kleinen und testbaren Funktionen besteht, die durch eine Sammlung von User Stories beschrieben werden, die Sie implementiert haben.

In diesem Fall klingt es so, als wäre "Tagging Products" in Ihrem System ein Epos, dh etwas, das weitaus größer als eine einzelne User Story ist und mit ein wenig Aufwand in mehrere kleinere Storys unterteilt werden kann. Wenn ich eine angemessene Menge an künstlerischer Lizenz nehme, kann ich mir die folgenden User Stories vorstellen, die ungefähr auf Ihre Anforderungen zutreffen könnten:

• Als Systemadministrator möchte ich dem System einige gültige Tags zuweisen, damit Benutzer bei der ersten Verwendung der Tagging-Funktion einige Werte zur Auswahl haben.
• Als Benutzer des Systems möchte ich in der Lage sein, ein Produkt nach Namen zu suchen, damit ich es später markieren kann.
• Als Benutzer des Systems möchte ich die Beschreibung eines Produkts lesen können, damit ich entscheiden kann, welche Tags es haben soll.
• Als Benutzer des Systems möchte ich ein Bild des Produkts sehen können, damit ich entscheiden kann, welche Tags es haben soll.
• Als Benutzer des Systems möchte ich in der Lage sein, ein einzelnes Tag an ein einzelnes Produkt anzuhängen.
• Als Benutzer des Systems möchte ich in der Lage sein, ein einzelnes Tag von einem einzelnen Produkt zu entfernen.
• Als Benutzer des Systems möchte ich in der Lage sein, ein einzelnes Tag an mehrere Produkte anzuhängen.
• Als Benutzer des Systems möchte ich in der Lage sein, mehrere Tags an ein einzelnes Produkt anzuhängen.
• Als Systemadministrator möchte ich eine eindeutige Liste der im System verwendeten Tags anzeigen, damit ich entscheiden kann, ob es sich bei einem dieser Tags um Duplikate handelt.
• Als Systemadministrator möchte ich doppelte Tags konsolidieren.

... und ich könnte weitermachen.

Ich bezweifle, dass eines davon so naturgetreu sein wird, dass Sie es verwenden werden, aber hoffentlich veranschaulichen sie die Art von Details, zu denen Sie mit Ihren User Stories gehen können.

Wenn eine User Story wirklich nicht in kleinere Storys unterteilt werden kann und Sie sie dennoch für zu groß halten, um sie auf einmal zu implementieren, können Sie sie in vertikale Segmente aufteilen. Dies ist eine Technik, bei der nur ein Teil der Funktion unter jeder User Story bereitgestellt wird. Jeder Teil ist jedoch ein testbarer Schnitt durch alle relevanten Ebenen der Technologie, z. B. für eine Website. Dies kann bedeuten, dass die Datenbank-, Anwendungs- und Benutzeroberflächenebenen geändert werden. Vermeiden Sie, dass eine User Story für die Datenbank funktioniert, eine andere für die Anwendung und eine andere für die Benutzeroberfläche, da diese nicht einzeln getestet werden können.

Wenn ich noch mehr künstlerische Lizenzen nehme, könnte ich aufteilen: "Als Benutzer des Systems möchte ich in der Lage sein, ein einzelnes Tag an ein einzelnes Produkt anzuhängen." in die folgenden vertikalen Scheiben:

• Als Benutzer des Systems, der sich ein einzelnes Produkt ansieht, möchte ich in der Lage sein, eine Liste von Tags nachzuschlagen, damit ich entscheiden kann, welches angewendet werden soll.
• Als Benutzer des Systems, der sich ein einzelnes Produkt ansieht und sich für ein Tag entschieden hat, das auf dieses Produkt angewendet werden soll, möchte ich es anwenden können.
• Als Benutzer des Systems, der ein einzelnes Produkt betrachtet und ein Tag auf dieses Produkt angewendet hat, möchte ich eine Bestätigungsmeldung auf dem Bildschirm, die mich darüber informiert, dass es erfolgreich gespeichert wurde.

Jeder von ihnen ist testbar - wenn auch nicht besonders wertvoll für sich.

Es gibt Bücher, die ausschließlich dazu dienen, herauszufinden, wie Sie Ihre Anforderungen richtig beschreiben und aufschlüsseln können. Es ist also keine leichte Aufgabe.

Oft finde ich Entwicklungsteams, die nach komplexen Lösungen streben, anstatt nach den einfachsten. Dies kann an der Geschichte selbst liegen oder daran, dass das Team eine übermäßig komplexe Lösung anstrebt, die nicht nur diese Geschichte löst, sondern auch die Grundlage für die Geschichten x, y und z bildet. Dies ist eine gute Absicht, bläht aber den Umfang auf, in dem die gleiche Arbeit mit weniger Arbeit erledigt werden kann. Es ist immer schwer zu beurteilen, wie viel Design in eine Geschichte fließen muss, um zukünftige Geschichten nicht zu ruinieren, indem das Design durcheinander gebracht wird. Diese Entscheidung muss das Team treffen.

Als Product Owner können Sie dies nur beeinflussen, indem Sie Geschichten in kleinere Teile zerlegen. Sie sollten sich fragen: Ist die Geschichte die kleinste Lösung, die wir uns derzeit vorstellen können? Können wir es in reduzierte Funktionssätze aufteilen, die eines Tages zum "großen flexiblen Tagging-System werden, das ich mir immer gewünscht habe"? Sie können mit einem Tag-System für nur ein einzelnes Tag beginnen, es dann um eine Liste vorgewählter Tags erweitern und dann vom Benutzer Tags usw. definieren lassen.

Für das Entwicklerteam läuft es darauf hinaus: Können wir einen einfacheren Ansatz finden, um die Geschichte zu realisieren, aber dennoch eine solide Architektur haben, die die Aufgabe heute erfüllt, ohne die zukünftigen Funktionen zu beeinträchtigen?

Wenn Sie offen für Zwischenlösungen sind und das Entwicklungsteam auch versucht, die einfachste und dennoch gute Lösung anzubieten, werden Sie wahrscheinlich den Sweet Spot finden, an dem die Größe der Geschichten, die Sie machen möchten, richtig ist (je kleiner desto besser). . Das heißt nicht, dass Sie nur kleine Geschichten haben. Einige sind größer als andere, dies ist nur eine Tatsache, die Sie akzeptieren müssen, oder wenn sie zu groß sind, zerlegen Sie Geschichten in kleinere Teile.