Ich habe eine Aufgabe in meinem Jira-Backlog, von der ich nicht weiß, ob sie in einer User Story enthalten sein sollte. Es gibt Aufgaben im Zusammenhang mit Entwicklung, Server, Konfiguration usw. Der Benutzer hat nicht darum gebeten, diese Aufgaben/Funktionen zu haben, aber als Entwickler wissen wir, dass wir sie haben müssen. z.B:
Minimieren Sie Code mit der Gulp-Aufgabe
Ich könnte diese Aufgabe wie folgt in eine User Story umwandeln:
Ich könnte die Rolle für den Entwickler ändern, aber das wird keine User Story sein :
Ist diese Aufgabe ein gutes Beispiel für das Erstellen von User Storys, wo es keine User Story gibt? Eine User Story mit (zu) allgemeinen Aufgaben. z.B:
Oder sollte ich es einfach als einfache Aufgabe (keine User Story) in meinem Backlog haben:
Weitere Beispiele für technische User Stories:
Das Erstellen von User Stories dient dazu, die Konversation in Gang zu bringen und dem Team den Kontext zu geben, um das vorliegende Problem zu verstehen und die richtige Lösung zu erstellen. Außerdem zwingt es den Autor, über den Mehrwert nachzudenken, den es hinzufügt. Die Verwendung von etwas wie INVEST ist hier sinnvoll.
Wenn der Wert der technischen Aufgaben klar ist, denke ich, dass die Verwendung eines User-Story-Formats nur Zeitverschwendung ist. Fragen Sie sich, warum Sie es in einem solchen Format schreiben möchten, was gewinnen Sie? Nur alle Aufgaben im selben Format zu schreiben, ist ein ungültiger Grund, wenn Sie mich fragen.
In Ihrem Beispiel möchten Benutzer die Website nicht minimieren, das ist die Lösung. Sie wollen, dass es schneller wird, aber tun sie das wirklich oder denkt ein Entwickler, dass die Benutzer das wollen? Das Schreiben einer User Story über „Benutzer, die eine schnellere Website wünschen“ könnte zu mehr Lösungen führen, als sie nur zu minimieren.
Stellen Sie den Wert in Frage, finden Sie einen Weg, dies zu tun, beschränken Sie sich nicht auf das Format der User Story. Finden Sie heraus, was für Sie für jede Art von Aufgabe funktioniert. Ich wäre mit einfachen und klaren Aufgaben in meinem Backlog zufrieden, solange wir es INVESTIEREN können.
Am Ende geht es nur darum, die Arbeit zu erledigen! :)
Ich habe eine Aufgabe in meinem Jira-Backlog
Wo kommst du her? Typischerweise verwaltet der Product Owner das Product Backlog und fügt User Stories hinzu, um zu zeigen, was er will.
Der Benutzer hat nicht nach diesen Aufgaben/Funktionen gefragt, aber als Entwickler wissen wir, dass wir sie haben müssen
Sprechen Sie dann mit dem Product Owner und erklären Sie ihm den Wert der Arbeit. Ich bin mir sicher, dass der Product Owner den Sinn der Arbeit erkennen und eine Story erstellen wird, die den Wert für die Benutzer deutlich macht.
Wenn Sie jedoch über routinemäßige Entwicklungsaufgaben sprechen (wie das Einrichten von Umgebungen, das Hinzufügen von Konfigurationen usw.), fügen Sie sie einfach als separate Aufgaben hinzu (kümmern Sie sich nicht um das User-Story-Format). Es liegt in der Verantwortung des Entwicklungsteams, ein Qualitätsprodukt zu liefern. Sie müssen nicht jede einzelne Aufgabe rechtfertigen, die sie tun, um das zu erreichen.
Alternativ können Sie sie unter eine vorhandene User Story packen. Angenommen, die erste Geschichte, die Sie in einem Sprint planen, ist die Einrichtung der Willkommensseite für die Website. Fassen Sie alle technischen Aufgaben, die Sie benötigen, in dieser Geschichte zusammen (z. B. Abrufen des SSL-Zertifikats, Konfigurieren des Proxys usw.). Auf diese Weise liefern Sie mit der ersten Story auch ein veröffentlichbares Inkrement.
Dadurch wird die Geschichte größer, aber das ist in Ordnung, da es einfach die Arbeit widerspiegelt, die Sie tun müssen, um die erste Geschichte herauszubringen.
Es ist nicht ungewöhnlich, dass Scrum-Teams im ersten Sprint nur eine Story liefern. Aus dem oben genannten Grund haben sie die gesamte Gründungsarbeit in diese erste Geschichte gepackt.
Bei jedem Projekt werden Geschichten in einem Kontext von Annahmen geschrieben. „Die Website wird gehostet“, „Benutzer haben Zugang zum Internet“ usw
Manchmal werden diese mit einer „Definition of Done“ oder einer Reihe von „technischen Anforderungen“ verdeutlicht, die für jede Story gelten. Aber ich würde vorschlagen, dass Sie sie als "Sprint 0" angreifen.
In Sprint 0 richten Sie die Umgebung und die Frameworks ein, die Sie verwenden werden, wählen Sprachen und Frameworks aus, kaufen Domänennamen usw. Dies würde Continuous Integration- und Deployment-Skripte umfassen, sodass das Komprimieren und Bündeln von Skripten usw. in den Build-Prozess integriert wird. In Ihrem speziellen Fall 'Erstellen Sie ein Build-Skript, das Gulp für alle Dateien ausführt'
Die Idee ist, alle Einrichtungsaufgaben aus dem Weg zu räumen, damit Sie sich auf die Bereitstellung von Funktionen für das Projekt konzentrieren können, anstatt ständig von technischen Blockaden getroffen zu werden, „wir müssen auf die Firewall warten“ oder „CI ist wieder kaputt“.
Am Ende von Sprint 0 sollten Sie ein grundlegendes "Hallo Welt"-Projekt haben und mit Einheiten-/Integrations-/Akzeptanztests oder anderen grundlegenden Anforderungen leben, die Sie haben.
Von da an geht es darum, diesem Basisprojekt zusätzliche Funktionen hinzuzufügen, die der Vorlage dessen folgen, was bereits vorhanden ist. Anstatt technische Lösungen erfinden oder diskutieren zu müssen.
aqwert