Eine der größten Herausforderungen in der Softwareentwicklung ist die nahezu unmögliche Aufgabe, klare Anforderungen zu sammeln und diese Anforderungen dann während der Codeentwicklung unverändert zu lassen. Im Waterfall-Ansatz zur Softwareentwicklung-trotz der Bemühungen, jede mögliche Kontingenz vor Beginn der Entwicklung zu definieren, zu dokumentieren und zu genehmigen—ist das gelieferte Produkt selten das, was der Kunde will.
Die agile alternative? Erstellung von User Story.,
Einer der größten Vorteile eines agilen Ansatzes für die Softwareentwicklung besteht darin, dass die Anforderungen nicht in Stein gemeißelt sind, sondern sich voraussichtlich mit ständigem Feedback von Stakeholdern und Unternehmen ändern werden. Agile Methoden wie Scrum und Extreme Programming (XP) ersetzen traditionelle, langwierige Anforderungsdokumente durch einen priorisierten Produktrückstand, der aus prägnanten User Stories besteht, deren Details näher an der Implementierungsbereitschaft der Story liegen.,
Obwohl die Erstellung von Benutzergeschichten mehr Kunst als Wissenschaft ist, enthält dieses Tutorial Informationen, Beispiele und Schritte, die Sie zum Erstellen hochwertiger Benutzergeschichten benötigen.
Die Geschichte der User Stories
XP führte 1998 erstmals das Konzept der User Stories ein und verglich sie mit Anwendungsfällen. In Object-Oriented Software Engineering: A Use Case Driven Approach, Ivar Jacobson eingeführt use-cases als eine Möglichkeit zur Dokumentation von Anforderungen durch die Definition von Interaktionen zwischen einer Rolle (eine person, die mit dem system) und das system selbst, um ein Ziel zu erreichen mit Hilfe der Unified Modeling Language (UML).,
Dieser Ansatz war in der objektorientierten Entwicklung beliebt und wird immer noch als Schlüsselprozess in Softwareentwicklungsframeworks wie dem Unified Process (UP), dem IBM Rational Unified Process (RUP) und der Oracle Unified Method (OUM) verwendet. Die Verwendung von Anwendungsfällen anstelle von User Stories ermöglicht eine iterative und inkrementelle Entwicklung und wird als agiler Ansatz für die Definition von Anforderungen angesehen.,
Mit der Einführung der wesentlich kürzeren User Stories und der Beliebtheit von XP und Scrum wurde ein Produkt-Backlog aus User Stories zum bekannteren Ansatz zur Definition agiler Anforderungen. Viele Praktiker denken immer noch, dass User Stories der einzig akzeptable agile Ansatz sind. Alistair Cockburn, einer der Unterzeichner des Agilen Manifests, bevorzugt jedoch Anwendungsfälle gegenüber User Stories.
Obwohl es viele starke Meinungen über die Bedeutung von „agile“ gibt, sind sowohl Anwendungsfälle als auch User Stories mit diesem Ansatz kompatibel., Einige sagen, User Stories ähneln sich schließlich den Anwendungsfällen, sobald das Team den Details der Implementierung zustimmt. In den frühen Stadien, die User Story ist einfach ein kurzer Satz, aber es ist nicht vollständig, bis die Details und Akzeptanzkriterien definiert sind.
Erstellen von User Stories
Es gibt unterschiedliche Meinungen über die Definition einer User Story und wie man am besten eine erstellen kann., Einige Richtlinien für eine gute User Story sind die folgenden:
- Es sollte von jemandem geschrieben werden, der geschäftliche Benutzer vertritt (normalerweise der Product Owner)
- Es sollte zunächst kurze Beschreibungen des „Wer, Was und warum“ enthalten, aber nicht das „Wie“
- Es sollte ein vertikales Stück Arbeitscode erzeugen
- Es sollte klein genug sein, dass es in einer Iteration codiert und getestet werden kann (normalerweise ein Zeitraum von ein bis vier Wochen)
Verschiedene Vorlagen, Techniken und Akronyme werden verwendet, um Produktbesitzern beim Schreiben von User Stories zu helfen., Drei der häufigsten Techniken sind die Rollen-Feature-Reason-Vorlage, die drei C ‚ s (Karte, Konversation, Bestätigung) und INVEST (unabhängig, verhandelbar, wertvoll, schätzbar, klein, testbar).
Beispiele
Angenommen, Sie entwickeln eine Anwendung, mit der Trainer Kursunterlagen hochladen und Schüler anziehen können, die an einer Klasse interessiert sind. So würden Sie User Story-Techniken anwenden.,
Role-Feature-Reason
Wie Mike Cohn von Mountain Goat Software erklärt, sieht die Role-feature-Reason-Vorlage oder RGB (role, goal, benefit) ungefähr so aus:
„Als ich so will .“
Obwohl es Variationen gibt, konzentriert sich diese kurze Satzstruktur auf das Wer, Was und Warum. Dies verhindert, dass der Product Owner dem Entwicklungsteam zu viele Informationen darüber gibt, wie er eine Lösung implementieren soll. Durch die Fokussierung auf das Wer, Was und Warum ist das Entwicklungsteam befugt, die beste technische Lösung zu finden.,
Beispiel 1: Einem Trainer die Möglichkeit geben, einen Kurs hinzuzufügen
Als Trainer möchte ich einen neuen Kurs hinzufügen können, damit ich das Potenzial habe, neue Studenten anzuziehen.
Beispiel 2: Bieten Sie einem Studenten die Möglichkeit, nach einem Kurs zu suchen
Als Student möchte ich in der Lage sein, die Kursangebote zu durchsuchen, damit ich ein Angebot finden kann, das mich am meisten interessiert.
Die Rolle (who)
Die Rolle beschreibt, wer von dieser Funktion profitieren wird. Beachten Sie, dass die Rolle nicht einfach „der Benutzer“ ist.,“Es gibt verschiedene Arten von Benutzern, und daher möchten wir, dass die Rolle spezifischer ist als „Benutzer“, aber beschreiben Sie den Benutzertyp, der von der Geschichte profitiert. Produktbesitzer haben oft die Aufgabe, ihren Benutzern in den Sinn zu kommen, um zu verstehen, was für sie am wertvollsten wäre.
Beispiel 1 Rolle = Trainer
Beispiel 2 Rolle = Student
Das Feature (was)
Dieser Schritt beschreibt sehr kurz, was der Benutzer will. Dies stellt am ehesten die Anforderung dar, die Sie in der traditionellen Softwareentwicklung beschreiben., Sie möchten jedoch darauf achten, nicht zu spezifisch zu sein oder zu beschreiben, wie der Code geschrieben wird. Das wird schließlich bestimmt, aber nicht, wenn Sie zuerst die User Story erstellen. Die User Story sollte aus der Perspektive des Benutzers geschrieben werden, der von der Funktion profitiert, nicht aus der Perspektive des Entwicklers, der sie codiert.
Beispiel 1 Feature = Fügen Sie einen neuen Kurs hinzu
Beispiel 2 Feature = Durchsuchen Sie die Kursangebote
Der Grund (warum)
Schließlich möchten wir angeben, warum der Benutzer diese Funktion möchte. Welchen Wert erhält der Benutzer davon?, Dies hilft dem Product Owner zu bewerten, wie die User Story im Backlog priorisiert werden kann. Wenn der Wert oder Nutzen nicht artikuliert werden kann, ist dies möglicherweise nicht erforderlich. Das Verständnis des Wertes hilft dem Entwicklungsteam oft dabei, innovative Wege zur Implementierung des Codes zu finden, um das Ziel zu lösen—Wege, die sich von denen des Product Owners unterscheiden können.,
Beispiel 1 Grund = neue Studenten anziehen
Beispiel 2 Grund = Finde ein Angebot, das mich am meisten interessiert
Die drei C ’s: Karte, Konversation, Bestätigung
Die von Ron Jeffries entwickelte Three C‘ s-Formel hilft, eine Einigung zwischen dem Unternehmen und dem technischen Team über die Bedeutung der User Story zu erzielen. Die drei C ‚ s führen sie durch die fortschreitende Ausarbeitung einer Geschichte, von einer kurzen Erklärung zu einer voll entwickelten User Story.,
Karte
Die Benutzergeschichte beginnt absichtlich kurz, mit einer einfachen Aussage, die auf eine 3×5-Karteikarte passen könnte, normalerweise nach dem Rollenspiel-Nutzen-Format, das ich gerade behandelt habe. Zum Beispiel:
Als Trainer möchte ich einen neuen Kurs hinzufügen können, damit ich das Potenzial habe, neue Studenten anzuziehen.
Konversation
Obwohl die User Story als einfache Anweisung beginnt, müssen Details entstehen, bevor das Team mit der Arbeit an der Story beginnt., Anstatt zu beschreiben, was in der Dokumentation benötigt wird, enthält das Team 1) Repräsentation des Unternehmens (normalerweise des Product Owners) und 2) das Entwicklungsteam selbst, einschließlich Entwicklern, Testern, Geschäftsanalysten oder anderen Personen im Team.
Dieses Gespräch ermöglicht es dem Entwicklungsteam, Fragen zu stellen, um sicherzustellen, dass sie ein klares Verständnis dafür haben, wonach gefragt wird und welcher Wert bereitgestellt wird. Zum Beispiel:
Entwickler: Muss der Trainer die Kursunterlagen auf eine Website hochladen?,
Product owner: Nein, der Trainer fügt nur Informationen zu dem Kurs hinzu, der angeboten wird, und die Funktion sollte eine Möglichkeit für den Schüler enthalten, auf eine Interessenliste zu gelangen. Diese Geschichte gibt dem Trainer die Möglichkeit, einen Kurs zu bewerben.
Entwickler: Welche Felder sollten enthalten sein?
Produkt-Besitzer: Natürlich Titel, Beschreibung, Datum und Uhrzeit, Ort.
Entwickler: Wird dies nur für die Werbung von Angesicht zu Angesicht Klassen sein?
Produkt-Besitzer: ja., Wir können später eine virtuelle Klassenoption hinzufügen, Aber diese Geschichte behandelt nur das Hinzufügen von Kursinformationen für persönliche Klassenangebote.
Entwickler: Welche Informationen sollten gesammelt werden, wenn ein potenzieller Student nach einer Interessenliste fragt?
Produkt: Eigentümer: Name, Telefonnummer und E-Mail-Adresse.
Das Team aktualisiert die Benutzerstory mit den Informationen, die sie aus der Konversation gesammelt haben, und diskutiert die Implementierung—oder das „Wie“—, wodurch häufig bestimmte Aufgaben erstellt werden, die ausgeführt werden müssen, um die Geschichte abzuschließen., Obwohl die User Story aus der Sicht des Benutzers geschrieben wird, schreibt das Entwicklungsteam die Aufgaben für die Entwickler und enthält die technischen Implementierungsdetails.
Bestätigung
Das Entwicklungsteam muss ein klares Verständnis dafür haben, wie die Funktion in verschiedenen Situationen funktioniert, einschließlich Fehlerbedingungen. Sie müssen eine Bestätigung bezüglich der Akzeptanzkriterien vom Product Owner erhalten. Dies sind die Kriterien, die erfüllt sein müssen, damit die Geschichte als erledigt und akzeptiert gilt., Hier ist ein Beispiel für Akzeptanzkriterien:
- Ein Trainer kann einen neuen Kurs hinzufügen, indem er Kurstitel, Zusammenfassung, Datum und Uhrzeit sowie Ort in ein Formular eingibt und auf die Schaltfläche „Kurs hinzufügen“ klickt.
- Wenn Felder fehlen oder Daten oder Zeiten ungültig sind, werden Fehlermeldungen angezeigt.
- Sobald der Kurs ordnungsgemäß hinzugefügt wurde, wird er öffentlich auf der Kurswebsite angezeigt und es wird eine Schaltfläche für einen Studenten angezeigt, um Interesse auszudrücken.,
- Mit der Schaltfläche Interesse kann ein Benutzer Name, E-Mail-Adresse und Telefonnummer eingeben, und diese Daten werden gespeichert und mit dem neuen Kurs verknüpft.
INVEST: Die Attribute einer soliden User Story
INVEST ist ein Akronym, mit dem Sie beurteilen können, ob Sie eine qualitativ hochwertige User Story haben. So gelten die Attribute im Akronym für die Geschichte, an der wir gearbeitet haben.
I = Independent-Kann diese Geschichte vom Team vervollständigt werden? Wir möchten, dass das Team die ganze Geschichte abschließen kann, anstatt beispielsweise von einem anderen Team abhängig zu sein, um die GUI auszuführen.,
N = Verhandelbar – Die Geschichte ist nicht so detailliert, um genau zu beschreiben, wie lange die Felder sein sollten, oder um Einzelheiten zu Datumsformaten und dergleichen anzugeben. Höchstwahrscheinlich wird es gängige Routinen oder Bibliotheken geben, die es dem Entwicklungsteam ermöglichen, sie so zu implementieren, wie es für sie am sinnvollsten ist.
V = Wertvoll-Der Product Owner beschreibt, dass der gesuchte Wert die Fähigkeit des Trainers ist, für kommende Klassen werben zu können. Dies wird im „Warum“ der ursprünglichen Aussage deutlich und im Gespräch erneut betont.,
E = Schätzbar – Das Team wird genügend Fragen stellen und die Details sammeln, um sich in ihrer Fähigkeit, die Geschichte zu schätzen, sicher zu fühlen.
S = Small – Das Team muss sich sicher fühlen, dass es die Story innerhalb eines Sprints abschließen kann. Wenn sie dies nicht tun, könnten sie die Geschichte teilen. Zum Beispiel können sie in unserer Beispielgeschichte beschließen, die Fähigkeit, die Schülerinformationen zu sammeln, zu einer anderen Geschichte zu machen und einfach Informationen über die Klasse für diese Geschichte anzuzeigen.
T = Testbar—Mit klaren Abnahmekriterien können sowohl der glückliche Weg als auch die Fehlerbedingungen getestet werden.,
Ausrichtung an einer Vision
Ich habe die Grundlagen der Erstellung einer User Story behandelt, aber Sie müssen immer noch das Gesamtbild verstehen, bevor Sie Ihre eigenen User Stories erstellen. Es gibt viel Arbeit, die Sie im Voraus tun müssen, auf einer höheren Ebene, um zu bestimmen, was die hochwertigsten Funktionen sind, die an die Kunden geliefert werden sollten. Diese werden letztendlich in User Stories zerlegt.
Es ist wichtig, dass das Team zuerst die Vision auf hoher Ebene versteht und sicherstellt, dass die Funktionen und letztendlich die Benutzergeschichten auf diese Vision auf hoher Ebene abgestimmt sind.,
Normalerweise zerlegen Sie das Produkt in Gruppierungen, die nach Namen wie „themes“ oder „features.“Obwohl die Kennzeichnung dieser Backlog-Elemente je nach agiler Methode und Tools, mit denen Sie sie beschreiben, unterschiedlich sein kann, besteht die Idee darin, sicherzustellen, dass sie so ausgerichtet sind, dass die Arbeit auf Ihre Vision zurückgeführt werden kann, um sicherzustellen, dass Sie die Ziele und Werte der Produktvision erreichen.
Starten Sie erneut kein Projekt, indem Sie User Stories erstellen. Beginnen Sie mit der Erstellung einer Vision., In unserem Beispiel zeige ich einfach eine Beispiel-Vision-Anweisung, die zu einigen Beispielfunktionen führt, die weiter in User Stories zerlegt werden können.
Vision
Bieten Sie eine qualitativ hochwertige Website, auf der Trainer für Kurse werben und Studenten diese Kurse belegen können.
Eigenschaften
- Stellen Sie eine Seite für das Kursangebot bereit, auf der sich die Schüler für Kurse anmelden können.
- Stellen Sie eine Homepage bereit, auf der Benutzer erfahren, worum es auf unserer Website geht.
- Stellen Sie einen Registrierungsprozess bereit, der es Benutzern ermöglicht, sich anzumelden, ein Profil zu erstellen und ihre Klassen zu verfolgen.,
- Stellen Sie einen Blog zur Verfügung, mit dem Sie für unsere Angebote werben und Werbung für unsere Website machen können.
User Stories
- Bietet Trainer die Möglichkeit, einen Kurs auf der Seite Kursangebot hinzuzufügen.
- Bietet Studenten die Möglichkeit, nach einem Kurs zu suchen.
Im obigen Beispiel können Sie sehen, wie die User Stories entstanden sind. Die User Stories waren Teil einer Funktion, um „eine Kursangebotsseite bereitzustellen“, die sich an der Vision auf hoher Ebene ausrichtet.,
Impact Mapping
Obwohl das Ausrichten an einer Vision Ihnen hilft, Ihren anfänglichen Backlog zu füllen, ist dies nicht der einzige Weg. Es gibt viele Tools und Techniken, mit denen Produktmanager die Storys erstellen können, die sich in einem neuen Backlog befinden und mit der Vision übereinstimmen.
Eine strategische Planungstechnik zum Verständnis des Gesamtbildes, Impact Mapping, wurde von Gojko Adzic, Autor von Fünfzig schnellen Ideen zur Verbesserung Ihrer User Stories und Impact Mapping, populär gemacht: Mit Softwareprodukten und-projekten eine große Wirkung erzielen., Impact Mapping ist eine Mindmap, die mit dem Ziel beginnt und die Frage nach dem Wert und dem Grund, warum Sie das Produkt erstellen, ansprechen sollte.
Die nächste Ebene listet die „Schauspieler“ oder Personen auf, die beim Erreichen des Ziels helfen. Als nächstes listet die Karte die Verhaltensweisen oder „Auswirkungen“ auf, die die Akteure ausführen, um dieses Ziel zu erreichen. Die letzte Ebene der Karte zeigt die „Ergebnisse“, die das Team implementieren kann. Diese ermöglichen und unterstützen die Akteure, die gewünschten Auswirkungen zu erzielen. Aus diesen Ergebnissen leiten Sie die Softwarefunktionen und-geschichten ab.,
- Ziel: Stellen Sie weit verbreitete Kurse zur Verfügung, an denen die Schüler teilnehmen möchten
- Akteure: Trainer, Schüler
- Auswirkungen: Trainer bieten qualitativ hochwertige Klassen an, die für die Schüler von Interesse sind; Schüler geben Empfehlungen und Empfehlungen
- Ergebnisse: Hochwertige Klassen, die für die Schüler zugänglich sind
- Potenzielle Geschichten:
- „Als Trainer möchte ich für den Unterricht werben, damit ich die Schüler erreichen kann.
- „Als Trainer möchte ich Feedback von den Schülern bekommen, damit ich mich kontinuierlich verbessern kann.,“
- “ Als Trainer möchte ich herausfinden, was die Schüler wollen, damit ich meinen Lehrplan erweitern kann.“
- “ Als Student möchte ich Klassen finden, die mich am meisten interessieren.“
- “ Als Student möchte ich Kurse finden, die ich online belegen kann, damit ich nicht reisen muss.“
- “ Als Student möchte ich Bewertungen von anderen lesen, damit ich entscheiden kann, welche Klassen am besten zu mir passen.“
Die Zuordnung von User Stories auf diese Weise ermöglicht die Rückverfolgbarkeit in den Denkprozess, wie die Stories letztendlich einen Wert schaffen und wie Sie sie verwenden, um das Endziel zu erreichen., Die Idee ist nicht, alles zu implementieren, sondern den kürzesten Weg durch die Karte zu finden, um Ihr Ziel zu erreichen.
Geschichten aufteilen
Eines der häufigsten Probleme, auf die agile Teams stoßen, ist, wenn Geschichten zu groß sind und nicht in einer Iteration abgeschlossen werden können. Wenn das Team die mit der Story verbundenen Aufgaben erstellt, stellt es fest, dass zu viele Unbekannte vorhanden sind oder dass die damit verbundenen Aufgaben mehr Zeit in Anspruch nehmen, als das Team in einer einzigen Iteration zur Verfügung hat. Teams sprechen dies manchmal an, indem sie eine größere Geschichte in kleinere Geschichten aufteilen.,
Denken Sie jedoch daran, dass Sie möchten, dass eine User Story eine funktionierende Software liefert, die dem Benutzer einen Mehrwert bietet. Anstatt eine User Story zu erstellen, die eine Funktion nur teilweise vervollständigt, teilen Sie Storys in „vertikale Slices“ auf, die eine End-to-End-Funktionalität bieten.
Wenden Sie sich an die Community, um tiefer zu lernen
Detaillierte Lösungen zur Lösung der schwierigsten Probleme in Bezug auf Anforderungen und User Stories sind für jede Situation einzigartig. Ein gemeinsames Merkmal erfolgreicher agiler Praktizierender ist jedoch, dass sie anderen helfen und teilen möchten, was sie wissen.,
Die Website von Cohn ‚ s userStories ermöglicht es denjenigen, die mit Produkt-Backlogs und User Stories arbeiten, Produkte, Ressourcen und Wissen auszutauschen. Die Produktseite enthält eine beeindruckende Liste von Tools, von denen viele kostenlos verfügbar sind, mit Möglichkeiten für Benutzerbewertungen und Eingaben. Cohn stellt auf der Website fest, dass er hofft, die Website zu erweitern, damit die Produkt-Backlogs geteilt werden können.
Es wird nie eine One-size-fits-all-Antwort geben, wie man perfekte User Stories schreibt., Mit einer gesunden Mischung aus Erfahrung, Ratschlägen von Experten und Experimenten mit vorgeschlagenen Tools und Techniken können Sie sich jedoch im Laufe der Zeit kontinuierlich verbessern.