Was ist der Weg, um Aufgaben zu erstellen?

Ich habe bereits gelesen: Wie kann man User Stories in Tickets abbilden?

Aber ich habe immer noch Schwierigkeiten zu verstehen, wie ich ein Ticketsystem genau nutzen soll, insbesondere bei Tickets für neue Features.

Nehmen wir an, das Projekt befindet sich an einem Punkt, an dem wir wissen, was wir tun müssen, aber noch nicht mit dem Programmieren begonnen haben. Als erstes möchte ich jetzt alle Anforderungen als Tasks in das Ticketsystem einbringen.

Wie würde ein Task-Ticket aussehen?

Handelt es sich um eine User-Story wie: Als Gast möchte ich mich auf der Website registrieren können, oder soll ich sie in Tickets/Aufgaben aufteilen, z . Ist es eine gute Praxis, User Stories zu verwenden, oder was ist der beste Weg?

Wenn diese Informationen relevant sind: Wir werden das Issue-Tracking-System von github verwenden.

Anforderungen sind keine Aufgaben. Auch User Stories sind keine Aufgaben. Warum tun Sie das und warum ist diese Frage kein Duplikat von pm.stackexchange.com/q/9914/4271 ?
Sind Sie auch sicher , dass pm.stackexchange.com/a/9927/4271 Ihre Frage nicht bereits beantwortet? Die Antwort dort scheint für Ihre Frage genauso relevant zu sein.
"User Stories sind keine Aufgaben" - deshalb frage ich, wie man es richtig macht

Antworten (2)

Tasking wird normalerweise unterhalb der Story-Ebene durchgeführt. Am häufigsten sehe ich Aufgaben, die als Anweisungen geschrieben sind, dh "Mach xyz ... Erstelle etwas ... Recherchiere ABC" usw.

Entwicklungsgeschichten werden im Allgemeinen in 4 verschiedene Aufgabengruppen unterteilt:

  1. Forschung
  2. Implementierung
  3. Codequalität
  4. QA/Testen

Wichtig ist, die Beziehung zwischen der Aufgabe und der übergeordneten User Story aufrechtzuerhalten, da die Story dem Kunden den Wert vermittelt, den die zugrunde liegenden Aufgaben bei der Implementierung ermöglichen sollten.

Wenn Sie Github verwenden, um Ihre Aufgaben zu verfolgen, werden Ihre Geschichten idealerweise auch in Github gespeichert oder zumindest mit einem anderen verwendeten Story-Tracking-Tool querverwiesen. Sonst laufen Entwicklungsmitarbeiter Gefahr, den Kontext der Aufgabe zu verlieren.

Bedenken Sie schließlich, dass die Problemverfolgung und die Aufgabenverfolgung zwei unterschiedliche Aktivitäten sind. Probleme sind oft Elemente, die in Geschichten oder Fehler umgewandelt werden können, nachdem der Produktbesitzer oder ein Lead das Problem überprüft, beurteilt und validiert hat.

Geschichten und Mängel sind die Elemente, die vom Lieferteam beauftragt und bearbeitet werden. Besteht die Gefahr, dass das Lieferteam in nicht aufgabenbezogene Probleme hineingezogen wird, wenn sie im selben System nachverfolgt werden?

Da dies keine große Unternehmenssache sein wird, sondern eher ein Lernprojekt, denke ich, dass es kein Problem sein wird, Aufgaben und Probleme im selben System zu haben. Vielleicht habe ich mich nicht sehr gut ausgedrückt: Ich möchte wissen, wie wir die Dinge, die wir tun müssen, am besten formulieren und im Issue-Tracker von Github speichern.
Sie sagten 4 Gruppen von Aufgaben, aber es sieht aus wie vielleicht 5? Research Implementation Code Quality QA/Testing-- Ich denke, das Wort Qualityist überflüssig ... können Sie das überprüfen?
Könnten Meta-Issues nicht für User Stories verwendet werden? Ein Beispiel für ein Meta-Problem in GitHub ist hier: github.com/dart-lang/sdk/issues/23454
1 Forschung, 2 Implementierung, 3 Codequalität, 4 QA/Testen. Mit Recherche meine ich, herauszufinden, wie man die Geschichte umsetzt. Die Implementierung erledigt die Arbeit, um die Geschäftsanforderungen zu erfüllen. Codequalitätsaufgaben sind nicht funktionale Anforderungen, die mit DoD für das Team übereinstimmen. Dinge wie Refactoring oder das Bezahlen von Tech-Schulden. QA/Testing ist die Domäne der automatisierten und manuellen Tests, um sicherzustellen, dass die Kundenanforderungen erfüllt werden. Deckt auch Dinge wie Leistung und Last ab.

Mein Team rüttelt immer noch an unserem Toolset und unseren Prozessen, aber ich habe vor, zu versuchen, einen GitHub-Meilenstein zu erstellen, der einem Feature oder einer User Story entspricht, wenn wir bereit sind, mit der Zerlegung zu beginnen, dann ein Problem für jede zugehörige Aufgabe einzureichen und ihm zuzuweisen dieser Meilenstein.

Auf diese Weise kann ich (und meine Kunden-Partner und mein Management) leicht die gesamte Arbeit im Zusammenhang mit der neuen Funktion sehen, den Fortschritt durch den Sprint sehen, sehen, wie neue verbundene Arbeit auftaucht, wenn wir feststellen, dass Aufgaben weiter zerlegt werden müssen, und so weiter.

Meilensteine ​​können Fälligkeitsdaten haben, sodass ich diese für das Enddatum des Sprints verwenden kann. Wenn wir in einem bestimmten Sprint an mehreren Funktionen/Geschichten arbeiten, kann ich einfach mehrere Meilensteine ​​​​mit demselben Fälligkeitsdatum haben: Auf diese Weise kann ich den Fortschritt jeder Funktion unabhängig voneinander sehen.

In Ihrem Beispiel könnten Sie also einen Meilenstein mit einem Kurznamen wie „Gast selbst registrieren“ und einer Beschreibung haben, die die eigentliche Geschichte enthält, „Als Gast möchte ich mich bei der Website registrieren können.“ Dann hätten Sie separate Probleme für Erstellen einer Registrierungsseite/eines Registrierungsformulars , Senden einer E-Mail an an den Benutzer, wenn er registriert ist, und so weiter.

Aber wie gesagt, wir haben das noch nicht wirklich versucht; also bin ich gespannt auf andere Antworten.

Ich habe bereits von dem Ansatz gehört, Meilensteine ​​für Features zu verwenden, aber das ist nicht der Weg, den ich gehen möchte. Da ich die Meilensteine ​​für Versionen wie Alpha, Beta, Launch usw. verwenden möchte.
Was ist der Weg, um Aufgaben zu erstellen?
AntwortenHierDatenschutz-Bestimmungen1y, 0v