Ich befinde mich in einer nicht agilen Umgebung, in der „User Story“ eigentlich „Anwendungsfall, unterstützt durch eine Excel-Anforderungsspezifikation, ein Testspezifikationsdokument und ein paar erforderliche Wireframes || eingeworfene Mock-Ups“ bedeutet. Sie wollen agil werden. Wenn die Stimmen im Ohr des Product Owners „User Stories“ hören, werden sie nicht gut damit umgehen. "user story" wird hier jahrelang missbräuchlich verwendet.
Ich dachte, das wäre ein schnelles Google, da ich bezweifle, dass ich die erste Person bin, die darauf stößt.
Wie soll ich mit der nicht standardmäßigen Verwendung von „User-Storys“ umgehen?
Ich warne davor, eine neue Terminologie einzuführen, da Sie damit Leute verwirren, die User Storys korrekt verwenden. Ich würde höchstens versuchen, sie „Agile User Stories“ (oder Scrum User Stories, wenn Sie speziell Scrum verwenden) zu nennen.
Stattdessen würde ich Ihnen raten, zu versuchen, diejenigen aufzuklären, die reflexartig darüber reagieren, wie der Begriff in der Vergangenheit verwendet wurde, und ihnen zu helfen, zu verstehen, was er für die Zukunft bedeutet.
Wenn Sie diesen Kampf jetzt nicht führen, werden Sie sich später mit den Auswirkungen der Einführung nicht standardisierter Terminologie auseinandersetzen müssen. (neue Mitarbeiter gewinnen, die „User Stories“ richtig verwenden, um Ihre Begriffe zu verstehen, Ihre Mitarbeiter dazu bringen, alle externen Bücher/Blogs/Schulungen zu verstehen, die auf „User Stories“ verweisen, Umgang mit Kunden, die „User Stories“ verstehen, aber nicht wissen was Ihr neuer Begriff bedeutet usw.).
Sie sind keine User Stories. Benutzer sind nur eine Art von Stakeholdern.
Betrachten Sie CAPTCHA-Boxen als Beispiel.
Als Benutzer
möchte ich ein CAPTCHA-Feld ausfüllen,
damit ... Moment, was? Nein habe ich nicht!
Es geschieht nicht zum Nutzen des Benutzers. Irgendwo gibt es einen Moderator der Seite, der das braucht, damit er sich nicht manuell durch eine Menge Spam wühlen muss. Ebenso gibt es einige Anforderungen aus Sicherheitsgründen oder aus rechtlichen Gründen oder für Prüfer oder Werbetreibende oder für die Leistung oder für ein anderes Drittanbietersystem oder weil das Altsystem, von dem wir sprechen, ein Problem ist.
Ich stimme Kyle nicht zu. Es geht manchmal um Benutzer, aber oft um Stakeholder, deren Ziele erfüllt werden müssen, damit die Benutzer etwas bekommen. Bei internen Projekten geht es fast immer darum, anderen Nutzern und Stakeholdern Nutzen zu bringen. Ich nenne sie seit einiger Zeit „Stakeholder Stories“ (obwohl es keine Geschichten sind) und habe festgestellt, dass dieser Begriff Teams dabei hilft, zu erkennen, wer die wahren Stakeholder sind. Sie bezeichnen sie normalerweise nur als "Geschichten", was für mich in Ordnung ist.
Meiner Erfahrung nach führt der Vorwand, dass sich Geschichten auf Benutzer konzentrieren sollten, dazu, dass die Bedürfnisse anderer Interessengruppen zurückgedrängt oder nur als „technische Geschichten“ behandelt werden, die dann neben anderen als Bürger zweiter Klasse geliefert werden müssen.
Das Nachdenken über die geschäftlichen Auswirkungen und die echten Stakeholder, die Feedback geben müssen, kann wirklich dazu beitragen, das Projektrisiko anzugehen.
Ich empfehle daher, dass eine Story ein Stück eines Features sein sollte, das erstellt wurde, um entweder Feedback zu erhalten oder Vertrauen zu gewinnen, wobei der Fokus auf dem Stakeholder liegt, der sich interessiert. Ich mag die Feature-Injection-Vorlage:
Um <ein Ziel zu erreichen>
Als <der Stakeholder, der es will>
möchte ich, dass < einige Benutzer > < etwas > tun.
Wenn Sie kein Vertrauen in die Stakeholder haben, liefern Sie ihnen etwas, um zu zeigen, dass Sie Fortschritte machen können, und gewinnen Sie ihr Vertrauen. Wenn Sie ihr Vertrauen haben, zeigen Sie ihnen etwas, das wahrscheinlich ihr Feedback benötigt. Es wird wahrscheinlich etwas Neues sein, das noch nie zuvor ausprobiert wurde (oder von sehr vielen Leuten noch nicht ausprobiert wurde).
Wenn Sie das tun, spielt es keine Rolle, wie Sie sie nennen. Aber ich würde es vorziehen, den Begriff "Benutzer" nicht zu verwenden, es sei denn, er bedeutet es wirklich.
Vielleicht möchten Sie in Betracht ziehen, nur „Fall“ zu verwenden, da die Mitarbeiter in Ihrem Unternehmen mit dem Begriff vertraut sind, aber nur neu definieren, was einen Fall ausmacht.
"Wir ändern die Art und Weise, wie wir Fälle spezifizieren" könnte sich einfacher verkaufen als "wir hören auf, Fälle zu bearbeiten und machen x".
Wenn Sie der Meinung sind, dass Sie die verwendete Terminologie wirklich ändern müssen, könnte eine der folgenden Methoden funktionieren.
Zugegeben, die meisten davon werden in einigen agilen Kontexten verwendet, aber sie sind so allgemein, dass Sie damit einverstanden sein sollten.
DefyGravity