Agil entwickeln, wissen wie
Im Mittelpunkt der agilen Softwareentwicklungsmethodik stehen zeitlich begrenzte Projektzyklen, die als Sprints bezeichnet werden. Ein Sprint ist ein kurzer Zeitraum, in der Regel zwei Wochen, in dem das Team an einer bestimmten Anzahl von Funktionen, den so genannten "User Stories", arbeitet. Diese Geschichten sind Elemente, die das Team in zwei Wochen liefern kann. Der Sprint besteht also aus einer wesentlich geringeren Anzahl von Funktionen als ein Wasserfallprojekt. Die Begrenzung der Funktionen auf diese Weise sorgt für einen überschaubaren Produktentwicklungs- und Veröffentlichungszyklus.
.jpeg)
User-Stories
Als Agil-getriebenes Team nutzen wir sie aktiv, um ein besseres Verständnis dafür zu bekommen, welchen Nutzen die Produkte unserer Kunden ihren Endnutzern bringen oder bringen sollten. Sie fördern auch die Zusammenarbeit und die Kreativität und treiben uns zu nicht-trivialen Entwicklungslösungen.
Heute möchten wir unser Wissen und unsere Erfahrung zu diesem Thema mit dir teilen, um die Wichtigkeit der User-Stories hervorzuheben und worauf man beim Schreiben von User-Stories achten sollte.
Was sind User-Stories?
User Stories sind eines der Kernelemente der agilen Methodik. Sie werden jedoch oft mit Softwareanforderungen verwechselt, was nicht stimmt. Was also ist eine User Story?
Eine User Story ist ein kleines (eigentlich das kleinste) Stück Arbeit, das einen gewissen Wert für einen Endbenutzer darstellt und während eines Sprints geliefert werden kann.
Das Hauptziel dieses Elements besteht darin, die Endbenutzer in den Mittelpunkt der Konversation zu stellen und die Produktfunktionalität aus ihrer Sicht zu erfassen. So erhalten die Entwickler ein besseres Verständnis dafür, was, für wen und warum sie entwickeln.
Gute User Stories erfüllen immer die INVEST-Kriterien von Bill Wake:
Independant - sie können in beliebiger Reihenfolge entwickelt werden. Änderungen an einer User Story wirken sich nicht auf die anderen aus.
Negotiable - das Team kann entscheiden, wie sie umgesetzt werden, somit gibt es keinen starr festgelegten Arbeitsablauf.
Valuable - jede User Story liefert den Endbenutzern dem Product Owner oder Endnutzer einen Wert.
Estimable - es ist einfach abzuschätzen, wie viel Zeit die Entwicklung einer User Story in Anspruch nehmen wird.
Small - sie sollte den gesamten Zyklus (Design, Kodierung, Testen) während eines Sprints durchlaufen.
Testible - es sollte klare Akzeptanzkriterien geben, um zu prüfen ob eine User Story angemessen implementiert ist.
Das User Story-Format (das auch vom Techwerk-Team verwendet wird) ist daher recht einfach und kurz:
Als [Nutzertyp- Gruppe] möchte ich [eine Handlung/Feature], damit [ein Nutzen/Wert] entsteht oder Eintritt.
Hier sind ein paar Beispiele für User-Stories, die zu einer erfundenen Taxi-App passen:
Als Taxifahrer möchte ich Fahrgäste die sich schlecht benommen haben sperren, damit sie mir nie wieder gezeigt werden.
Als Fahrgast möchte ich die ausgewählte Zahlungsmethode mit meinem Profil verknüpfen, damit ich künftig schneller, einfacher und ohne Bargeld meine Fahrt bezahlen kann.
Als Taxifahrer möchte ich Fotos von meinem Auto in mein Profil einfügen, und dem Fahrgast höchstmögliche Transparenz zu bieten.
Als Fahrgast möchte ich, dass mehrere verfügbare Taxifahrer angezeigt werden, damit ich die für mich am besten geeignete Option auswählen kann.
Das Schreiben von User Stories hört sich zwar ganz unkompliziert an, aber sie birgt auch Herausforderungen.
Wir werden später auf unsere bewährten Tipps und Erfahrungen eingehen, die dir helfen können gute User Stories zu schreiben.
Obwohl wir gerade herausgefunden haben, dass Agile User Stories unabhängig sind und als völlig separate Arbeitseinheiten verstanden werden sollten, werden sie manchmal in Epics zusammengefasst. Wenn du mit User Stories arbeitest, wirst du wahrscheinlich auf das Konzept eines Epic stoßen.
Was sind Epics?
Ein Epic ist eine übergeordnete Ebene, welches mit einer Gruppe von verwandten Stories verbunden ist.
Wir bei Techwerk verwenden Epics, um komplexere Aufgaben zu beschreiben und eine klare Hierarchie zu schaffen, die es ermöglicht, die Entwicklung einfacher zu verwalten und dem Product Owner einen neuen Wert zu liefern, während wir auf ein größeres Ziel hinarbeiten. Das Format der User Story selbst bleibt nach wie vor gleich.
Epics geben uns also einen Überblick über unsere Ziele und wie wir uns diesem nähern. Sie helfen uns auch bei der Prioritätensetzung, da wir überprüfen und tracken können, welche Epics unsere Aufmerksamkeit am meisten erfordern und welche Stories daher zuerst umgesetzt werden sollten.
Zu guter Letzt:
User Storys müssen Akzeptanzkriterien beinhalten, die uns ein tieferes und besseres Verständnis der Abnahmebedingungen vermitteln, da sie wichtige Informationen darüber enthalten, wie Stories funktionieren. Bleiben wir bei dem Beispiel und den User Storys der Taxi-App:
Die App zeigt Taxifahrer an, die in den letzten 20 Minuten online waren und keine aktuelle Fahrt haben.
Die App zeigt nur fünf Taxifahrer an, die dem Fahrgast am nächsten sind.
Der Fahrgast kann sich die Profile dieser Taxifahrer ansehen, einschließlich ihrer Fotos und Preise.
Wie wir sehen, kennen wir jetzt nicht nur das Ziel dieser User Story für die Nutzer, sondern auch einige Merkmale, die bei der Implementierung beachtet werden soll. Selbstverständlich steht es immer frei zu entscheiden wie detailliert die Abnahmekriterien beschrieben werden sollen. Sie können von "just get it done" bis hin zu noch detaillierteren Kriterien als im obigen Beispiel reichen.
Das hängt stark meistens vom Product Owner oder Entwicklungsteam ab. Wenn das Team eine Anleitung und klare Anweisungen braucht, die keinen Raum für Interpretationen zulässt, ist es sinnvoll detaillierte Abnahmekriterien zu definieren.
Jetzt haben wir einiges über User Stories erfahren.
Aber warum sind sie für agile Entwicklerteamssie so wichtig?
Insbesondere Scrum-Teams lieben User Stories und nutzen sie aktiv um Schätzungen vorzunehmen, Prioritäten zu setzen und Sprints zu planen, was uns dabei hilft, agil und flexibel auf Änderungen zu reagieren. Dies ist besonders dann von Vorteil, wenn wir mit Start-Ups arbeiten, die sich in der MVP-Phase befinden und nur begrenzte Ressourcen zur Verfügung haben, bevor sie ihr Projekt bei strategischen-Investoren vorstellen können.
Abgesehen von den oben genannten gibt es einige Vorteile, die für alle agilen Teams gelten:
I Sie konzentrieren intensiver auf das Projekt - Es hilft dem Team, das digitale Produkt nicht nur aus technischer Sicht gut zu entwickeln, sondern auch für die Endnutzer nützlich zu machen.
II Ermöglicht Kreativität - Da es nur die notwendigsten Informationen enthält, kann das Team kreative Ideen entwickeln, um die beste Lösung zur Umsetzung einer Story zu finden.
III Das Projekt wird überschaubarer - Wir bei Techwerk wissen, dass es viel einfacher ist, mit kleinen und abschätzbaren agilen User Stories zu arbeiten als mit großen, komplexen Aufgaben.
IV Sie inspirieren das Team! - Jeder Entwickler liebt das Gefühl eines kleinen Erfolgserlebnisses. Es motiviert und macht Laune kontinuierlich weiterzuarbeiten.
Conclusion
User Stories sind ein wesentliches Element des agilen Ansatzes mit vielen Vorteilen. Es ist jedoch wichtig, sie richtig zu (be)schreiben.
Beispiele für gute User Stories erfüllen die INVEST-Kriterien, das heißt, sie sind:
Independent
Negotiable
Valuable
Estimable
Small
Testable
Das übliche Muster für User Stories umfasst den Nutzer, die Aktion und das Ergebnis (oder den Nutzen) und sieht in der Regel wie folgt aus:
Als [Art des Benutzers/Rolle] möchte ich [eine Aktion], damit [ein Ergebnis/ein Nutzen] erzielen.
User Stories können dir helfen, den Wert Ihres digitalen Produkts ständig zu verbessern, den Entwicklungsaufwand richtig einzuschätzen und die Entwicklung von Funktionen in der MVP- und Post Launch-Phase zu priorisieren.
Du hast Fragen oder weitere Anregungen oder möchtest das nächste Projekt mit uns angehen?
Kontaktiere Uns und wir sprechen über dein/Euer Projekt.
