Sind technische User Stories in Scrum erlaubt? Wenn ja, wie lautet die Standardvorlage zum Schreiben technischer User Stories in Scrum? Ist es das gleiche As a <user> I want to do <task> so that I can <goal>?
Ich habe in einigen Blogs gelesen, dass als Entwickler keine User Story ist , aber ich habe auch gelesen, dass Scrum diese nicht vorschreibt. Es gibt nur wenige Blogs , wo sie geteilt haben User Storys mit System als Benutzer , es ist wie as a <user who is not end user> i want to <system functionality> so that <some techinical thing>. Welches ist der Standard?
Zum Beispiel gibt es User Stories wie:
Als Rezensent möchte ich Fotos von jedem Hotel / Essen hochladen, damit andere Benutzer sie sehen und mögen können
Als Benutzer möchte ich Fotokommentare hinzufügen, damit ich meine Ansicht besser erklären kann
Für diese beiden User Stories gibt es jetzt einen großen technischen Punkt - das Speichern und Abrufen des Bildes
Kann ich also eine technische Geschichte mit dem Titel "Mechanismus zum Speichern und Abrufen von Bildern" mit der folgenden Beschreibung hinzufügen?
Als Entwickler möchte ich einen Mechanismus zum Speichern und Abrufen von Bildern entwickeln, damit Benutzer Bilder hinzufügen / anzeigen können, wo immer dies erforderlich ist
quelle
Antworten:
Technische Geschichten sind erlaubt, aber ich würde Ihnen raten, sie so weit wie möglich zu vermeiden.
Zum Beispiel kann Ihre Geschichte zum Speichern und Abrufen von Bildern einfach als zwei reguläre User-Geschichten geschrieben werden
(Beachten Sie, dass dies davon ausgeht, dass das Bild in Ihrer ursprünglichen Upload-Story nach dem Upload nicht dauerhaft gespeichert wird. Obwohl dies seltsam aussehen mag, ist es eine gültige Methode, Storys aufzuteilen, um sie verwaltbar zu machen.)
(Dies bedeutet, dass gespeicherte Bilder später abgerufen werden können.)
Technische Geschichten sollten für Arbeiten reserviert werden, die für die Organisation wichtig sind, aber für die Benutzer nicht direkt als Merkmal / Funktionalität sichtbar sind. Fügen Sie beispielsweise einen Lastausgleich hinzu, um eine größere Anzahl oder Anforderungen zu verarbeiten.
quelle
In Anbetracht Ihres Beispiels stellt sich die Frage, warum ein Entwickler einen Mechanismus zum Speichern und Abrufen von Bildern entwickeln möchte, damit Benutzer Bilder hinzufügen / anzeigen können, wo immer dies erforderlich ist, es sei denn, ein Benutzer möchte Bilder hinzufügen oder anzeigen.
Das heißt, während Ihre Frage gut ist, ist das Beispiel nicht. Dies ist eine Benutzerfunktion und sollte eine User Story haben. Und wenn der Benutzer diese Funktionalität nicht wirklich benötigt, sollte der Entwickler dies nicht tun wollen.
Eine technische Geschichte ist mehr: "Als Entwickler möchte ich die Duplizierung in den Datenarchivierungsmodulen reduzieren, damit ich nicht jede Änderung an 6 Stellen vornehmen muss."
Die Frage, ob diese in den Sprint aufgenommen werden sollen, ist schwierig und hängt etwas davon ab, wen Sie als Ihren Kunden betrachten. Ist es der Endbenutzer oder das Unternehmen, das Sie beschäftigt, oder das Unternehmen, das das Unternehmen beschäftigt, das Sie beschäftigt?
Viele Branchenmeinungen werden von Personen durchgeführt, die für Beratungsunternehmen arbeiten. Aus dieser Perspektive kann ich das Argument sehen, dass Entwicklergeschichten schlecht sind. Sie sollten nur ein Teil dessen sein, was Sie täglich tun, unsichtbar für das Unternehmen, das dafür bezahlt. Diese Unternehmen wissen instinktiv, dass zu hohe Rechnungen dafür sorgen, dass Ihre Arbeit versiegt. Daher arbeitet jeder Entwickler nach dem Prinzip, nur technische Entwicklungen durchzuführen, die Ihre Entwicklungszeit verbessern oder Ihre Fähigkeit verbessern, fehlerfreie Software freizugeben.
Meine Erfahrung besteht eher darin, in internen Teams zu arbeiten und Software direkt an das Unternehmen zu liefern, das meine Löhne zahlt. In vielen dieser Unternehmen besteht eine Vertrauensbarriere zwischen dem Unternehmen und dem technischen Flügel des Unternehmens. In allen von ihnen gibt es eine andere Mentalität, bei der sinkende Kosten ebenso wie steigendes Einkommen sind.
In diesen Umgebungen kann es hilfreich sein, wichtige Entwicklergeschichten zu definieren. Es erhöht die Sichtbarkeit, schafft Vertrauen und ermutigt Entwickler und Management, über den Wert solcher Aufgaben für das Unternehmen nachzudenken und entsprechende Prioritäten zu setzen.
Letztendlich schlage ich vor, dass Sie es versuchen. Und wenn es keinen Wert bietet, hören Sie damit auf.
Aber mein Instinkt sagt, wenn Sie den Wert dieser Entwicklung für das Unternehmen in Betracht gezogen hätten, hätten Sie nicht einmal versucht, daraus eine Entwicklergeschichte zu machen. Es ist entweder gut für den Endbenutzer oder nicht. Wenn dies nicht der Fall ist, hat das Geschäft keinen Wert.
quelle
Das ist eine gute Frage. Ich habe keine offizielle Antwort, aber wo ich arbeite, fügen wir technische User Stories hinzu und nennen sie technische Schulden. Wenn sie nicht erlaubt wären, würde ich einen anderen Weg finden, sie hinzuzufügen, nur um meine Arbeit aufzuzeichnen und dem Unternehmen mitzuteilen. Ebenso erinnert uns diese Dokumentation daran, was für zukünftige Projekte benötigt wird.
Wenn wir in einer neuen Anwendung keine technischen Storys hinzufügen dürfen, besteht die Unterbrechung beispielsweise darin, dass ich nach dem Start eines Sprints, der Datenbankmodelle erstellt und auf die Genehmigung durch meinen Datenmodellierer wartet, eine Woche lang mitsummiere sie iterieren mit dem Modellierer und wenn Sie fertig sind, senden Sie die Skripte an die Datenbank und warten Sie, bis sie die Datenbankobjekte erstellt haben. In der Zwischenzeit werde ich ein neues Codeprojekt, einige grundlegende ORM-Funktionen und mein Layout für die Quellcodeverwaltung erstellen. Wenn alles gesagt und getan ist, habe ich Zeit, eine leere Zielseite zu erstellen und bereitzustellen.
Tag für Tag, während dies geschieht, klettert das Geschäft, wenn ich die Informationen nicht aufzeichne, dass unser Team nicht an dem Projekt arbeitet, obwohl wir es tatsächlich sind. Wenn wir diese Elemente in den Geschichten haben, können wir unsere Arbeit abhaken, die Arbeit dokumentieren und dem Unternehmen mitteilen, dass wir Fortschritte machen.
Wenn es eine bessere Best Practice gibt, bin ich ganz Ohr.
quelle
Mein persönliches Gefühl ist, dass Teams nicht zu sehr auf das angewiesen sein sollten, was Scrum erlaubt, und sich mehr Sorgen darüber machen sollten, was für das Team funktioniert. Ein Teil der Grund dafür , dass gedränge ein bisschen ein schlechter Ruf bekommen hat , ist , dass Praktiker kann sich Prozess konzentriert , die auf die Ideen , die hinter agilen Projektmanagement gegensätzlich ist.
Ich werde jetzt aus meiner Seifenkiste steigen, aber wenn Sie sich fragen, ob das Folgende wirklich "Gedränge" ist, lesen Sie bitte das Obige (erneut).
Es ist wichtig, die in den User Stories definierten "Funktionen" von den "Leistungen" zu trennen, die das technische Team bereitstellen muss, um diese Funktionen zu unterstützen. In diesem Fall ist das Speichern und Abrufen von Bildern ein technisches Ergebnis, das Sie (als technisches Team) implementieren müssen. Nahezu jede Geschichte benötigt einige technische Ergebnisse.
Der Grund, warum dies wichtig ist, ist, dass ein technisches Ergebnis (für sich) aus Anwendersicht keinen Wert erzeugt. Wenn Sie anfangen, technische Ergebnisse als User Stories zu verfolgen, können Sie leicht in die Falle tappen, technische Ergebnisse als geschäftlichen Wert zu betrachten. Wenn Sie das Wasser auf diese Weise trüben, verwechseln Sie Arbeiten, die Geschäftsziele unterstützen (dh Dinge, die Geld kosten), mit tatsächlichen Geschäftszielen (dh Dinge, die Geld verdienen).
quelle
teams should not be too hung up on what scrum allowsist problematisch. Dies ist ein Hauptgrund dafür, dass das Scrum- Framework weiterhin missverstanden wird. Frachtkulte, die in der Praxis nicht einmal korrekt sind, werden durch anhaltende Unwissenheit verewigt.Alle oben genannten Antworten verweisen nicht auf das maßgebliche Quelldokument für das Scrum-Framework: The Scrum Guide .
Der Fokus sollte auf der Wertschöpfung liegen. Manchmal kommt dieser Wert von technischer Arbeit wie der Aktualisierung der Infrastruktur. Schließen Sie diese Artikel nicht aus!
Der Begriff User Story wird im Scrum Guide nie angezeigt, weil
Die Verwendung einer User Story ist nur eine mögliche Technik zum Aufzeichnen der PBIs. Obwohl es üblich ist, das Format "Wie ich will, also das" zu sehen, kann es seiner ursprünglichen Absicht widersprechen . Dieses problematische Format wurde auch auf der Agile 2017 angesprochen .
Das Verständnis und die Verwendung von vertikalem Schneiden ist hilfreich, um die Größe der Product Backlog-Elemente (PBIs) zu verringern. Betrachten Sie schneiden , dass einzelne speichern und abrufen Artikel in speichern und abrufen Artikel s .
quelle