walkthrough

Stakeholder-Walkthrough

Anforderungen, die niemand aufgeschrieben hat, tauchen auf, wenn jemand, der nicht der Autor ist, versucht, die Sache zu tun: der Betreiber, der den Dienst installiert; der Wissenschaftler, der nach seinen Daten sucht; der Kollege, der ein Repository einrichtet; der Maintainer, der um drei Uhr morgens ein Log liest. Ein Walkthrough macht das auf dem Papier, mit einer benannten Persona und einem konkreten Prozess, bevor die Änderung spezifiziert wird. Das Ergebnis ist kein Design: Es sind Fragen an den Eigentümer, Lücken und Akzeptanzbeispiele, die die Spezifikationen und Tests verwenden können.

Zwei ausgeliehene Gewohnheiten, mit Dank: Interview aus zwei Hüten, dem Produkthut (Nutzerwert, Ziele, Erfolg) und dem Entwicklerhut (Machbarkeit, Sicherheit, Randfälle), wie es die MIT-lizenzierte Feature-Forge-Fähigkeit von jeffallan tut; und das, was ein simulierte Stakeholder "gesagt" hat, als geringeres Vertrauen markieren als das, was ein echter gesagt hat, wie es die Anforderungserhebungs-Fähigkeiten von melodic-software tun.

Eingaben

Klären Sie diese mit dem Benutzer vor dem Walkthrough und schreiben Sie sie an den Anfang der Ausgabe:

1. Die Persona. Wer sie sind, was sie von diesem Prozess wollen, was sie wissen und nicht wissen, was auf ihrem Rechner ist und was sie niemals lesen würden. Bevorzugen Sie eine reale Rolle einer Person im Institut gegenüber einem Archetyp; bevorzugen Sie die Antworten einer realen Person gegenüber Ihren Vermutungen, wenn Sie fragen können.
2. Der Prozess. Die Sache, die sie zu tun versuchen, von ihrem ersten Schritt bis zu dem Moment, an dem sie sie als erledigt betrachten. Beispiele: Installieren Sie den Crawler auf einem Server; finden Sie die Messung der letzten Woche im Index; fügen Sie ein neues Dateiformat als externe Sammlung hinzu; starten Sie ein neues Repository für die Entwicklung mit Agenten; lesen Sie nach einem Nachtlauf das Crawl-Protokoll.
3. Was existiert. Die Dokumente, der Code, die Befehle und Seiten, denen die Persona begegnen würde, damit der Walkthrough die Realität und nicht einen Plan testet. Lesen Sie sie so, wie die Persona es täte: in der Reihenfolge, in der sie sie finden würden, und überspringen Sie, was sie überspringen würden.

Der Walkthrough

Gehen Sie den Prozess Schritt für Schritt in den Schuhen der Persona durch. Notieren Sie für jeden Schritt:

• Was sie tun, konkret: den eingegebenen Befehl, die geöffnete Seite, die gelesene Datei, die gefragte Person.
• Was sie wissen müssen in diesem Moment und ob das, was existiert, es ihnen sagt.
• Was hier in der Praxis schiefgeht: der stille Fehler, die irreführende Nachricht, die Wahl ohne Standard, der Schritt, der Rechte erfordert, die sie nicht haben, das Warten ohne Rückmeldung.
• Die Frage, die sie dem Eigentümer stellen würden, wenn sie könnten, in ihren eigenen Worten.

Wechseln Sie dann zweimal den Hut über den gesamten Walkthrough: Fragen Sie mit dem Produkthut, was die Persona wollte und ob der Prozess es liefert, wie "erledigt" für sie aussieht, worüber sie sich beschweren würden; fragen Sie mit dem Entwicklerhut, was undurchführbar, unsicher, im Maßstab langsam oder in der Reihenfolge der Schritte fragil ist.

Wenn der Walkthrough an einen Punkt gelangt, den die Dokumente nicht abdecken, erfinden Sie die Antwort nicht: Notieren Sie sie als Frage, und wenn Sie etwas annehmen mussten, um fortzufahren, sagen Sie das und markieren Sie den Rest des Walkthroughs als auf dieser Annahme beruhend.

Gehen Sie eine Ebene höher, wenn ein Schritt etwas Allgemeines offenbart (fünf Warums): Eine verwirrende Nachricht ist ein Schritt; "Das Werkzeug sagt nie, was es tun wird, bevor es es tut" ist eine Anforderung.

Ausgabe

Schreiben Sie den Walkthrough in die Design-Notizen des Projekts, falls vorhanden (z.B. design/walkthroughs/<persona>-<prozess>.md), andernfalls docs/walkthroughs/, und geben Sie eine kurze Zusammenfassung in der Antwort. Vorlage:

# Walkthrough: <Persona> <führt Prozess aus>

Persona: <wer, Ziel, Wissen, Umgebung>. Vertrauen: <simuliert | basierend auf Interviews mit ...>.
Was existiert: <gelesene Dokumente, Code, Befehle>.

## Schritte
1. **<Schritt>.** Tut: <...>. Muss wissen: <...>. Geht schief: <...>. Würde fragen: "<...>".

## Produkthut
<was sie wollten, was "erledigt" für sie ist, worüber sie sich beschweren würden>

## Entwicklerhut
<undurchführbar, unsicher, langsam, fragil>

## Fragen an den Eigentümer
- <Frage, in den Worten der Persona, mit dem Schritt, aus dem sie stammt>

## Lücken
- <Anforderung, Verhalten oder Dokument, das nicht existiert; der Schritt, der es benötigt>

## Akzeptanzbeispiele
- Wenn <konkrete Situation>, dann <beobachtbares Ergebnis>. (bereit für ein Szenario in der Spezifikation oder einen Test)

Regeln

• Sagen Sie, welche Teile simuliert sind. Ein Walkthrough durch einen Agenten findet die Lücken, die ein sorgfältiger Kollege finden würde; er weiß nicht, was die reale Persona schätzt. Geben Sie die Fragen an einen echten Stakeholder weiter, wo einer existiert, und aktualisieren Sie die Vertrauenszeile.
• Bleiben Sie in den Schuhen. Wenn Sie wissen, wie das System funktioniert, weiß es die Persona nicht; schreiben Sie, was sie sieht, nicht, was Sie wissen.
• Konkret vor allgemein. "Der Betreiber führt modama-crawler crawl aus und sieht zwei Stunden lang nichts" ist ein Befund; "Das Feedback könnte verbessert werden" ist keiner.
• Fragen, Lücken und Beispiele sind das Ergebnis. Entwerfen Sie hier nicht die Lösung; der Eigentümer entscheidet, was zu einer Anforderung wird.
• Ziehen Sie einen unvoreingenommenen Blick in Betracht: Für ein Werkzeug, das existiert, findet ein Unter-Agent, dem nur die Persona, der Prozess und die benutzerseitigen Dokumente gegeben werden, mit der Anweisung, das Werkzeug auszuführen, was der Autor nicht mehr unwissen kann. Das ist die hallway-test-Fähigkeit in diesem Plugin; verwenden Sie sie, wenn der Walkthrough zu "lass es uns versuchen" wird.