Unser prozess
User Story
Sowohl Use Cases als auch User Stories (User Storys) beziehen sich auf Benutzeranforderungen, die beschreiben, was die Benutzer mit einem System tun können.
Beispiel einer User Story
Der Anwendungsfall könnte wie folgt aussehen: "Buchhandlung - Kundenprofil aktualisieren".
In der Zwischenzeit würde die User Story wie folgt aussehen: "Als Kunde möchte ich mein Profil aktualisieren, damit künftige Einkäufe an meine neue Adresse geliefert werden." Es handelt sich um eine Art von Anwendererzählung. Es ist eine Struktur, ein spezifischer Aufbau. Dabei ist es wichtig zu berücksichtigen, dass die Nutzer unterschiedliche Bedürfnisse haben.
Wie wir sehen, geht die User Story über die Angabe des Ziels des Benutzers hinaus, da sie auch seine Beweggründe beschreibt.
Möchten Sie eine User Story erstellen?
Software: User Story vs. Akzeptanztest
User Stories ermöglichen Akzeptanztests (bezogen auf die Akzeptanzkriterien).
Der Zweck des Abnahmetests besteht nicht in der Aufdeckung von Fehlern, sondern in der Bestätigung der Ausführung von Software mit ausreichender Qualität.
So finden wir heraus, ob wir die Anforderungen, die der Kunde/Stakeholder an uns gestellt hat, erfüllen konnten.
Die Tests finden zu einem frühen Zeitpunkt der Arbeit statt und führen zu zufriedenstellenden Ergebnissen, unabhängig von der gewählten Methode.
Die User Story stützt sich eher auf die Akzeptanzkriterien als auf die schriftlichen Anforderungen, um die in der User Story enthaltenen Details zu bestimmen.
Während die Tester beurteilen, ob eine Anforderung korrekt umgesetzt wurde, können sie nicht sagen, was der Kunde/Stakeholder über die Software sagen wird.
Wenn wir feststellen, dass eine Anforderung geändert werden muss, müssen wir den Business Analysten darüber informieren.
Befolgen wir den für das Projekt definierten Prozess zur Kontrolle von Änderungen, der uns garantiert, dass Änderungen nicht übersehen werden und die Auswirkungen jeder einzelnen Änderung analysiert werden.
Was aber, wenn die nachfolgenden User Story zu umfangreich sind, um in einer einzigen Iteration umgesetzt zu werden? Wir unterteilen sie in kleinere Geschichten und setzen jede dieser Geschichten in separaten Iterationen um.
Bei der Erstellung von Benutzergeschichten sollten Sie auch die 3 C (3 C modell) der Benutzergeschichte im Auge behalten, nämlich Cards (Story Card, Story Cards), Conversasion und Confrimation.
Der Benutzer und seine Anforderungen. Das Problem mit den ursprünglichen Annahmen eines Projekts
Anforderungen sind eine Spezifikation dessen, was implementiert werden soll.
Sie beschreiben, wie sich das System verhalten soll, definieren seine Eigenschaften oder Attribute und können den Systementwicklungsprozess einschränken.
Es gibt noch weitere Definitionen von Benutzeranforderungen, aber die obige ist eine der genauesten.
Zu den Methoden, die Benutzeranforderungen darstellen, gehören Use Cases, User Story und Event-Response Tables.
Benutzeranforderungen beziehen sich auf die Ziele oder Aufgaben, die die Benutzer durch das Produkt erfüllen müssen.
Darüber hinaus beziehen sich die Anforderungen auch auf die Beschreibung von Produktattributen oder -merkmalen in Bezug auf die Erfüllung der Bedürfnisse der Nutzer.
Zur Darstellung der Benutzeranforderungen können wir unter anderem die User Story verwenden.
Die User Story hilft bei der Festlegung der endgültigen Prioritäten des Projekts, der endgültigen Software Features, aber sie müssen realistisch sein, denn nur so kann eine hohe Effizienz der Arbeit gewährleistet werden.
Dabei sollten wir nicht vergessen, wie wichtig die Meinung des Entwicklungsteams ist.
Es geht darum, realistische Ziele zu setzen. Achten Sie also darauf, wenn das Team sagt, dass es zum Beispiel unmöglich ist, eine Funktionalität in der geforderten Zeit zu erstellen.
Manchmal geht ein Projekt jedoch weit über die ursprünglichen Annahmen hinaus.
Dann müssen wir den Umfang reduzieren, den Zeitplan verlängern, zusätzliche Mittel bereitstellen oder mehr Leute finden, die die Arbeit erledigen.
User Story: Wie ermittelt man Benutzeranforderungen?
Um die Anforderungen des Benutzers zu ermitteln, sollten wir gemeinsam die Aufgaben definieren, die der Benutzer mit der Software zu erfüllen hat.
Es ist auch wichtig, die Ziele zu wählen, die er erreichen will. Anforderungen können nicht nur mit einer User Story, sondern auch mit Use Cases und Scenarios beschrieben werden.
User Story, Sammlung von Anforderungen und Iterationen
Bei der Entwicklung digitaler Produkte werden die Anforderungen während der gesamten Entwurfsphase der Lösung gesammelt, analysiert, detailliert und aktualisiert.
Dies ändert jedoch nichts an der Möglichkeit, dass der Produkteigentümer zu jedem Zeitpunkt, auch in der Entwicklungsphase, zu dem Schluss kommt, dass etwas anders gestaltet werden muss.
In einer solchen Situation führt der Unternehmensanalytiker eine Anforderungsaktualisierung durch, wobei seine Hauptaufgabe darin besteht, zu prüfen, wie sich die Änderung einer Anforderung auf andere Systemanforderungen auswirken kann.
Das Sammeln von Anforderungen kann auf viele Arten erfolgen.
Zu den beliebtesten Methoden gehören Workshops, Tiefeninterviews, die Analyse von Gesetzen und Normen, die den Markt regeln, die Analyse von Einschränkungen (z. B. technischer Art), die Beobachtung des Nutzerverhaltens (z. B. in Bezug auf das bestehende System, das wir ersetzen wollen), die Beobachtung und Prozessabbildung usw.
Der Business Analyst ordnet die erfassten Anforderungen in entsprechende Kategorien ein (funktionale Anforderungen, Qualitätsmerkmale, Geschäftsregeln) und entscheidet, ob die Anforderungen in die Vision des digitalen Produkts passen. Dann werden sie in so genannte Produktionsiterationen unterteilt.
Die Einteilung in Iterationen sollte auf intuitive Weise mit dem Product Owner erfolgen, der bestimmt, inwieweit eine bestimmte Funktionalität für die Benutzerfreundlichkeit und Attraktivität der Lösung wesentlich ist.
Wir können die Iterationen auch als Umsetzungsbereiche betrachten. Je größer die Spielräume sind, desto unschärfer werden sie.
Die gesammelten Anforderungen bilden die Grundlage für den IT Anforderungsanalysten, der die Anforderungen nach ihrer Umsetzungspriorität aufschlüsselt. Dies geschieht unter Mitwirkung des Geschäftsinhabers.
Es gibt viele Methoden der Priorisierung, wobei die gängigste die "MoSCoW" Methode ist, bei der alle Anforderungen in eine Vier-Punkte-Skala eingeteilt werden: "muss", "sollte", "könnte" und "wird nicht".
Auf dem Markt gibt es verschiedene Varianten dieser Methode, z. B. die Verwendung einer Drei-Punkte-Skala: "muss sein", "sollte sein", "schön zu haben".
Für die Bewertung der Prioritäten ist es nützlich, die wichtigsten Wettbewerbsvorteile des geplanten digitalen Produkts und die wichtigsten Funktionen sowie die geschätzten Kosten für die Umsetzung zu kennen.
Eine der fortschrittlicheren und sehr genauen Priorisierungsmethoden ist die "House of Quality"-Methode, über die wir demnächst einen eigenen Artikel im Zusammenhang mit der Produktion von Webanwendungen schreiben werden.
Sobald die Anforderungen nach Prioritäten geordnet sind, teilen wir sie in Produktionssprints ein, die ein vorher festgelegtes Budget und eine bestimmte Dauer haben können.
Das Problem der Bedarfsdeckung
Was führt dazu, dass die Zielnutzer der Anwendung mit dem IT System unzufrieden sind? Vielleicht sind wir auf einen ständig unzufriedenen Unzufriedenen gestoßen, aber das muss nicht so sein.
Das Problem liegt in der Erwartungslücke, d. h. in den Unterschieden zwischen dem, was die Nutzer tatsächlich brauchen, und dem, was umgesetzt wurde.
Eine solche Situation kann zum Beispiel eintreten, wenn wir mehr Wert darauf legen, die Bedürfnisse einer Gruppe von Interessenvertretern zu berücksichtigen, die die Software letztendlich nicht nutzen werden.
Wenn es um ein digitales Produkt geht, kommt es häufig vor, dass einige Interessengruppen ihre Bedürfnisse befriedigen wollen, die nicht unbedingt mit der Vision des Produkts übereinstimmen, oder dass Personen mit einer stärkeren Stimme im Verlauf von Interviews die Einführung ihrer spezifischen Richtlinien fordern.
Wir versuchen, die funktionalen Anforderungen entsprechend der äußeren, irrelevanten Kraft zu biegen. Deshalb ist es wichtig, dass die Person, die die Anforderungen sammelt, über hohe zwischenmenschliche Fähigkeiten verfügt und die Moderation professionell durchführen kann.
Agile und Scrum zur Rettung
Es lohnt sich, daran zu erinnern, denn wir leben in einer sich dynamisch verändernden Geschäfts- und Technologiewelt, in der eine kontinuierliche Zusammenarbeit mit dem Kunden unerlässlich geworden ist.
Daher die wachsende Beliebtheit von MVP, Design Sprint oder Scrum. Mit anderen Worten: Die agile Methodik, die agile Frameworks sind jedes Jahr auf dem Vormarsch.
Agile Methodik
Die Agile Methodik wurde in den 90er Jahren im Silicon Valley geboren, obwohl der Name offiziell erst 2001 auftauchte. Damals wurde das "Agile Manifest" veröffentlicht, eine Reihe von Prinzipien zur Verbesserung der Arbeit an Softwareprojekten.
Das Manifest besagt, dass Menschen und Interaktionen wichtiger sind als Prozesse und Werkzeuge und dass funktionierende Software wichtiger ist als detaillierte Dokumentation.
Die Zusammenarbeit mit dem Kunden ist wiederum wichtiger als die Aushandlung von Verträgen, und die Reaktion auf Veränderungen ist wichtiger als die Umsetzung des festgelegten Plans.
Agile ist das Gegenteil des Wasserfallmodells, das durch starre Muster und mangelnde Flexibilität gegenüber sich ändernden Kundenbedürfnissen gekennzeichnet ist.
Scrum vs. Wie sieht der Benutzer das Projekt?
Scrum, ein Element von Agile, bei dem User Stories eine Rolle spielen, ist in Sprints unterteilt, d. h. in Projektphasen von bis zu vier Wochen Dauer.
Auf diese Weise werden laufend Änderungen vorgenommen und der Kunde ist ständig in den Entstehungsprozess des Produkts eingebunden.
Wenn wir am Ende eines Sprints die Information erhalten, dass die ausgewählten Funktionalitäten nicht den Erwartungen entsprechen, können wir im nächsten Sprint Anpassungen vornehmen. Sie können jederzeit schnell eine Funktion durch eine andere ersetzen oder Geld sparen, indem Sie eine Idee aufgeben, die nicht funktioniert hat.
In Scrum Projekt spielt der Product Owner eine wichtige Rolle. Sie erstellen eine Liste von Anforderungen für den Sprint und präsentieren die Arbeitsergebnisse den Kunden und Nutzern für ein Feedback.
Bevor der Product Owner jedoch tätig wird, geht seiner Arbeit die Sprintplanung voraus. Wir beschränken den Planungsprozess auf maximal acht Stunden, wenn der Sprint einen Monat dauert.
Wer sich für das Thema interessiert, dem sei das Buch "Agile Estimating and Planning" von Mike Cohn, einem der Begründer von Scrum, empfohlen.
Es handelt sich um eine Publikation, die eine hervorragende Einführung in die Merkmale der agilen Methodik gibt und zweifellos hilfreich ist, wenn Sie unter anderem mit User Story arbeiten wollen.
Software: ein Beispiel dafür, wie der Kunde eine große Rolle bei ihrer Entwicklung spielt
Die Regel ist einfach: Je häufiger der Kontakt mit den Geschäftsinhabern oder den Zielnutzern der Software, desto einfacher ist es, auf dem richtigen Weg der Produktentwicklung zu bleiben.
Die Experten sagen, dass die Reihe von Treffen dazu führt, dass die Erwartungslücke am Ende des Projekts viel kleiner ist und Lösungen entstehen, die viel näher an den tatsächlichen Bedürfnissen des Zielkunden sind.
Agile Projekte zeichnen sich dadurch aus, dass das Anforderungsmanagement meist in Form von User Stories im Anforderungsregister erfolgt.
In den Planungssitzungen einigen sich der Product Owner und das Team auf die Stories, die in der nächsten Iteration umgesetzt werden sollen.
Die Auswahl der Geschichten erfolgt wiederum auf der Grundlage ihrer Prioritäten und der Effizienz des Entwicklungsteams.
Wie geht es weiter? Sobald eine Gruppe von Stories ausgewählt und genehmigt ist, werden sie "eingefroren", und die vorgeschlagenen Änderungen an den Anforderungen werden in zukünftigen Iterationen berücksichtigt.
Bei agilen Projekten wird nicht versucht, die Zustimmung der Beteiligten zu sämtlichen Anforderungen im Voraus einzuholen; in diesem Fall entstehen die vollständigen Funktionalitäten erst im Laufe der Zeit.
Wir sollten jedoch nicht vergessen, dass die Vision und andere geschäftliche Anforderungen zu Beginn festgelegt werden sollten.
Product Backlog: wie man Prioritäten setzt und welche Rolle das Entwicklungsteam in diesem Prozess spielt
Wie priorisiert man das Product Backlog, eine Liste von Bedürfnissen, die aus Anforderungen und Funktionalitäten besteht?
Es ist hilfreich, wenn das Entwicklungsteam Informationen über die mit den einzelnen Anforderungen verbundenen Kosten und Risiken austauscht. Eine User Story kann auch zur Festlegung der endgültigen Prioritäten verwendet werden.
Wenn wir realistische Prioritäten setzen, können wir den Entwicklern helfen, den größtmöglichen Nutzen zu den niedrigsten Kosten und in einem angemessenen Zeitrahmen zu erzielen.
Die gemeinsame Priorisierung bildet die Grundlage für den Erfolg in agilen Projekten. Dies ermöglicht es den Entwicklern, nützliche Software so schnell wie möglich zu liefern.
Mit Hilfe von User Stories können wir den Benutzer besser verstehen und so eine Software entwickeln, die seinen Bedürfnissen entspricht.
Andernfalls macht die Implementierung der Software absolut keinen Sinn. In jedem Unternehmen, auch im digitalen Bereich, sollte der Kunde/Benutzer an erster Stelle stehen.
Beispiele für User Story Tools
Im Folgenden finden Sie einige Software-Empfehlungen, die Ihnen bei der Erstellung von User Stories helfen und Ihren Produkt- und Softwareentwicklung Prozess verbessern werden.
Ihre scrum teams können die folgenden Tools verwenden:
- FigJam
- Featmap
- Visual Paradigm
- Agile User Story Map for JIRA