In diesem Artikel untersuchen wir die Ergebnisse der Verwendung des User-Story-Analysetools ScopeMaster ein Beispielsatz von User Stories (Zugriff auf Originale hier). Die von uns verwendeten Geschichten wurden von Mike Cohn auf der Mountain Goat-Website veröffentlicht und beschreiben die Funktionen einer zu erstellenden interaktiven Website.
Über die Beispiel-User Stories
Wir haben diese Beispiel-User Stories ausgewählt, da sie frei verfügbar sind und von einem bekannten Autor von Büchern zum Thema Schreiben von Software-User Stories veröffentlicht wurden. Es sind Beispiele, die jeder herunterladen kann. (Das PDF enthält tatsächlich Beispiele für drei verschiedene Projekte). Für diese Übung haben wir uns gerade die Geschichten der angesehen ScrumAlliance-Website . Laden Sie die CSV-Datei mit den Beispiel-User-Stories herunter
Der Zweck der Übung besteht darin, herauszufinden, was ScopeMaster über eine typische Reihe von User Stories verraten kann.
Vorbereitung
Schritt 1. Konvertieren Sie das PDF in eine CSV
Das PDF-Dokument enthält eine Liste mit Aufzählungspunkten von User Stories. Um die Liste für den Import vorzubereiten, haben wir zunächst jede User Story in eine Zeile in einer Tabelle kopiert. Die Tabelle wurde dann als CSV gespeichert und konnte in ScopeMaster importiert werden. Dies war der zeitaufwändigste Teil der gesamten Übung! Glücklicherweise sind heutzutage die meisten User Stories in einer Struktur enthalten, die problemlos als CSV-Datei formatiert werden kann, sodass dieser Schritt normalerweise vermieden wird.
Insgesamt gibt es 98 User Stories. Wir haben die Gelegenheit genutzt, vor dem Import für jeden eine eindeutige Referenz-ID zu generieren. Wenn Sie möchten, können Sie die von uns erstellte CSV-Datei hier wiederverwenden: Original-Beispiel-User-Storys von Mountain Goat – ScrumAlliance CSV
Schritt 2. In ScopeMaster importieren
Anschließend haben wir in ScopeMaster ein neues Projekt erstellt und die Option „CSV importieren“ ausgewählt
Wir empfehlen die Trennung des funktionalen Teils der User Story vom Nutzentext, daher haben wir den Import von ScopeMaster gebeten, dies für uns zu tun.
Schritt 3. Alles analysieren
Anschließend haben wir die automatisierte Analyse gestartet. Einfach durch Drücken der grünen Taste.
Hier geschieht die Magie. Die Analyse-Engine von ScopeMaster bearbeitet nacheinander jede User Story, sie wird interpretiert, analysiert, getestet, dimensioniert und mit Querverweisen versehen.
In gerade unter 3 MinutenScopeMaster analysierte jedes Wort aller 98 User Stories und führte fast 112.000 Tests durch.
Ergebnisse
Schauen wir uns nun an, was ScopeMaster uns über diese User Stories erzählt.
Jede User Story: Interpretiert, getestet und dimensioniert (falls möglich)
- ScopeMaster untersuchte jedes Wort jeder User Story, um festzustellen, ob daraus eine klare funktionale Absicht festgestellt werden kann. Ist das klar?
- Wenn ja, ermittelt ScopeMaster, wer der ist Benutzer Und Was was sie erreichen wollen/müssen. dh. Ist es benutzerorientiert und funktional?
- Aus der oben ermittelten Funktionsabsicht hat ScopeMaster die Funktionsgröße in COSMIC-Funktionspunkten nach ISO-Standards geschätzt. Was ist die Größe?
Einblick in die Beispiel-User Stories
Das Anwendungsfallmodelldiagramm wurde aus der Interpretation von generiert die Menge der User Stories. Dieses Diagramm gibt sofort Einblick in viele Qualitätsaspekte der User Stories, die in Anforderungsrepositorys wie Trello, Jira und Azure DevOPs einfach nicht sichtbar sind. Dieses Diagramm zeigt die logische Beziehung zwischen User Stories. Mithilfe dieses Diagramms können Sie feststellen, ob Sie die richtigen Anforderungen haben.
Von User Stories zum Datenmodell
Aus den von ScopeMaster ermittelten funktionalen Absichten wird aus dem Text der User Stories ein vorgeschlagenes Klassendiagramm aller wahrscheinlichen Klassen und ihrer Methoden ermittelt. Dies kann Entwicklern helfen zu verstehen, welche Daten sie berücksichtigen müssen und wie diese gespeichert und verarbeitet werden können. Dies ist kein endgültiges Klassendiagramm, aber ein sehr nützlicher Ausgangspunkt. Mithilfe dieses Diagramms lässt sich ermitteln, wie die Daten organisiert und strukturiert werden sollen, um den Anforderungen gerecht zu werden.
Generierte Tests direkt aus User Stories
Bestimmen der Backlog-Größe
Für alle Teams und alle Projekte variieren die User Stories in der Größe und dem Aufwand, sie bereitzustellen. Diese Variabilität kann sehr hoch sein. ScopeMaster wurde von Anfang an entwickelt, um die funktionale Dimensionierung schriftlicher Softwareanforderungen zu automatisieren. Dies bedeutet, dass es darauf ausgelegt ist, den Verwaltungsaufwand für das Lesen von Anforderungen zur Bestimmung einer formalen Funktionsgrößenschätzung der darin beschriebenen Software zu eliminieren oder zu reduzieren. Die funktionale Größe ist ein technologieunabhängiger, benutzerorientierter Größenindikator. ScopeMaster schätzt die funktionale Größe in den beiden wichtigsten ISO-Standards für die Größenbestimmung von Software, nämlich KOSMISCHE Funktionspunkte Und IFPUG Funktionspunkte. Wir empfehlen Ersteres, da es besser für moderne Softwarearchitekturen geeignet ist und unvollständige Anforderungen besser bewältigen kann. ScopeMaster schätzt die Funktionalität Größe aller Storys in Ihrem gesamten Backlog in wenigen Minuten, was dem Team erspart, Zeit mit wertlosen Diskussionen über Story Points oder T-Shirt-Größen zu verschwenden.
Qualitätsanalyse
In knapp 3 Minuten identifizierte ScopeMaster Hunderte von Problemen mit den User Stories.
Unklarheiten
51 der 98 User Stories hatten eine mehrdeutige funktionale Bedeutung, die, wenn sie nicht gelöst würde, zu Fehlern führen würde. 51 Mängel festgestellt.
Fehlende Benutzergeschichten zur grundlegenden Sicherheit
In den User Stories wurde nicht von Anmelden, Authentifizieren, Autorisieren, Erlauben oder Abmelden gesprochen. Dies ist offensichtlich ein wichtiges Versäumnis. Wir gehen normalerweise davon aus, dass hierfür mindestens mehrere User Stories erforderlich sind. (obwohl die Geschichte „Passwort vergessen“ vorhanden ist). 5 festgestellte Mängel:
• Anmeldung
• E-Mail validieren
• Kennwort ändern
• Ausloggen
• Und dann müsste bei jeder rollensensitiven User Story eine Rollen- und/oder Berechtigungsprüfung durchgeführt werden
Der ursprüngliche Satz von User Stories beschrieb die erforderliche Funktionalität nicht vollständig.
Inkonsistente Bedingungen für Benutzer/Personas
ScopeMaster identifizierte 26 potenzielle Benutzertypen. Es ist wahrscheinlich, dass es tatsächlich nur 10 verschiedene Personas gibt. 16 Mängel festgestellt.
Inkonsistente Bedingungen für Benutzer/Personas
In ähnlicher Weise identifizierte ScopeMaster 41 potenzielle Objekttypen, während es wahrscheinlich nur etwa 25–30 sind. 16 Mängel festgestellt.
Vollständigkeit der Datenpflege (CRUD-Analyse)
Für jeden gültigen Objekttyp sollte es mindestens eine Funktion für jedes CRUD-Ereignis geben. Nach Eliminierung der redundanten Objekttypen führt dies dazu, dass etwa 80 funktionale User Stories fehlen. 80 Mängel festgestellt.
Fähigkeitsausreißer
Das Use-Case-Modelldiagramm deckte weitere fehlende Anforderungen basierend auf Rollen/Personas auf. Wir schätzen mindestens 1 oder 2 pro Benutzertyp. 10 Mängel festgestellt
Wertaussagen
ScopeMaster stellte fest, dass nur 58 der 98 den Ausdruck „so dass“ verwendet haben, alle bis auf drei jedoch den Begriff „so“ enthalten. 3-40 Mängel festgestellt
NFRS
Darüber hinaus ergab die Erkennung nichtfunktionaler Anforderungen von ScopeMaster, dass es mehrere relevante Kategorien von NFRs gibt, die in dieser Reihe von User Stories nicht erwähnt wurden: Zugänglichkeit, Überprüfbarkeit, Beobachtbarkeit. 3 Mängel festgestellt
Zusammenfassung der Qualitätsergebnisse
In nur 3 Minuten identifizierte ScopeMaster 211 wahrscheinliche Probleme (97 + 114) mit diesen User Stories. Aus der CRUD-Analyse geht außerdem hervor, dass nur die Hälfte der wahrscheinlich notwendigen User Stories tatsächlich aufgeführt sind. (Dieser Beispielsatz von User Stories wurde möglicherweise vor der Veröffentlichung absichtlich gekürzt.)
Darüber hinaus hat ScopeMaster über 140 wesentliche Testszenarien generiert, die dazu beitragen werden, die Funktionstestinitiative zu beschleunigen, sobald die Funktionalität erstellt wurde.
Der Zweck dieser Übung bestand nicht darin, die Beispiel-User-Stories zu kritisieren, sondern den Wert der Verwendung von ScopeMaster für beliebige User-Storys hervorzuheben.
Wir freuen uns über alle Kommentare der Leute von Mountain Goat.
Abschluss
Anhand dieser Übung können wir erkennen, dass ScopeMaster bei diesem Beispielsatz von User Stories wertvolle Arbeit leistet. Es hat:
- Es wurden über 200 Probleme aufgedeckt, die leicht gelöst werden können, bevor sie versehentlich zur Ursache einer Nacharbeit werden.
- Fehlendes Zielfernrohr aufgedeckt
- Ein mögliches Datendesign wurde enthüllt
- Erstellte brauchbare Basistestszenarien für jede User Story, einschließlich positiver und negativer Tests.
- Geschätzte funktionale Größe jedes Stockwerks (einschließlich der fehlenden) in ISO-Standards für funktionale Größe.
All dies summiert sich zu einer beträchtlichen Menge nützlicher, aufschlussreicher und nach links gerichteter Arbeit, die dazu beiträgt, Sicherheit in den Umfang zu bringen und das Risiko jedes Softwareprojekts zu reduzieren.
Es wäre großartig, von Mike Cohn oder jedem, der auf der ScrumAlliance-Website gearbeitet hat, von ihren Erfahrungen mit der Verwendung dieser User Stories und von ihren Gedanken zur ScopeMaster-Analyse zu hören. Bisher war niemand aus seinem Team für eine Stellungnahme erreichbar.