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.
Antworten:
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":
Ü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:
und so weiter. Kurz gesagt, Sie müssen Ihre User Stories in feinere Details zerlegen.
quelle
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 ".
quelle
YAGNIBegriff ist: Versuchen Sie nicht einmal ein vollständiges polymorphes Tagging - System zu machen , noch . Erstellen Sie eine einfache für den jeweiligen Anwendungsfall. Wenn der Product Owner mit zurückkommt eines anderen Geschichte über andere Dinge , Tagging, dann erweitern Sie das einfache bestehende System in ein polymorphes Tagging - System. Nur weil Sie denken, dass es notwendig sein wird, heißt das noch lange nicht, dass es notwendig sein wird. Es kann sich herausstellen, dass das Markieren anderer Modelle für eine Weile nicht erforderlich ist. Dann vergisst jeder dies und es wird nie zu einer Anforderung. Daher "Du wirst es nicht brauchen".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.
quelle
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:
... 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:
Jeder von ihnen ist testbar - wenn auch nicht besonders wertvoll für sich.
quelle
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.
quelle