Wie definiere ich Akzeptanzkriterien für subjektive Ergebnisse?

Ich denke, subjektive User Stories sind ein Rezept für Scope Creep. Wenn Sie sich auf die Anforderungen von Geschäftsinhabern konzentrieren und etwas Messbares schaffen möchten, würde ich auf ein Framework wie das digitale Marketing- und Messmodell zurückgreifen , um diskrete KPIs zu generieren, die der Geschäftsinhaber versteht und aus Ihrer Sicht erreichbar ist.

z.B:

• Ziel: Bessere Dokumentation
• Ziel: Brauchbare Anleitung
• KPI: Verbesserung der Empfehlungsumsetzung
• Ziel: 90 % der Empfehlungen werden innerhalb einer Woche umgesetzt
• Segment: Aufgabenrückstandsbericht

Die User Story wird also:

Als Kleinunternehmer möchte ich einfache und leicht zu befolgende Anweisungen, damit ich 90 % der Empfehlungen innerhalb einer Woche umsetze

Warum Ihre „Geschichte“ nicht testbar ist

Als Inhaber eines kleinen Unternehmens möchte ich,
dass ich einfache und einfache Anweisungen für Empfehlungen zu meiner Website befolge
, damit ich verstehe, was ich tun muss und welche Ressourcen erforderlich sind.

Du hast hier zwei Probleme:

1. Dies ist keine User-Story. Dies ist ein Epos , das zerlegt werden muss.
2. Diese Geschichte folgt nicht den INVEST-Kriterien , weshalb ihr offensichtliche Akzeptanzkriterien fehlen. Dies ist für Epics oft in Ordnung (wenn nicht ideal), aber Sie müssen sicherstellen, dass die zugehörigen User Stories testbar sind .

In den folgenden Abschnitten wird erläutert, wie Sie Ihr Epos zerlegen, Geschichten schreiben, die der INVEST-Mnemonik folgen , und zu einem iterativen, testgetriebenen Dokumentationsmodell wechseln.

Agile Lösungen, um Dokumentationsgeschichten testbar zu machen

Zerlegen Sie Ihr Epos

Das erste, was Sie tun müssen, ist, Ihr Epic in einzelne User Stories zu zerlegen. Betrachten Sie das folgende Beispiel:

• Epic: Website-Benutzerdokumentation

  1. Als Websitebesitzer
     möchte ich, dass das Benutzerhandbuch ein Kapitel zur Konfiguration der Captcha-Einstellungen enthält
     , damit ich die Anzahl der Anmeldeversuche der Benutzer erhöhen kann, die für die Anmeldung erforderlich sind.

  2. Als Website-Eigentümer
     möchte ich, dass das Benutzerhandbuch ein Kapitel über die Randomisierung der Zielseite enthält,
     damit ich es den Benutzern erschweren kann, meine Website mit einem Lesezeichen zu versehen.

Diese Geschichten sind zwar albern, aber weitgehend umsetzbar. Jede Geschichte enthält ein konkretes Ergebnis (dh ein Kapitel in der Bedienungsanleitung) zu einem bestimmten Thema mit genügend Kontext, um messbare Ziele zu erreichen.

Definieren Sie Akzeptanztests

Natürlich sollte ein Teil Ihrer Definition of Done darin bestehen, zu testen, ob die Informationen in Ihrem Handbuch richtig übermittelt werden. Das ist nicht Teil der User Story; Stattdessen besteht ein Teil Ihrer Sprint-Planung für diese Geschichte darin, alle erforderlichen Benutzerakzeptanztests zu Ihrem Sprint-Backlog hinzuzufügen.

Beispielsweise kann das Team planen, dass ein echter Kunde das Kapitel zu den Captcha-Einstellungen durchgeht und prüft, ob es verständlich und vollständig ist. Oder das Team kann sich dafür entscheiden, ein Teammitglied Schritt für Schritt durch das Kapitel gehen zu lassen und den Anweisungen im Handbuch zu folgen , anstatt es auf andere Weise zu tun, um zu sehen, ob es wie geschrieben funktioniert. Dies wird auf jeden Fall nützliche Rückmeldungen über die Verwendbarkeit der Anweisungen geben.

Iterieren, iterieren und nochmals iterieren

Bei der iterativen Entwicklung geht es nicht darum, beim ersten Mal etwas Perfektes zu erreichen. Vielleicht liefern Sie Ihr Kapitel auf randomisierten Startseiten aus, was damals für den Tester verständlich und sinnvoll war, aber später haben Sie einen neuen Kunden, der mit Schritt 15 desselben Kapitels zu kämpfen hat. Aus agiler Sicht ist dies einfach eine Chance, sich schrittweise zu verbessern!

Sie würden eine neue User Story schreiben, wie zum Beispiel:

Als Website-Benutzer
möchte ich, dass Schritt 15 von Kapitel 23 aus Gründen der Klarheit neu geschrieben wird
, damit ich das Verfahren zum Randomisieren meiner Homepage befolgen kann.

Auch hier sind Ziel und Umfang klar definiert, aber die Akzeptanztests werden angepasst. Sie sollten Tests hinzufügen, die Akzeptanztests durch Ihren neuen Kunden (oder einen Proxy) beinhalten, während Sie Regressionstests mit Ihren bestehenden Akzeptanztests durchführen, um sicherzustellen, dass Sie die Situation für Ihre bestehenden Kunden nicht verschlimmern.

Befolgen Sie die INVEST-Kriterien

Jede User Story, die Sie schreiben, sollte:

• In sich geschlossen, ohne Abhängigkeiten von anderen Geschichten.
• Schätzbar, damit Umfang und Aufwand vom Team verstanden werden.
• Klein genug, um innerhalb eines einzigen Sprints zu planen, zu entwickeln und zu testen .
• Testbar, mit definierten Metriken. Objektive Tests sind am besten, aber "Frag Mikey, ob es ihm gefällt!" erfüllt immer noch die Anforderungen der Testbarkeit, solange sich das Team darauf geeinigt hat, um zu entscheiden, ob eine Geschichte "fertig" ist.

Wenn Sie Ihre User Stories auf diese Weise schreiben, werden Sie feststellen, dass es dem Team viel leichter fällt, sowohl das Ziel der Story als auch die Erfolgskriterien dafür zu identifizieren. Dadurch werden die Implementierungsdetails (z. B. was für jeden Abschnitt der Dokumentation zu schreiben ist) für die Entwickler und technischen Redakteure viel offensichtlicher, ohne detaillierte Spezifikationen zusammenstellen zu müssen.

Indem Sie innerhalb des Sprints mit den Akzeptanztestern oder Endbenutzern zusammenarbeiten, um die Akzeptanzkriterien sowohl zu definieren als auch zu testen, stellen Sie außerdem sicher, dass Sie am Ende des Sprints nicht mit dem Falschen enden. Diese Umstellung auf testgetriebene Dokumentation kann herausfordernd sein, unterscheidet sich aber aus Prozesssicht nicht wirklich von testgetriebenem Code.

Es gibt zwei Ansätze für subjektive Messungen in User Stories, die je nach Ihren Umständen funktionieren können:

1) Verwenden Sie sie nicht: In einigen Fällen können Sie mit den Stakeholdern konkretere Messungen erarbeiten, um die subjektiven zu ersetzen. Sie können spezifisch sein, z. B. „Ich möchte, dass die Seite schnell geladen wird“ durch „Ich möchte, dass die Seite in 3 Sekunden geladen wird“ oder relativ wie „Ich möchte den Algorithmus verbessern, um Stapel 25 % schneller zu verarbeiten.“

2) Konzentrieren Sie sich auf das Gespräch: Nehmen wir an, Sie möchten einen intuitiven Schadensmeldungsprozess in Ihrer Anwendung. „Intuitiv“ ist viel schwieriger in konkrete Begriffe zu übersetzen, daher müssen Sie sich möglicherweise auf einige Methoden einigen, die das Team verwenden wird, wie z. Dieser Ansatz birgt das Risiko, dass er sich lange hinzieht, daher sollten Sie ihn wahrscheinlich zeitlich festlegen. Genau genommen ist dies eher eine Spike- als eine User-Story, aber es sollte trotzdem helfen, Ihr Problem zu lösen.

Ein Akzeptanzkriterium, das den Zweck und den Umfang klar identifiziert. Im Allgemeinen versuche ich zu definieren, welche Szenarien im Geltungsbereich liegen und welche Szenarien nicht im Geltungsbereich liegen. In diesem Fall und nach Kundenfeedback werde ich versuchen, einige Anwendungsfälle aufzulisten, um einige der möglichen Pfade zu definieren.

In der Regel ist ein wirksames Akzeptanzkriterium detailliert / spezifisch und eindeutig und wir sollten keine subjektive Sprache verwenden.

Verwenden Sie einen Spike !

Eine Aufgabe, die darauf abzielt, eine Frage zu beantworten oder Informationen zu sammeln, anstatt ein versandfähiges Produkt herzustellen. Manchmal wird eine User Story generiert, die nicht gut eingeschätzt werden kann, bis das Entwicklungsteam tatsächlich an der Lösung einer technischen Frage oder eines Designproblems arbeitet. Die Lösung besteht darin, eine „Spitze“ zu erstellen, bei der es sich um eine Arbeit handelt, deren Zweck es ist, die Antwort oder Lösung bereitzustellen. - http://agiledictionary.com/209/spike/

Sobald der Spike abgeschlossen ist, sollten Sie jetzt genug Definition haben, um Ihre User Stories zu erstellen.