User Stories verfeinern
Bei der Verfeinerung von User Stories geht es darum, jede User Story zu verbessern, aufzuteilen und zu klären. Die Details und Klarheit jeder User Story sollten überprüft werden. Backlog Grooming ist ein Begriff, der sich im Allgemeinen auf den übergeordneten Prozess der Priorisierung von User Stories bezieht. Sowohl die Verfeinerung (Klärung) als auch die Pflege (Priorisierung) sind wichtige Schritte zur Erreichung guter Qualitätsanforderungen. Ersteres stellt sicher, dass der Benutzer bekommt, was er will, und letzteres kümmert sich um die Reihenfolge, die sowohl den Geschäftsanforderungen als auch der Effizienz des Entwicklungsteams entspricht. In diesem Artikel konzentrieren wir uns auf die Verfeinerung von User Stories und überlassen die Priorisierung einem separaten Artikel.
Zweck von User Stories
Der Zweck von User Stories besteht darin kommunizieren, um sicherzustellen, dass die Bedürfnisse des Benutzers korrekt in einer Sprache ausgedrückt werden, die ein Entwickler und Tester vollständig und konsistent verstehen kann. Die User Stories müssen es sein benutzerorientiert, einfach, klar, eindeutig Und konsistent, mit nichts fehlen. Durch die Verfeinerung Ihrer Geschichten beseitigen Sie viele Anforderungsmängel, die oft erst lange nach Beginn der Design- und Entwicklungsarbeiten entdeckt werden. Die Verfeinerung von User Stories mit ScopeMaster ist in der Regel 10–20 Mal schneller als die manuelle Bearbeitung.
User Stories oder Anforderungen
Sind User Stories und Anforderungen dasselbe? Einige agile Puristen werden erklären, dass User Stories Erinnerungen an Gespräche und daher keine Anforderungen sind. Wir haben jedoch festgestellt, dass bei den meisten Teams die User Stories werden als Anforderungen behandelt, und so machen wir dasselbe. Anforderungen oder User Stories sind im Wesentlichen ein Ausdruck der Fähigkeiten, die die Benutzer von der Software benötigen, um eine klare und konsistente Kommunikation mit dem Team sicherzustellen. Beachten Sie, dass User Stories (oder Anforderungen) keine technischen Aufgaben oder Projekteinschränkungen beinhalten. Im Folgenden verwenden wir die Begriffe Erfordernis Und Benutzer Geschichte austauschbar.
Fehler in User Stories sind unvermeidlich
Das Schreiben von Anforderungen oder User Stories ist das Gleiche wie bei jeder anderen Wissensarbeit – wir machen dabei Fehler. Auch wenn wir vorsichtig sind, passieren Fehler, sie sind unvermeidlich. Darüber hinaus schreiben wir sie im Allgemeinen auf Englisch, einer unglaublich subtilen Sprache, in der jedes Wort vom Leser auf unterschiedliche Weise verstanden werden kann. Selbst wenn wir glauben, sie gut geschrieben zu haben, ist es durchaus wahrscheinlich, dass die Leser zu einem etwas anderen Verständnis gelangen werden. Wenn zwei Leser der User Story zu einem unterschiedlichen Verständnis gelangen können, dann liegt ein Defekt vor. Ein Fehler in einer User Story oder Anforderung führt dazu, dass die falsche Software erstellt wird.
Kosten für Fehler in User Stories oder Anforderungen
Das Verständnis der Qualitätskosten ist ein sehr wichtiges Thema, da es uns helfen kann zu verstehen, warum die Qualität der Anforderungen wirklich wichtig ist. Ein Anforderungsfehler, der nicht vor der Entwicklung behoben wird, führt zu einem Fehler. Das ist eine unvermeidbare Tatsache. Viele Anforderungsprobleme werden während der Entwicklung entdeckt. Aber nicht alle von ihnen. Lassen Sie uns überlegen, welche Auswirkungen es hat, wenn wir diesen Fehler erst später im Softwareentwicklungslebenszyklus (SDLC) finden und beheben. Wenn der Fehler während der Entwicklung entdeckt wird, müssen wir möglicherweise die Entwicklung stoppen, prüfen, was die richtige Anforderung ist, sie dann neu entwerfen und den Code neu schreiben. Dies braucht Zeit und wird den Fortschritt stören und verzögern. Je nach Art und Schwere des Anforderungsmangels kann dies zu größeren Nacharbeiten (anderes Design, andere Architektur) führen. Dies kann Projekte verzögern und zu erheblichen Kostensteigerungen führen.
Betrachten wir nun eine noch schwerwiegendere Situation, in der ein Fehler in einer Anforderung erst bemerkt wird, nachdem der Code in Produktion geht. Dies kann noch schwerwiegendere Folgen haben. Die Software macht möglicherweise das Falsche und schadet den Benutzern oder dem Unternehmen. Dies kann katastrophale Auswirkungen haben.
Kosten für die Behebung von Mängeln in den Anforderungen
Wenn in der Produktion ein durch unzureichende Anforderungen verursachter Mangel festgestellt wird und dieser schwerwiegend ist, gibt es zwei Kategorien von Kosten: interne und externe.
Interne Kosten
- Die zusätzliche Arbeit, die Software so zu ändern, dass sie ordnungsgemäß funktioniert
- Der zusätzliche Aufwand zur Änderung von Daten, die aufgrund des Fehlers falsch verarbeitet wurden
- Die Opportunitätskosten, die entstehen, wenn Personal für die Behebung dieses Fehlers eingesetzt wird, anstatt andere nützliche Arbeiten auszuführen
Externe Kosten
- Folgekosten für die Benutzer oder Begünstigten der Software, die durch den Fehler verursacht werden
- Entschädigung für die Benutzer, die unter diesem Fehler gelitten haben
- Zusätzliche Arbeit von Nicht-Software-Mitarbeitern zur Bewältigung des Vorfalls/der Auswirkungen auf Benutzer, bis der Fehler behoben werden kann
- Reputationsschaden für eine Organisation
In den meisten Fällen unterschätzen Softwareprojektteams die Kosten schlechter Anforderungen. Wenn Sie mehr über dieses Thema erfahren möchten, empfehle ich dieses hervorragende Buch „Die Ökonomie der Softwarequalität“
Automatisierte Anforderungs-QA
ScopeMaster bringt die Arbeit der Anforderungsqualitätssicherung auf ein neues Niveau. ScopeMaster trägt dazu bei, die Arbeit zur Verbesserung der Anforderungsqualität und zur Verfeinerung der User Story zu beschleunigen.
ScopeMaster automatisiert die Suche und beschleunigt die Behebung vieler Anforderungsmängel, um sicherzustellen, dass Ihre Anforderungen oder User Stories:
- Klar
- Prägnant
- Konsistent
- Vollständig
- Testbar
- Beträchtlich
- Einzigartig
- Benutzerorientiert
- Designfrei
Die einzige wichtige Eigenschaft, die ScopeMaster nicht automatisieren kann, besteht darin, zu erkennen, ob Sie die Anforderung tatsächlich benötigen. Ist sie wertvoll? Dies müssen Sie selbst lösen, aber ScopeMaster spart Ihnen so viel Zeit, dass Sie den tatsächlichen Wert jeder Anforderung berücksichtigen können.
Lerne mehr über Automatisierte Backlog-Verfeinerung
Was sind gute Anforderungen?
Wir haben festgestellt, dass schlechte Anforderungen schädlich, kostspielig, verschwenderisch und in manchen Fällen sogar gefährlich sind. Wie schreiben wir also gute Anforderungen? Woher wissen wir, ob wir gute Anforderungen haben? Wie können wir Probleme in Anforderungen erkennen? Es gibt einige universelle Zutaten für gute Anforderungen, die wir beschreiben werden und die Ihnen helfen werden:
Benutzerorientiert
Alle Anforderungen müssen in Bezug auf die Bedürfnisse eines Benutzers ausgedrückt werden. Anschließend können sie in Entwickleraufgaben unterteilt werden, aber zunächst muss eine Version der Anforderung in Bezug auf die Benutzerbedürfnisse ausgedrückt werden, damit wir sicher sein können, dass das, was entwickelt wird, den Bedürfnissen des Benutzers entspricht.
Klar und eindeutig
Eine Anforderung sollte vom Leser nicht leicht missverstanden werden. Dies ist möglicherweise die am schwierigsten sicherzustellende Dimension. Das bedeutet, dass eine Anforderung eine klare Funktionalität beschreiben sollte, die ein Benutzer ausführen muss. Zwei Leser derselben Anforderung sollten zum gleichen allgemeinen Verständnis darüber gelangen, welche Daten als Teil der Anforderung verarbeitet werden müssen.
Prägnant
Anforderungen sollten prägnant sein. Eine Anforderung muss weder ausführlich sein noch eine blumig-elegante Sprache verwenden.
Konsistent
Eine Reihe von Anforderungen sollte einheitliche Begriffe für Benutzertypen verwenden, z Administrator. Eine Reihe von Anforderungen sollte auch einheitliche Begriffe für Datentypen (Objekttypen) verwenden.
Vollständig
Eine Anforderung sollte in sich vollständig sein (beschreiben Sie alle für diese Benutzerfunktion erforderlichen Funktionsschritte). Außerdem sollte eine Reihe von Anforderungen vollständig sein und alle Funktionen beschreiben, die zur Verwaltung aller Daten im System erforderlich sind. Hierfür ist die CRUD-Analyse am hilfreichsten.
Beträchtlich
Wenn eine Benutzeranforderung nicht funktionell umfangreich ist (dh in KOSMISCHEN Funktionspunkten messbar ist), mangelt es ihr mit an Sicherheit grenzender Wahrscheinlichkeit an Qualität, wenn es sich um einen der anderen Aspekte in dieser Liste handelt. Aus diesem Grund sind wir der Ansicht, dass die Fähigkeit zur Größenbestimmung in CFP ein hervorragender Test für die Klarheit und Qualität der Anforderungen ist. Nb. Technische Aufgaben und nichtfunktionale Anforderungen sind auf diese Weise nicht umfangreich. Technische Aufgaben werden im Allgemeinen in Personalstunden bemessen. Nicht funktionale Größenbestimmung ist ein ungelöstes Problem, obwohl es einige Empfehlungen gibt (in einem separaten Artikel).
Testbar
Tester müssen in der Lage sein, zu bestimmen, wie sie testen können, ob eine Anforderung erfüllt wurde. Daher muss die Anforderung so formuliert sein, dass sie getestet werden kann. Eine der besten Möglichkeiten, um sicherzustellen, dass diese Anforderung testbar ist, besteht darin, sicherzustellen, dass sie die funktionale Absicht klar beschreibt. (Hierfür empfehlen wir die COSMIC-Größe)
Einzigartig
Wir möchten nicht, dass eine Reihe von Anforderungen doppelten Inhalt oder doppelte Funktionalität enthält. (Dies ist möglicherweise eines der unbedeutendsten Qualitätsprobleme von Anforderungen.)
Designfrei
User Stories sollten keine Details darüber enthalten, wie eine Funktion implementiert werden soll. Eine User Story ist kein Platzhalter für Designdetails. Sie können die Arbeit zur Implementierung einer User Story aufteilen technische Aufgaben, aber das sind keine User Stories.
Wertvoll
Jede User Story muss dem Benutzer oder Stakeholder einen Mehrwert bieten, andernfalls sollte sie nicht erstellt werden. Der Wert sollte in Begriffen ausgedrückt werden, die der Benutzer (nicht der Entwickler) erkennt.
Das ist unsere empfohlene Liste mit 10 Merkmalen guter User Stories oder Softwareanforderungen. Es gilt in allen Situationen. Einige Anforderungsexperten werden zu Recht argumentieren, dass dies nicht weit genug geht. Es stimmt, es gibt bestimmte Situationen, in denen Anforderungen noch höhere Standards erfüllen sollten, als wir hier beschrieben haben. Was wir beschrieben haben, ist eine Reihe von Attributen, die überall gelten sollten, unabhängig von der Art der Software, die Sie entwickeln/assemblieren/bereitstellen.
Vorsicht vor INVEST!
INVEST wurde von frühen Agilisten erfunden, um eine Art Checkliste für User Stories bereitzustellen. Es steht für:
- Ich bin unabhängig (von allen anderen)
- „N“ verhandelbar (kein spezifischer Vertrag für Funktionen)
- "Wertvoll
- „E“ stimulierbar (in guter Näherung)
- „S“-Einkaufszentrum (damit es in eine Iteration passt)
- „T“ stabil (im Prinzip, auch wenn es noch keinen Test dafür gibt)
Wir mögen Checklisten, sind jedoch der Meinung, dass die INVEST-Liste zu viele Mängel aufweist, als dass sie allgemeingültig für die Beurteilung der Qualität von Anforderungen wäre, und raten von ihrer Verwendung ab.
Es kann nicht sichergestellt werden, dass die Geschichten benutzerorientiert sind
Wenn Software für einen Benutzer nichts Nützliches tut, ist sie nicht nützlich. Wenn unsere Geschichten nicht nutzerorientiert sind, dann handelt es sich um einfache Arbeitsaufgaben. Und so werden so viele User Stories letztendlich zu Aufgaben, die nicht Ausdruck einer für den Benutzer erkennbaren Funktionalität oder Fähigkeit sind. Kurz gesagt, Ihr Ausdruck von Erledigt wird wahrscheinlich schlecht sein.
Die Konsistenz kann nicht sichergestellt werden
Wenn Sie nur diese Richtlinien befolgen, werden Sie wahrscheinlich auf Anforderungen stoßen, die Benutzer-/Persona-Namen durcheinander bringen und viele verschiedene Begriffe für Objekttypen enthalten.
Es kann nicht sichergestellt werden, dass die Größe groß ist
Durch die Bezugnahme auf Estimable und nicht auf Sizeable kann dieser Ansatz nicht sicherstellen, dass jede User Story eine (funktionale) Größe hat. Die funktionale Größe ist nicht nur für das Projektmanagement wertvoll, sondern auch ein guter Test für die Qualität der Anforderungen. Eine große Anforderung ist eine gute Qualität.
Design-Free ist nicht gewährleistet
Wenn Sie sich nur auf INVEST verlassen, werden Ihre User Stories mit Aufgaben (und „technischen User Stories“) vermischt, wodurch die Arbeit vom Benutzer und ihrem Wert für ihn entfernt wird.
Verwendung von ScopeMaster
Innerhalb einer Stunde nach der ersten Nutzung von ScopeMaster werden Sie Anforderungsmängel schneller als je zuvor finden und beheben. Abhängig von der Qualität der ursprünglichen Anforderungen können Sie bis zu 200 Fehler pro Tag finden und beheben. Können Sie sich eine andere Aktivität vorstellen, die bei der Fehlersuche und -behebung so produktiv wäre?
Folge diesen Schritten:
- Importieren Sie die Geschichten Ihrer Benutzer (über eine CSV-Datei).
- Klicken Sie auf „Alle analysieren“ (vielleicht haben Sie Zeit für einen Kaffee).
- Entdecken Sie die Ergebnisse der Analyse von ScopeMaster
- Beginnen Sie mit den mehrdeutigen und formulieren Sie sie um, um sie zu klaren, benutzerorientierten, funktionalen User Stories zu machen
- Verwenden Sie das automatisch generierte Datenwörterbuch und das Anwendungsfallmodell, um eine konsistente Benutzerbenennung sicherzustellen
- Nutzen Sie die CRUD-Analyse, um eine konsistente Objektbenennung sicherzustellen
- Untersuchen Sie das Qualitätsfeedback, das ScopeMaster liefert, um sie weiter zu verbessern.
- Nutzen Sie die CRUD-Analyse, um sicherzustellen, dass die Anforderungen vollständig sind
