Was vom Wie trennen – Design in einer agilen Umgebung [geschlossen]

Question

Wie bringen Sie das Produktmanagement in einer agilen (Scrum-)Umgebung dazu, ausreichend kleine Backlog-Elemente oder Storys zu erstellen, ohne dass sie das gesamte Design übernehmen müssen, was nicht ihre Spezialität ist?Mit anderen Worten: Wie trennt man in der agilen Entwicklung das Was (Geschäftsanforderungen) vom Wie (Design)?

Answer 1

Mit Scrum, dem Produkt Management sollte eine Person sein:Die Produktbesitzer .

Was Sie tun möchten, wird während des erledigt Sprintplanung, bei dem das gesamte Team (Product Owner, Scrummaster, Entwickler) anwesend sein sollte.

Der Was sollte definiert werden als benutzergeschichten bis zum Produktbesitzer .Die User Stories sollten auf hohem Niveau sein und Ihren Produktbesitzer darauf beschränken, die Geschäftsanforderungen auszudrücken Ein-Satz-Geschichten sollten den Zweck erfüllen.

z.B. Als StackOverflow-Benutzer würde ich gerne meinen Ruf sehen

Eines der Ziele der Sprintplanung besteht darin, die Storys festzulegen, die während des Sprints erstellt werden sollen.Wenn also die Geschichten vom Produktbesitzer ausgewählt werden, kann das Team sie unterteilen und kurz über das Design sprechen (das Wie) und schätzen sie.

Kurz gesagt, die Was sollte vom Produktbesitzer durchgeführt werden Wie vom Team.Wenn dem Product Owner dieser Prozess klar erklärt wird, wird er nicht versuchen, alles zu entwerfen.Wenn er es trotzdem versucht, wird ihn der Scrummaster aufhalten.

Answer 2

Das erste, was Sie tun müssen, und das ist die Ursache für das Scheitern vieler Scrum-Projekte, ist, Ihrem Produktmanagement beizubringen, die Rolle des Product Owners zu übernehmen.Sie müssen ihm zeigen, dass er für den ROI des Projekts verantwortlich ist, und dafür ist er dafür verantwortlich, die Storys/Inhalte/Geschäftsanforderungen/Funktionen oder was auch immer Sie verwenden, um Ihr Produkt-Backlog so zusammenzustellen, dass es am besten ist Wertvolle Gegenstände haben höhere Priorität.

Ich bin dafür, User Stories als Produkt-Backlog-Elemente zu verwenden und dann bei der Sprint-Planung die ausgewählten Storys für die Erstellung des Sprint-Backlogs in kleinere Aufgaben aufzuteilen.

Wenn Sie Ihre User Stories schreiben oder Ihrem PO beim Schreiben helfen, sollten Sie immer bedenken, dass die Storys INVESTIEREN sollten. ICHunabhängig, Nverhandelbar, Vfür Kunden wertvoll, Estimulierbar, SEinkaufszentrum und Tstabil.

Ich denke, zu Beginn könnte die Verwendung der folgenden Vorlage hilfreich sein, damit sich die Bestellung auf die Geschäftsziele konzentriert:

„Als – Typ Benutzer – möchte ich – ein Ziel –, damit – ein Grund –.“

Ein Beispiel für eine Geschichte wäre: „Als Stackoverflow-Benutzer möchte ich über eine Antwort abstimmen, damit die wertvollste Antwort leicht gefunden werden kann.“

Vergessen Sie nicht, den PO den Akzeptanztest für jede Story Ihres Sprint-Backlogs schreiben oder definieren zu lassen, da er als grundlegendes Kriterium verwendet werden kann, um festzustellen, ob eine Story vollständig implementiert ist.

Für das obige Beispiel sind zwei mögliche Abnahmetests:

„Testen Sie, um eine Antwort positiv zu bewerten“

„Testen Sie, um eine Antwort abzulehnen“

Mit dieser Story und zwei Akzeptanztests weiß das Team, dass der Stackoverflow-Benutzer über die Antworten abstimmen und den Story-Status aktualisieren kann. Fertig ist es notwendig, dass das System dem Benutzer erlaubt, eine Antwort nach oben oder unten abzustimmen, ohne Ausnahmen auszulösen.

Answer 3

Vergessen Sie nicht, dass die Product-Backlog-Elemente anhand eines Gewichtungssystems (Primzahlen, Fibonacci usw.) in der Reihenfolge ihrer Wichtigkeit bewertet werden sollten, sodass, wenn Sie Elemente in Ihrem Backlog haben, Elemente mit ähnlicher Wichtigkeit (d. h.2 Items mit einem Gewicht von 21), dann sollten beide theoretisch versuchen, vor den 13ern und 8ern in den Sprint eingefügt zu werden.

Answer 4

Während der (Neu-)Schätzung des Rückstands (nach der Priorisierung) sollte das Team Modellierungen durchführen, um das volle Ausmaß der User Story zu verstehen und die Komplexität genau einschätzen zu können.Dies ist nicht der volle Umfang der Modellierung, die stattfinden kann (Teams sind möglicherweise mehr in der Entwicklung tätig), aber es ist ein guter Ausgangspunkt und Sie können von der Anwesenheit des Kunden/Produktbesitzers profitieren, der dort Fragen beantwortet und dann.

Die daraus resultierende Diskussion wird Ihnen dabei helfen, mit dem Product Owner zusammenzuarbeiten, um dessen Anforderungen auf eine sinnvolle und geeignete Granularität aufzuteilen.