Muss ein Schauspieler einer User Story ein menschliches Wesen sein?

Question

User Stories werden traditionell als Ausdruck geschrieben "Als [User Type] möchte ich [Feature], so dass [etwas nutzen]". In den Büchern und Online-Ressourcen [User Type] entspricht typischerweise eine Rolle eines Menschen. Wenn jedoch Merkmale von Systeminterna beschrieben werden, ist es oft einfacher, einen unbeaufsichtigten Dienst anstelle eines Benutzers, z. "Als ein ServiceX möchte ich, dass einige Daten regelmäßig aktualisiert werden, damit ich XYZ mit den neuesten Informationen machen kann".

Eine solche Form macht es einfach, leicht verständliche Akzeptanztests für verwandte Teile des Systems zu schreiben. Aber ist das konzeptionell richtig? Sollten User Storys nicht auf Funktionen basieren, die einen Wert darstellen, und da Systeme und Services nicht daran interessiert sind, Geschäftswerte zu gewinnen, sollten sie keine Akteure von User Stories sein?

Answer 1

Systeme sind sicherlich daran interessiert, geschäftlichen Wert zu gewinnen. Ein Akteur könnte ein automatisierter Agent sein, der von einem Dritten geschrieben wurde und der die Absicht dieses Dritten verkörpert. In der Tat wird dies zu einer dominanten Form der Interaktion, da Web-Services zu einem beliebteren Feature wichtiger Websites werden, wodurch komplexe Inter-Site-Interaktionen im Auftrag von Benutzern möglich sind, die jedoch nur Maschinen umfassen.

Answer 2

Ich sehe nicht, warum ein Schauspieler ein Mensch sein sollte - Ihr Beispiel ist ein absolut guter Grund dafür nicht zu sein.

Die Sache mit einer solchen Methode ist nicht, sich daran zu hängen, an den Einzelheiten der definierten Praxis festzuhalten. Selbst wenn die Leute, die ursprünglich den Begriff "User Stories" erfunden haben, meinen, dass sie nur für Menschen gelten sollten, gibt es kein Gesetz, das Sie dazu zwingt, streng an ihren Konzepten festzuhalten.

Der ganze Sinn der User Stories, agilen, gedränge, und alle anderen Methoden ist zu mit dem Entwicklungsprozess zu unterstützen, nicht zu seine der Entwicklungsprozess. Eine Methode ist nur wertvoll, solange sie den Prozess verbessert, also sollten Sie sie verwenden. Sie sollten sich frei fühlen, die Methodik an Ihre individuellen Umstände anzupassen. Lassen Sie die Methodik nicht wichtiger werden als die eigentliche Code-Entwicklung.

Answer 3

Hier ist das Geheimnis. Es handelt sich nicht um User Storys, sondern um Benutzerszenarien.

Die Benutzer ist die Sache, die die Interaktion - die Maschine oder eine Person.

Die Stakeholder ist die Person oder das Unternehmen, die den Nutzen aus der Interaktion (es ist nie eine Maschine; nicht in diesem Stadium in AI-Entwicklung sowieso). In der Regel gibt es mehrere Interessengruppen mit konkurrierenden Bedürfnissen für ein bestimmtes Projekt. Der primäre Stakeholder kann aufgespürt werden, indem herausgefunden wird, wer für das Projekt bezahlt und warum.

Der Benutzer ist selten jemals der primäre Stakeholder. Normalerweise möchte ein Stakeholder, dass ein Benutzer etwas tut, damit er, der Stakeholder, profitieren kann.

Zum Beispiel möchten Twitter-Investoren, dass Nutzer Twitter genießen, so dass sie alle ihre Möglichkeiten behalten können, Geld in der Zukunft zu verdienen. Chefs wollen, dass ihre Sekretäre Textverarbeitungsprogramme verwenden, damit sie Briefe schneller tippen und in letzter Minute ihre Meinung ändern können. StackOverflow möchte, dass großartige Beiträge hochgestuft werden, damit sie ihre Werbeeinnahmen erzielen können.

Here's a blog post, die ich zu dem Thema schrieb, einschließlich einer Vorlage, die Sie verwenden können, um die Anliegen von Benutzer und Stakeholder zu trennen.Ich überlasse es Ihnen als Übung, sich vorzustellen, wer davon profitiert, wenn Sie, der Benutzer des Posts, es lesen.