Wir arbeiten derzeit an einem Projekt und diskutieren mit anderen, wie wir das Projekt am besten aufschlüsseln können. Unten stelle ich nur Titel zur Verfügung, schreibe nicht die vollständigen User Stories, um das Lesen zu beschleunigen.
Jetzt gibt es einige Debatten darüber, ob Kontaktnummern wirklich in zwei separate Geschichten aufgeteilt werden müssen. Meiner Meinung nach besteht Bedarf. Wir starten möglicherweise nur mit der Erfassung der privaten Telefonnummer und dann der Handynummer zu einem späteren Zeitpunkt.
Die zweite Debatte ist, dass ich diese weiter aufschlüsseln würde, um eine separate Geschichte für die Validierung zu haben, Beispiel:
Das Argument könnte also sein, dass diese Geschichte für den Kunden keinen Wert hat. Es hat jedoch einen gewissen Wert, da es dem Kunden helfen soll sicherzustellen, dass er eine gültige Handynummer eingegeben hat, dh UK beginnt mit 07 oder +447. Abgesehen davon ist mein Grund für separate Stories zur Validierung, dass wir ohne Validierung der Handynummer starten könnten, obwohl es schön wäre, es zu haben.
Wenn Sie die Dinge in kleinere Teile aufteilen, wird alles überschaubarer: einfacherer Fortschritt, leichtere Fortschrittsverfolgung und der Fortschritt ist viel sichtbarer. Außerdem erleichtert es die Iteration.
Außerdem wäre ich sogar versucht, das Anzeigen und Aktualisieren der Mobilnummer in separate Stories aufzuteilen, da wir wiederum nur mit Anzeigen live gehen könnten. Ich denke, dies spiegelt das schrittweise Bauen wider, ähnlich wie es Spotify mit seinem Beispiel Skateboard, Scooter, Fahrrad, Motorrad, Auto vorschlägt.
Ist mein Ansatz valide?
Ihr Ansatz scheint gültig zu sein, aber nur Sie und Ihr Team können feststellen, ob er für Ihren aktuellen Prozess optimal ist. Bei der Dekomposition geht es darum, die optimale Story-Größe für den Prozess Ihres Teams zu finden ; Während kleinere Stories helfen, den Fluss aufrechtzuerhalten, können einige Stories so klein sein, dass die Größe der Arbeitseinheit durch den Prozess-Overhead überschwemmt wird, den jede Story mit sich bringt.
Ist mein Thema „Persönliche Kontaktinformationen“ richtig aufgeschlüsselt?
Es gibt keine kanonische Antwort auf diese Frage, da die notwendige Granularität von User Stories (oder traditionellen Work Breakdown Packages, was das betrifft) stark von Dingen abhängen wird wie:
Überlegen Sie zum Beispiel, ob es für das Projekt sinnvoll ist, Ansichts-, Aktualisierungs- und Validierungsschritte in separaten Storys zu erstellen. Dies hängt stark ab von:
Ihr Rahmen.
Einige Frameworks machen es trivial, alle drei Ergebnisse als eine einzelne Arbeitseinheit zu behandeln, während andere dies nicht tun. Ihr Kilometerstand wird daher variieren.
Ihre Abhängigkeiten.
Wenn die Geschichten unabhängig voneinander erstellt werden können, können Sie sie sicherlich zu separaten Geschichten machen, wenn dies einen Mehrwert für das Projekt darstellt. Die Behandlung voneinander abhängiger Elemente auf Aufgabenebene als separate User Storys ist jedoch oft ein Projektgeruch.
Die Abgrenzung zwischen einer Geschichte und einer Aufgabe innerhalb Ihres Projekts.
Das Behandeln einer Reihe von Teilaufgaben als mehrere User Stories erhöht einfach den Prozessaufwand. Als zusätzliche Überlegung sollte eine Geschichte selten (wenn überhaupt) vorgeschrieben sein, und Elemente auf Aufgabenebene sind im Allgemeinen von Natur aus vorgeschrieben. Versuchen Sie, Ihre Geschichten so granular wie möglich zu halten und gleichzeitig sicherzustellen, dass selbst die kleinste Geschichte über der Aufgabenebene bleibt.
Ihre Arbeitseinheit.
Als leuchtendes Beispiel: Obwohl nichts grundsätzlich falsch daran ist, die Stories in kleinere Stories aufzuteilen, die über der Aufgabenebene bleiben, könnte ich bei einem Rails-Projekt mit einem ausgereiften Team eine einzelne Story aus "support-validierten Handynummern auf der Kontaktseite" machen ." Mir erscheint diese Arbeitseinheit relativ klein und idempotent. Auch hier kann Ihre Laufleistung je nach Kontext und Fähigkeiten variieren.
Ist mein Ansatz valide?
Ihr Ansatz scheint abstrakt sicherlich gültig zu sein, aber ob er im Kontext Ihres speziellen Projekts nützlich ist, kann Ihr Team entscheiden. Die zugrunde liegende Frage ist, ob der zusätzliche Detaillierungsgrad dem Team hilft oder behindert. Wenn eine Story im Allgemeinen den INVEST-Prinzipien folgt und in eine einzelne Iteration passt, dann kann eine weitere Zerlegung einfach den Overhead oder die Komplexität des Planungsprozesses erhöhen.
Hier sind zwei Dinge besonders zu beachten:
Das „V“ für Wert in INVEST muss nicht immer Wert für den Endverbraucher sein.
Der Wert kann für das Projekt und nicht nur für den Endbenutzer sein. Solange es einen klar identifizierten „Wertkonsumenten“ für die Story gibt und solange der Product Owner (oder ein vergleichbarer Stakeholder in Ihrem Rahmen) Wert in der Story findet, ist das für „V“ ausreichend.
Das Zerlegen von Geschichten ist ein Kompromiss.
Wie Sie schon sagten, sind kleinere Storys in vielerlei Hinsicht einfacher zu verwalten und im Allgemeinen „agiler“. Alle Stories haben jedoch einen festen Betrag an Prozess-Overhead, daher muss ein Gleichgewicht gefunden werden, die Story so klein wie möglich zu halten, ohne sie so klein zu machen, dass sie unnötigen Buchhaltungs- oder Framework-Overhead hinzufügt. Dieser Balanceakt erfordert unterschiedliche Kompromisse für jedes Projekt, Team und jede Geschichte, sodass Ihr Team sein eigenes Optimum finden muss.
Ich werde den anderen beiden Antworten hier widersprechen und sagen: Nein, Ihr Ansatz ist nicht gültig. Betrachten Sie den einfachen Anwendungsfall eines Kontakts, der kein Telefon zu Hause hat, sondern nur ein Mobiltelefon. Sie werden von einem System frustriert sein, das ihr einziges Telefon mit einer ungültigen privaten Telefonnummer zurückweist.
Stattdessen würde ich vorschlagen, dass Sie die Geschichten in folgende Kategorien unterteilen:
Story 1 hätte die höchste Priorität, aber abhängig von Ihrer erreichten Geschwindigkeit könnten Sie zB Story 2 komplett fallen lassen und direkt zu 3 gehen, Story 5 nach 1 implementieren usw., wodurch Sie flexibel sind, was in jeder Version geliefert wird.
Sieht gut für mich aus.
Ich würde die Geschichten wahrscheinlich so aufschlüsseln:
dann kann die Bestellung/das Unternehmen ihre relative Priorität ausgleichen.
Was die Validierung von Telefonnummern betrifft, muss entschieden werden, ob es sich um eigenständige Storys oder um zusätzliche Akzeptanzkriterien für die beiden Update-Storys handelt.
Ich glaube nicht, dass es darauf eine richtige oder falsche Antwort gibt. Es hängt vom Wert der Validierung für das Unternehmen und den Kosten für die Bereinigung ungültiger Telefonnummern ab, ob und wann die Validierungsgeschichten schließlich implementiert werden.
Persönlich würde ich die Telefonnummernvalidierung zu einem Teil der Akzeptanzkriterien machen, unter der Annahme, dass es sich um eine sehr kleine Aufgabe handelt und Verschwendung vermieden wird (ungültige Daten, deren Bereinigung in Zukunft Kosten verursachen wird).
Lee Walker