User Stories - Probleme, die nicht User Stories gemacht werden können

Question

Ich bin von einem XP-Hintergrund. Ich kenne den Prozess sehr gut und habe solide Arbeitserfahrung damit. Ich habe herausgefunden, dass dies der beste Weg ist, Software zu entwickeln.

Ich bin in der Position eines Prozessdoktors von Art und dies schafft viel Selbstüberprüfung und Aufwertung meines eigenen Verständnisses.

Eine sehr häufige Sache, die ich höre ist, dass einige Arbeit nicht zu Geschichten gemacht werden kann. Ich persönlich glaube das nicht. Die Ausreden sind

1. Es ist zu groß (Der Entwickler wird nichts zu zeigen, bis zum Ende der 5 Wochen).
2. es ist ein komplizierter Algorithmus oder abstraktes Konzept (dauert 5 Wochen zu schreiben und nichts zu zeigen).

Diese Frage soll Hinweise, Tipps oder Vorschläge erhalten.

Ich suche nach Hinweisen, Tipps und Vorschlägen, wie man diese und ähnliche wahrgenommene Probleme anspricht (und mehr, wenn Sie an sie denken können).

Ich werde die Antwort markieren, die die meisten Informationen darüber hat, wie man Benutzer/Entwickler umgehen kann, die keine Geschichten schreiben und ihre vielen Ausreden ansprechen, warum nicht (ich habe nur ein paar aufgelistet und es gibt noch viele mehr).

Answer 1

Also im Grunde Ihre Frage lautet: „Was kann ich tun, wenn Leute behaupten, eine Aufgabe, für eine User Story zu groß ist, und nicht aufgeteilt werden können.

Nach meiner Erfahrung fast jedes Problem kann aufgeteilt werden Fragen Sie sie, ob sie eine vereinfachte Version implementieren, erweiterte Features auslassen, vielleicht sogar an einigen Stellen Standardwerte verwenden können, im Grunde alles, um etwas zu erzeugen, das innerhalb einer Iteration aussagekräftige (dh testbare) Ergebnisse liefert Punkt einer Iteration ist nicht, vollständige Funktionalität zu liefern, sondern nur nützliche und testbare Funktionalität.

Diese Aufteilung kann schwierig sein, aber Sie zwingt Sie zu überlegen, was Sie wirklich brauchen, was sehr wertvoll ist. Die Entwickler meckern vielleicht darüber (ich mache oft selbst :-)), aber es ist wirklich notwendig. Das Aufteilen großer Aufgaben in überschaubare User Storys ist das Herzstück aller agilen Methoden.

Das heißt, wenn die Aufgabe wirklich, wirklich, wirklich nicht nach unten durchbrochen werden kann (man denke an komplexen mathematischen Algorithmus in einem Forschungsumfeld, die Wochen dauert, bis auch die Grundlagen des verstehen), dann ist Ihre Iteration zu kurz. Die Iteration muss lang genug sein, um aussagekräftige Ergebnisse zu liefern. Und wenn die meisten Ihrer Probleme so hart sind, dass sie 2-3 Monate brauchen, um etwas zu erledigen, dann ist das Ihre Iterationslänge. Aber ich habe noch nie ein Projekt gesehen, wo das war wirklich der Fall ist ...

Answer 2

Das Problem der "algorithmischen Spezifikation" ist häufig.

Viele Menschen bevorzugen es, Code zu schreiben, und es ist nicht wichtig, wer der Benutzer ist oder was er tut.

Ich versuche, sie zu konzentrieren, indem Sie diese Fragen stellen.

1. Was kann die Person unternehmen? Was könnten sie möglicherweise tun mit den Informationen? Wenn sie etwas Verantwortung haben, können sie Maßnahmen ergreifen, um etwas zu verweigern, zu genehmigen, zu halten, abzulehnen, neu zu verarbeiten, zu stoppen, zu starten. Wenn der Benutzer keine Maßnahmen ergreifen kann, müssen Sie fragen, ob sie wirklich Interessengruppen sind.
2. Welche Entscheidung müssen sie treffen? Wie entscheidet die Entscheidung welche Aktion (falls überhaupt) zu ergreifen ist? Wir können diese Entscheidung nicht automatisieren - deshalb sind Leute in der Schleife.
3. Welche Informationen benötigt diese Person, um die Entscheidung zu treffen, Maßnahmen zu ergreifen.

Information-Entscheidung-Aktion.

Wir schreiben nur Software, um Informationen vorzubereiten, damit Leute Entscheidungen treffen können, damit sie handeln können.

Wenn das nicht der Fokus ist, geraten die Geschichten außer Kontrolle.

Answer 3

Benutzer/Entwickler, die gewohnt Geschichten

Benutzer schreiben sollen keine Benutzergeschichten schreiben. Sie sollen Ihnen keine User Storys erzählen. Sie können erwarten, dass sie darüber sprechen, wie sie funktionieren, welche Probleme sie beschäftigen und was sie gerne tun möchten, um ihre tägliche Arbeit zu erleichtern.

Sie selbst sollten ihnen zuhören und sich Notizen machen. Wenn dies zulässig ist, verwenden Sie einen Kassettenrekorder oder eine Kamera. Dann bringen Sie die gesammelten Informationen zurück, wenn Sie sie wiedergeben und identifizieren, was Sie User Stories nennen. Sie besprechen sie mit dem Team und wenn Sie sich geeinigt haben, haben Sie Anwendungsfälle, die in Ihrer Entwicklung eine Rolle spielen.

Welche Rolle Entwickler spielen, liegt ganz bei Ihnen. Wenn sie nur Programmierer sind, nehmen sie nicht am Prozess teil. Wenn sie zum Teil als Berater fungieren, helfen sie dabei, User Storys zu definieren.

Answer 4

Normalerweise, wenn Sie "es ist zu groß" bekommen, was sie wirklich sagen, ist "Ich habe nur eine vage Idee, wie das funktionieren sollte". Sie müssen mit ihnen arbeiten, um sie besser zu definieren, bis es möglich ist, sie in logische Teile aufzuteilen, die leichter verwaltet werden können.

Answer 5

Hier sind ein paar Ressourcen, die ich im Laufe der Zeit gesammelt haben und das könnte helfen:

• Patterns for Splitting User Stories
• Story Weight Reduction Toolkit
• Twenty Ways to Split Stories
• Ways to split user stories

zu groß oder zu com Es gibt immer einen Weg, eine Geschichte auf Diät zu setzen (vielleicht erhalten Sie nicht das Endergebnis in einer Iteration, aber das bedeutet nicht, dass Sie nicht können und, nun, es wird mehr als eine Iteration geben).

Answer 6

Es ist im Grunde die Pflicht und die Verantwortung des Produktbesitzers. Und es kann irgendwelche Anforderungen/Aufgaben geben, die nicht in User Storys aufgeteilt werden können. Ich fand viele solcher Diskussionen auf SCrum Master Forums

Answer 7

Wenn Entwickler-Team behauptet, dass die Geschichte zu groß ist und nicht in den Sprint passen .. nehmen Sie ihr Feedback und versuchen, die Geschichte mit Must have und schön, um Aufgaben zu teilen und zu versuchen Teilen Sie es basierend darauf.

Überprüfung dieses Flussdiagramm .. kann eine Hilfe sein: http://www.agileforall.com/wp-content/uploads/2012/01/Story-Splitting-Flowchart.pdf