Wir versuchen, unsere Epics besser zu organisieren. In der Vergangenheit blieben die Epics auf Jira unbegrenzt offen. Jedes Support-/Bug-Ticket für die Produktion wird dem bestehenden Epic hinzugefügt. Da wir jedoch Epics verwenden, um unsere Roadmap zu verfolgen (im Grunde haben wir ein Plugin, das die Epic-Timeline anzeigt und was gerade aktiv ist. Es ist sehr nützlich, ein großes Bild zu geben, da wir viele Epics haben), die unbegrenzt offenen Epics rendern dies Fahrplan nutzlos.
Wir haben uns entschieden, das Epic zu schließen, sobald alle Ausgaben in diesem Epic geschlossen sind. Das Problem ist nun, wo sollen Produktionsfehler/Support-Tickets platziert werden, wenn das entsprechende Epic geschlossen ist? Wenn wir sie zu ihrem jeweiligen Epic hinzufügen, werden wir zurück sein, um das Epic immer offen zu halten, was wir nicht wollen. Wenn wir sie keinem Epic zuweisen, ist es schwierig, den Supportaufwand zu verfolgen, der sich aus bestimmten Epics ergibt.
Hatte jemand ein solches Problem?
Außerhalb des Jira-Kontexts stellt ein Epic eine Art lieferbaren Geschäftswert dar. Ein Epic besteht normalerweise aus guten Geschichten , der volle Wert wird für den Kunden und die Benutzer realisiert, nachdem alle Geschichten fertiggestellt und geliefert wurden. Nicht alle Geschichten müssen Teil eines Epos sein. Ich würde auch sagen, dass andere Arten von Backlog-Elementen, wie z. B. Elemente, die technische Schulden oder Fehler darstellen, nicht Teil eines Epics wären.
Ich neige dazu, Epics zu verwenden, um Arbeiten darzustellen, die sich über mehrere Iterationen erstrecken, obwohl ich auch einen Wert darin sehe, verwandte Storys gemäß der Definition eines Epos zu gruppieren. Es ist auch an eine Veröffentlichung gebunden – obwohl die Geschichten in den meisten Fällen unabhängig voneinander veröffentlicht werden könnten, neige ich dazu, ein Epic sofort in Produktionsumgebungen zu veröffentlichen, während ich die Arbeit viel regelmäßiger in Test- und Demonstrationsumgebungen einsetze. Das Epos macht die Arbeit sichtbar, während sie die Zustände durchläuft. Zu den Zuständen gehören beispielsweise „Offen“, „In Bearbeitung“, „Überprüfen“, „Testen“, „Freigegeben“. Stories bewegen sich von Open bis Released, um zu bedeuten, dass sie sich in der Test-/Demoumgebung von Epic befinden und codiert, Code überprüft und getestet wurden. Das Epic macht dasselbe, geht aber in den Review, wenn es mit dem Hauptentwicklungszweig zusammengeführt wird, und in den Test, wenn die endgültigen Regressionstests stattfinden.
Ich würde mir ansehen, warum Sie ständig neue Fehler und Geschichten zu Epics hinzufügen. Anscheinend versuchen Sie, Jira Epic als Release oder Tag zu verwenden, die beide auch in Jira vorhanden sind. Anstatt zu versuchen, den Wartungs- und Supportaufwand von Epic zu verfolgen, verfolgen Sie ihn nach Dingen wie Komponenten oder einer bestimmten Version zugewiesen. Bei Bedarf können Techniken zur Ursachenanalyse angewendet werden, um zukünftige Arbeiten auf bestimmte Epics zurückzuverfolgen, und Sie können wiederum Tags oder vielleicht eine Art benutzerdefinierter Felder verwenden, um die Supportarbeit mit der Arbeit zu verknüpfen, die sie verursacht hat.