WikiDer > Benutzer Geschichte

User story

EIN Benutzer Geschichte ist eine kurze Beschreibung (Geschichte) dessen, was ein Benutzer (Benutzer) will. User Stories werden bei der Entwicklung verwendet Software oder Produkte. Eine User Story besteht aus wenigen Sätzen der gemeinsamen Sprache des (Computer-)Benutzers, die angeben, was der Benutzer im Rahmen seiner Arbeit tut oder tun muss. User Stories werden innerhalb von . verwendet agil Softwareentwicklung als Weg Anforderungen beschreiben. In diesem sagt man 'wer', 'was', 'warum' will. Das ganze ist nicht sehr detailreich und muss auf einen passen veröffentliche es. Es ist der Haupteinfluss des Benutzers auf die Funktionalität des zu entwickelnden Systems oder Produkts.

User Stories können auch von Entwicklern geschrieben werden, um nicht-funktionale Anforderungen zu erfassen, beispielsweise im Bereich Sicherheit, Qualität und Performance,[1] Hauptverantwortlich für die Sammlung der User Stories ist jedoch der Product Owner.

Beispiele

Als Benutzer möchte ich meine Kunden sowohl nach Vornamen als auch nach Nachnamen suchen können.
Programmstart
Zu Beginn des Programms wird das Dokument angezeigt, mit dem der Benutzer zuletzt gearbeitet hat.
Programm anhalten
Beim Schließen des Programms wird der Benutzer gefragt, ob er seine Arbeit speichern möchte.

Benutzen

User Stories werden in vielen agilen Entwicklungsmethoden verwendet, wie z XP und Gedränge. User Stories bestimmen, was in Softwareprojekten gemacht wird. Vom User / Product Owner / Kunden werden die User Stories nach Wichtigkeit sortiert, dann in Aufgaben zerlegt und von den Entwicklern mit genaueren Zeitschätzungen versehen.

Leistungen

XP und andere agile Entwicklungsmethoden bevorzugen eine persönliche Kommunikation und eine verständliche Dokumentation, die schnell angepasst werden kann, anstatt sich auf das Problem zu konzentrieren.

User Stories helfen dabei:

  • Sie sind sehr kurz. Sie enthalten Dinge, die in kurzer Zeit hergestellt werden können, eher in Tagen als in Wochen.
  • Sie benötigen wenig Wartung.
  • Sie ermöglichen es, Projekte in kleine Teile zu zerlegen.
  • Sie eignen sich sehr gut für Projekte, bei denen sich die Anforderungen und Wünsche ständig ändern oder schlecht verstanden werden.
  • Sie machen es einfacher, die benötigte Zeit abzuschätzen.
  • Um sie zu schreiben, ist es notwendig, dass die Benutzer in das System eingebunden werden, damit auch die aus Benutzersicht wertvollsten Dinge realisiert werden.

Geschichtenkarten

Story-Karte

Eine Story-Map[2] ist die grafische Darstellung des Product Backlogs. Oben befinden sich die wichtigsten User Stories, die manchmal auch als "Epics" bezeichnet werden. Die Stories sind in der Reihenfolge gruppiert, in der Sie einem Fremden das System erklären würden. Vertikal, unterhalb der Epics, sind die User Stories auf ihren Karten der Reihe nach aufgelistet von Bedeutung Die erste waagerechte Reihe ist ein sogenanntes "wandelndes Skelett"[3], darunter wird es feiner.[4]

Auf diese Weise ist es sogar möglich, große Systeme zu beschreiben, ohne den Überblick zu verlieren.

Siehe auch

Verweise

  • Daniel H. Steinberg und Daniel W. Palmer: Extreme Softwareentwicklung, Pearson Education, Inc., ISBN 0-13-047381-2
  • Mike Cohn, "Angewandte Benutzergeschichten", 2004, Addison Wesley, ISBN 0-321-20568-5
  • Mike Cohn: Agiles Schätzen und Planen, 2006, Prentice Hall, ISBN 0-13-147941-5
  1. ↑Davies, Rachel, Nicht-funktionale Anforderungen: Helfen User Stories wirklich?. Abgerufen am 12. Mai 2011.
  2. ↑Patton, Jeff, Das neue User Story Backlog ist eine Landkarte. Zugriff am 23. Juni 2017.
  3. ↑Cockburn, Alistair, Gehendes Skelett. Aufgerufen am 4. März 2013.
  4. ↑Story-Mapping. Agile Allianz. Aufgerufen am 4. März 2013.