Ich bin sehr an User Stories für endbenutzergesteuerte Funktionen gewöhnt. Aber wenn Sie ein Projekt von Grund auf neu starten, ist es dann sinnvoll, die Geschäftsinhaber als Benutzer zu behandeln und ihre Bedürfnisse auch so zu definieren? Einige Beispiele
As a Business Owner
I want regular database backups
So that we can maintain business continuity
As a Business Owner
I want end-user analytics
So that we can know how our platform is being used
As a Business Owner
I want end-user authentication
So that only registered users have access
Dinge wie diese sind offensichtlich Features, die ein Dev/Devops-Team erstellen muss, aber sie sind nicht wirklich endbenutzerorientiert im traditionellen Sinne, an den ich bei User Stories denke. Gedanken?
Der Begriff „Benutzer“ in User Stories wird oft besser als Akteur oder Rolle in einem Anwendungsfall oder einfach als Wertkonsument verstanden . Das Hauptziel einer klar definierten Rolle in einer User Story besteht darin, die Story so zu gestalten , dass der Umfang eingeschränkt wird. Das sekundäre Ziel besteht darin, sicherzustellen, dass die User Story als Platzhalter für die Zusammenarbeit und nicht als Ersatzspezifikation angesehen wird. Mit einem identifizierten Verbraucher der Geschichte wird es für das Team viel einfacher zu wissen, mit wem es über Implementierungsdetails oder Akzeptanzkriterien sprechen kann.
Um es kurz zu machen, an Ihren Geschichten ist rein pragmatisch nichts auszusetzen. Sie können jedoch besser sein, wenn Sie den „Benutzer“ im Story-Format nutzen, um den Kontext und die Zusammenarbeit zu verbessern.
Während Ihre Geschichten wahrscheinlich so wie sie sind umsetzbar sind, können Sie sie mit einem besseren Rahmen und durch die Schaffung von Möglichkeiten zur Zusammenarbeit verbessern. Schauen wir uns ein Beispiel an.
Mit den oben beschriebenen Zielen könnten Sie Ihre erste Geschichte wie folgt umschreiben:
Als Datenbankadministrator
möchte ich sicherstellen, dass die Datenbank innerhalb von 4 Stunden wiederhergestellt werden kann,
damit wir unsere Geschäftskontinuitätsziele erreichen können.
Diese Geschichte ist dem Original wahrscheinlich überlegen, weil:
Ihre anderen Geschichten würden ebenfalls von einer ähnlichen Behandlung profitieren. Es lohnt sich auf jeden Fall, etwas mehr Zeit aufzuwenden, um sicherzustellen, dass Sie die richtigen Mitarbeiter für eine Kerngeschichte gewonnen haben, sowie ausreichend Kontext, um sicherzustellen, dass das Team das Richtige aufbaut .
Wenn es mehrere Rollen oder Feature-Verfeinerungen gibt und eine einzelne Story nicht alle erfasst (oder möglicherweise nicht kann), ist es oft besser, einen grundlegenden Anwendungsfall auszuwählen und dann zu iterieren. Darum geht es bei der iterativen Entwicklung! Wenn Sie User Stories verwenden, sollten Sie Ihre Funktionen sowieso iterativ , inkrementell und empirisch verbessern . Indem Sie einen interaktiven Ansatz verfolgen, können Sie sich darauf konzentrieren, Funktionen just-in-time und auf einem „ausreichend guten“ Qualitätsniveau zu erstellen, anstatt zu versuchen, eine komplexe Lösung mit großem Planungsaufwand im Voraus zu spezifizieren, der im Allgemeinen zu viele Einschränkungen mit sich bringt der Lösungsraum zu keinem nützlichen Zweck.
Richtig gemacht, sind User Stories nicht nur eine andere Art, altmodische Spezifikationen zu beschreiben. Sie stellen ein anderes Paradigma dar, das auf Zusammenarbeit und empirischer Kontrolle basiert, und erfordern eine grundlegend andere Art, über einen Problembereich nachzudenken.
Nutzen Sie User Stories als Konversationsstarter und Kurznotizen, um Ihre Zusammenarbeit zu fördern. Schreiben Sie keine detaillierten Geschichten für Dinge, die derzeit nicht im Umfang sind (YAGNI), sondern verbringen Sie die Zeit damit, die wirklich wichtigen Dinge während der Backlog-Verfeinerung und der Sprint-Planung zu zerlegen und zu identifizieren. Wenn ein bestimmtes Feature schließlich als Teil eines zusammenhängenden Sprint-Ziels in den Geltungsbereich kommt, wird es viel offensichtlicher, ob Sie das richtige Wer und Was in Ihren Geschichten haben, und das wird wiederum eine bessere Anleitung für das Entwicklungsteam sein, wenn es arbeitet wie man es im aktuellen Sprint umsetzt!
Willkommen bei PN.
Einer der einflussreichsten Personen auf dieser Welt (des Projektmanagements), Mike Cohn, schrieb darüber einen Artikel im Jahr 2015, den Sie unbedingt lesen sollten, mit dem Namen Not Everything Needs to Be a User Story: Using FDD Features . Einige seiner Artikel wurden verwendet, um Fragen innerhalb dieser Community gut zu beantworten, und es passt auch zu Ihrer.
Der Artikelname erwähnt die Lösung des Autors für solche Fälle, in denen der Benutzer zu weit entfernt ist - Feature-Driven Development (FDD) .
Wie der Autor schreibt
Ein FDD-Feature wird in diesem Format geschrieben:
[action] the [result] [by|for|of|to] a(n) [object]Betrachten Sie als Beispiele diese:
- Schätzen Sie den Schlusskurs der Aktie
- Generieren Sie eine eindeutige Kennung für eine Transaktion
- Ändern Sie den auf einem Kiosk angezeigten Text
- Führen Sie die Daten für doppelte Transaktionen zusammen
Sie haben bereits einige großartige Antworten, aber ich möchte nur etwas hinzufügen. Sie sagen, dass Ihre Geschichten:
sind nicht wirklich endbenutzerorientiert im herkömmlichen Sinne
Ich bin mir nicht sicher, ob dies bei allen Geschichten der Fall ist, die Sie auflisten.
Zum Beispiel:
Als Geschäftsinhaber möchte ich regelmäßige Datenbanksicherungen, damit wir die Geschäftskontinuität aufrechterhalten können
Ja, das ist wichtig für den Geschäftsinhaber, aber das liegt an den Auswirkungen, die es auf die Endbenutzer haben wird.
Du könntest es so umschreiben wie:
Als Endbenutzer möchte ich sicher sein, dass meine Daten geschützt sind, damit ich nicht den Zugriff auf das Produkt verliere oder meine Daten erneut eingeben muss
Ähnlich für:
Als Geschäftsinhaber möchte ich eine Endbenutzerauthentifizierung, damit nur registrierte Benutzer Zugriff haben
Auch Ihre Endbenutzer wollen einen sicheren Service. Dies könnte möglicherweise umgeschrieben werden als:
Als Endbenutzer möchte ich sicher sein, dass mein Konto sicher ist, damit niemand auf meine Informationen zugreifen oder unbefugte Änderungen vornehmen kann
User Stories sind ein Werkzeug, um Benutzerbedürfnisse zu verstehen und zu erfüllen. Ich könnte das letzte ändern, um zu sagen: "Als zahlender Benutzer möchte ich, dass meine Anmeldungen gesichert sind, damit mir keine Kosten für die unbefugte Nutzung meines Kontos in Rechnung gestellt werden."
Es gibt andere Mechanismen wie die Definition of Done für Qualitätsbelange wie Verfügbarkeit, Tests usw.
Außerdem erfordert Scrum keine Verwendung von User Storys. Wenn Sie also die Wiederherstellbarkeit hinzufügen möchten (auf die ich mich gegenüber dem Backup selbst konzentrieren würde), müssen Sie keine User Story verwenden, um dies zum Backlog hinzuzufügen.
Benutzer253751