Zählt dies als User Story für ein einfaches Sudoku-Spiel?

Ich versuche, eine User Story für ein einfaches Sudoku-Spiel zu erstellen, indem ich den agilen Ansatz der Softwareentwicklung verwende.

Ich verstehe das Konzept hinter User Stories, habe mich aber nur gefragt, ob es möglich ist, ein Beispiel zu finden, um mein Verständnis zu fördern.

Würde sagen

• Als begeisterter Sudoku-Spieler möchte ich mehrere Level mit unterschiedlichen Schwierigkeitsgraden haben.
• Als neuer Spieler möchte ich eine Einführung in das Spiel, um mir die Grundlagen beizubringen.

als User Story zählen?

Ihre Beispiele können als User Stories gelten, es fehlt ihnen jedoch ein sehr wichtiger Teil: das Ziel, das der Benutzer bei der Implementierung der Story erreichen möchte.
Dieses Ziel mag für Sie offensichtlich sein, aber Sie sollten es trotzdem aufschreiben.

Eine User Story hat das Format

As a <user>
I want <feature>
So that <goal>

Der Zielteil ist wichtig, da er den Entwicklern hilft, die richtigen Entscheidungen zu treffen.

Ihr zweites Beispiel könnte zwei sehr unterschiedliche Ziele haben, die zu unterschiedlichen Designs führen würden.

• Als neuer Spieler möchte ich eine Einführung in das Spiel, um mir die Grundlagen beizubringen, damit ich das Spiel lösen und ein Gefühl der Leistung bekommen kann
• Als neuer Spieler möchte ich eine Einführungsstufe in das Spiel, um mir die Grundlagen beizubringen, damit ich die Spielregeln lernen kann

Im ersten Fall würde es ausreichen, nur ein einfaches Level zu haben, aber im zweiten Fall möchten Sie den Benutzer anleiten, warum eine bestimmte Nummer in einer bestimmten Zelle platziert werden muss / nicht.

Zusätzlich zu dem guten Punkt, den Bart in Bezug auf das Ziel erwähnt hat, möchte ich mich auf den "agilen" Teil konzentrieren. Obwohl es sich um User Stories handelt, befinden sie sich weit oben auf der "epischen" Seite des Spektrums und sind für die Entwicklung noch nicht nützlich.

Wie ich es sehe, würden Sie im Allgemeinen mit Geschichten wie den oben genannten beginnen, wenn Sie anfänglich ein neues Produkt oder eine neue Funktion planen, um ein gutes Gefühl dafür zu bekommen, was Sie bauen möchten, und dann würden Sie anfangen, diese Art von "Epos" zu brechen "Geschichten zu immer kleineren Stücken, bis Sie eine Reihe von Geschichten haben, die direkt für die Entwicklung umsetzbar sind. Insbesondere wenn Sie Test Driven Development (TDD) üben, möchten Sie eine Granularität erreichen, bei der jede User Story natürlich nur auf wenige Testfälle übersetzbar ist (obwohl jede noch komplex sein kann).

Beispiele für solche umsetzbareren Geschichten könnten sein:

• Als Spieler möchte ich das Spiel bitten, ein lösbares Sudoku-Brett für mich zu generieren, damit ich mit der Planung meines Ansatzes beginnen kann.
• Als Spieler möchte ich in der Lage sein, Werte in die Zelle mit meiner Maus zu füllen und das Spiel anzeigen zu lassen, ob der Wert das Brett ungültig macht, damit ich mögliche Optionen schnell ausprobieren und bei Bedarf zurückverfolgen kann.

Ich würde den folgenden ausgezeichneten Beitrag von Alex Cowan empfehlen, um mehr darüber zu erfahren: Ihre beste agile User Story .