Ich fange gerade erst mit User Stories an (lese einige Blogs und sehe mir einige von Mike Cohns Präsentationen an).
Mein derzeitiges Verständnis ist, dass die Geschichte ein vertikaler Teil des Systems ist. Geschichten sind nicht „Datenbank hinzufügen, damit Kundendaten dauerhaft gespeichert werden“ oder etwas horizontal Ähnliches.
Geschichten handeln vom „ Was “ statt vom „ Wie “.
Jetzt kann man sich das Projekt/Produkt, an dem ich arbeite, als Verkaufsautomat vorstellen. Nehmen wir also an, ich habe die folgende Geschichte in dem Projekt namens "Automaten":
Als Kunde
möchte ich eine Quittung erhalten,
um meinen Kauf später nachweisen zu können.
Diese Geschichte scheint stark von dem Drucker abzuhängen, der eine Quittung physisch drucken kann, aber nehmen wir an, die Entwicklung wurde gestartet, aber die Hardware ist noch nicht eingetroffen.
Ich kann Geschäftslogik und GUI schreiben, aber ich kann mich nicht in den Drucker integrieren.
Ich kann jedoch eine Implementierung erstellen, die die Quittung auf die Konsolenausgabe "druckt".
Ist es in Ordnung, Aufgaben aus dieser Geschichte herauszuziehen und die Geschichte als abgeschlossen zu betrachten?
Die Aufgabe wäre ungefähr so:
"Xerox-Druckerimplementierung für [Drucker]-Schnittstelle erstellen"
Dies kann möglicherweise bedeuten, dass alle Geschichten abgeschlossen werden können, bevor die Hardware eintrifft, aber es lässt uns mit einer Reihe von (konkreten) Aufgaben zurück.
Einerseits fühlt es sich gut an, wenn der Product Owner (oder wer auch immer die Geschichte akzeptiert) diese Einschränkung/Kompromiss versteht und akzeptiert.
Dennoch kann man sagen
"Wie kommt es, dass Sie sagen, dass Sie die Geschichte abgeschlossen haben, aber Sie können sie nicht demonstrieren?".
Oder:
"[Hardware kommt an]. Nun, die Hardware ist da. Installieren Sie unsere Software und lassen Sie sie uns versenden.
-Nein, wir brauchen 2 Wochen für die Integration.".
Alles in allem scheint es auf Kommunikation (zweites 'C' in der Karte, Gespräch und Bestätigung) und gemeinsames Verständnis (Bestätigung) anzukommen.
Meine Sorge ist, dass ich neu in diesem Bereich bin und dies eine erste und bisher einzige Idee ist, wie man diese Situation angeht, und die Erfahrung zeigt, dass das blinde Durchlaufen anfänglicher Ideen zu dunklen Ecken führen kann.
BEARBEITEN:
Ich habe die Antwort von @Sarov akzeptiert, aber ich möchte hinterlassen, was ich aus diesem Thread gelernt habe:
Ich würde nein sagen.
Wie Sie bereits bemerkt haben, sollten User Storys vertikale Slices sein. Eine andere Sichtweise ist, dass sie selbst einen Wert bieten sollten .
Sie sollten Geschichten nur dann abbrennen, wenn diese Geschichten einen Mehrwert bieten können.
Es ist jedoch möglich, Geschichten aufzuteilen und/oder zu überarbeiten . Als kurzes Beispiel:
Denken Sie daran, dass Storys keine Implementierungsdetails enthalten. Sie könnten Ihre Story beispielsweise auf andere Weise vervollständigen – indem Sie dem Benutzer erlauben, eine E-Mail-Adresse einzugeben, sodass die Quittung per E-Mail an ihn gesendet wird.
Sie könnten dann die erste Geschichte beenden und eine zweite erstellen:
Als Kunde
möchte ich in der Lage sein, eine Quittung zu erhalten, ohne eine E-Mail-Adresse anzugeben,
damit ich meine E-Mail-Adresse privat halten kann.
... was eine sekundäre Option zum Drucken von Quittungen hinzufügen könnte.
Tolle Frage. Es läuft wirklich alles darauf hinaus, eine entscheidende Frage zu beantworten: Wird der minimale Arbeitsaufwand, der in dieser Karte angegeben ist, immer noch einen Wert haben? Diese Frage sollten das Entwicklungsteam und der Product Owner gemeinsam beantworten.
Stellen Sie sicher, dass Ihre Arbeit unabhängig von anderer Arbeit ist, mit Ihrem Product Owner verhandelbar, wertvoll, schätzbar, klein und testbar ist, um die obige Frage zu beantworten.
Ist es in Ordnung, Aufgaben aus dieser Geschichte herauszuziehen und die Geschichte als abgeschlossen zu betrachten?
^ Dies ist eine Frage an Ihren Product Owner, der dafür verantwortlich ist, den Wert der Arbeit Ihres Teams zu maximieren. Sich auf Ihre Definition of Done zu stützen und sie zu verfeinern , ist genauso wichtig wie das Verhandeln mit Ihrem PO über wertvolle Arbeit.
Kurz gesagt, es gibt keine wirklich endgültige Antwort auf Ihre Frage, außer mit Ihrem Product Owner zusammenzuarbeiten, um zu verstehen und zu verhandeln, was als wertvoll angesehen wird. Diese Übung hilft nicht nur bei dieser Karte, sondern bei allen nachfolgenden Karten, die sich vorwärts bewegen.
Vielleicht bin ich "contrarian", wenn ich vorschlage, dass eine (wahre ...) "User Story" überhaupt keine Implementierungsdetails enthalten sollte .
(Schließlich „hat Ihr ‚Benutzer‘ überhaupt keine Ahnung, ‚wie Ihre Software funktioniert‘.“ Und Sie wissen auch nicht alles darüber, wie Ihr Benutzer seine/ihre gesamte Arbeit macht. zwei werden sich [ganz] treffen.")
In meiner modifizierten Version dieser beliebten Methodik sind „User Stories genau das – Beschreibungen dessen, was tatsächliche Benutzer tun und sehen wollen“. Implementierungspläne werden vom Team erstellt, da es die einzige Gruppe ist, die die Software wirklich kennt.
Implementierungspläne (und Zeitpläne) werden vollständig vom Team erstellt, wobei alle gelieferten User-Storys sorgfältig geprüft werden, und erfordern manchmal, dass neue (!) User-Storys zur Klärung eingeholt werden. Ich bitte oder erwarte nicht, dass Benutzer mir diese Pläne direkt in ihren Stories geben. Das Team konzipiert und perfektioniert die Pläne und vergleicht sie dann mit den Geschichten, um zu sehen, ob sie übereinstimmen, und um zu entscheiden, ob wir für diesen Benutzer die bestmögliche Arbeit geleistet haben.
Todd A. Jacobs
Simon Haas
Todd A. Jacobs
Todd A. Jacobs