Für mich ist es bequemer, Anforderungen in technischen Begriffen zu beschreiben. Ist es also möglich, die Benutzergeschichten in Scrum nicht zu verwenden? Wird es noch agil sein?
Natürlich darfst du! Scrum schreibt nicht vor, welche konkrete Darstellung von Anforderungen Sie verwenden sollten. Im Scrum Guide gibt es überhaupt keinen Begriff wie „User Story“ . Scrum Guide betreibt stattdessen „ Product Backlog Item “.
Scrum Guide erlegt gut definierten (oder „verfeinerten“ in der Scrum-Terminologie) PBI drei Einschränkungen auf:
PBI kann also theoretisch jede Art von Anforderungsdarstellung sein.
Hauptgrund, warum User Story eingesetzt wird: Sie ist kundenorientierter .
Aber wenn Sie Product Owner sind und kein Kommunikationsproblem mit Stakeholdern haben, können Sie mit einer solchen Art von Anforderungsdarstellung arbeiten, wie Sie möchten.
Abschließend Zitat aus Scrum Primer :
Product-Backlog-Einträge sind klar und nachhaltig artikuliert. Entgegen weit verbreiteter Missverständnisse enthält das Product Backlog keine „User Stories“; es enthält einfach Elemente. Diese Elemente können als User Stories, Use Cases oder andere Anforderungsansätze ausgedrückt werden, die die Gruppe für nützlich hält. Unabhängig vom Ansatz sollten sich die meisten Artikel jedoch darauf konzentrieren, den Kunden einen Mehrwert zu bieten.
Wenn es also für Ihre Stakeholder in Ordnung ist, gibt es kein Problem, selbst wenn Sie Anforderungen im „SRS-Stil“ (wie „System soll …“-Phrasen) anwenden.
Eine User Story zu haben ist irgendwie zentral für die Bildung eines Scrum-Teams. Technisch gesehen würde ich sagen, dass Sie kein Scrum machen. Es kann immer noch agil sein, wenn es für Ihr Team und Ihren Kunden funktioniert, aber ...
Die Entscheidung, ob Sie User Stories verwenden oder nicht, sollte nicht auf Ihrer Bequemlichkeit basieren, sondern darauf, was das Team für den Erfolg braucht und was getan werden muss, damit der Kunde am Ende ein qualitativ hochwertiges Produktinkrement erhält Wiederholung.
Wenn das Team genug über den Tellerrand hinaus denken kann (und den geschäftlichen Wert der von Ihnen dokumentierten Arbeitsaufgabe versteht), um eine Lösung zu finden und etwas für einen Kunden in einer Iteration ohne formelle User Story zu erstellen … dann machen Sie es. Wenn Sie Implementierungsdetails für Ihr Team schreiben und es sich wie „Code-Affen“ anfühlt, dann verfehlen Sie den Zweck der Verwendung von Scrum und befähigen das Team, einen inkrementellen Wert für einen Kunden zu liefern.
Technisch nein, gemäß dem 1. Agile-Manifest-Prinzip [„Unsere höchste Priorität ist es, den Kunden durch frühzeitige und kontinuierliche Bereitstellung wertvoller Software zufriedenzustellen.“][1], da technische Anforderungen nur die Details der Implementierung, Bereitstellung, Wartung und nicht der Geschäftswert, den sie dem Produkt bringen.
Je nachdem, wovon Sie sprechen, dass nur technische Anforderungen erforderlich sind, handelt es sich entweder um eine selbsterklärende bestimmte Aufgabe, oder diese Anforderungen sind nicht rein technisch und enthalten immer noch die Erklärung eines Zwecks, dem sie dienen, dh einem geschäftlichen Wert . Da es beim Geschäftswert um den Gewinn geht, den der Benutzer aus der Nutzung dieses Produkts und dieser Funktion erhält, anstatt aus irgendetwas anderem (z. etc.).
Interessante Frage. Schade, dass ich es vorher nicht gesehen habe - es erinnert mich daran, dass der Geschäftswert sowohl funktional als auch technisch kombiniert ist, während die Aufteilung von funktionalen Anforderungen und technischen Anforderungen nur der Einfachheit halber erfunden wurde.
Ewan
Stanislaw Baschkirtsew