Suchen und Finden
Service
Infos und Kontakt
Kapitel 4
User Stories (S. 51-52)
User Stories sind ein etabliertes und weit verbreitetes Konzept für die Beschreibung und das Management von Anforderungen in agilen Softwareprojekten. Im Vergleich zu traditionellen Mitteln des Anforderungsmanagements sind User Stories sehr viel unschärfer und offener formuliert. Sie lassen viel Raum für Änderungen und helfen dabei, ein System zu entwickeln, das der Kunde wirklich will, und nicht eines, das vor einem Jahr spezifiziert wurde.
User Stories beschreiben Anforderungen aus Sicht des Benutzers. Der sichtbare Teil einer User Story ist ihre Story-Karte, die den Kern der Anforderung in einem Satz beschreibt. Die Story-Karte dient im Wesentlichen als Platzhalter für die spätere Konversation zur User Story. Denn genau hierauf kommt es an: Konversation ist der wichtigste Bestandteil einer User Story. Das bedeutet konkret, dass die Details und konkrete Ausprägung einer User Story erst während ihrer Entwicklung im Dialog zwischen Product Owner und Team geklärt werden.
Der Kommunikationsaspekt einer User Story ist etwas, das viele Entwicklungsteams noch nicht ausreichend verstanden haben. Vielfach werden User Stories als eine Art moderne Use Cases der agilen Softwareentwicklung verstanden. Use Cases liefern zwar, ähnlich wie User Stories, einen konkreten Geschäftswert, sind aber von vornherein wesentlich vollständiger und genauer spezifiziert, als User Stories.
Die Unvollständigkeit von Stories ist Teil ihres Konzepts. User Stories akzeptieren den Umstand, dass Benutzer und Kunden erst relativ spät wissen, was sie wollen, nämlich erst dann, wenn sie Teile des Systems kennengelernt und ausprobiert haben. Sowohl dem Team als auch dem Kunden muss klar sein, dass eine User Story zunächst etwas sehr Vages ist, was aber umso konkreter wird, je näher die Story an ihre eigentliche Umsetzung rückt und erst während der Entwicklung sehr konkret wird. Das entscheidende Mittel hierfür ist die Kommunikation, das heißt das Gespräch über die User Story.
Dieses Kapitel führt in das Konzept von User Stories ein, beschreibt deren Aspekte und Eigenschaften und erklärt, was gute Stories sind und wie man sie schreibt. Des Weiteren wird begründet, weshalb sich User Stories so gut für die agile Softwareentwicklung und insbesondere für Scrum eignen.
4.1 Was sind User Stories?
Eine User Story beschreibt eine Anforderung an ein Softwaresystem. Die Anforderung besitzt einen konkreten und sichtbaren Mehrwert für den Kunden. Die User Story ,,Als Coach will ich mein Profil einstellen" besitzt einen solchen Mehrwert. Wenn die Story implementiert wird, verfügt das System über eine neue Funktionalität, die den Geschäftswert der Anwendung erhöht. Ein Gegenbeispiel ist die Anforderung ,,Die Software soll in Java programmiert werden". Dies ist keine User Story, da es dem Kunden keinen Mehrwert im Sinne seines Gesch¨aftsmodells liefert, wenn die Anwendung in Java programmiert wird.
Ein weiteres wichtiges Merkmal einer User Story ist ihre Bedeutung für den Kunden. Die Story muss für den Kunden eine Bedeutung im Kontext seines Geschäftsumfelds besitzen. Beispielsweise hat die Anforderung ,,Die Anwendung muss auf zwei Applikationsservern laufen" keinerlei Bedeutung für den Kunden im Sinne seines Kerngeschäfts. Natürlich ist es wichtig, dass die Anwendung ausfallsicher läuft. Aber eben nicht als Geschäftswert an sich, und deshalb ist die Anforderung keine User Story.
Den Begriff User Story kennen viele Entwickler. Einer weit verbreiteten Meinung nach ist eine User Story eine handgeschriebene Karte mit Informationen zur umzusetzenden Anforderung.
Alle Preise verstehen sich inklusive der gesetzlichen MwSt.; Ersparnis im Vergleich zur Printversion





















