Ich hatte eine Diskussion im Team, um eine Epicfür alle technical-debtsim Projekt zu erstellen. Das Problem ist, dass Epic per Definition nicht mehr als ein Viertel spawnen sollte, aber wenn wir ein Epic für technische Schulden erstellen, kann es für die Dauer des Projekts laufen. Ich habe im Internet gesurft, aber nichts gefunden. Bitte helfen Sie mit den richtigen Agile-Richtlinien.
Ein Epos ist eine große Geschichte . Eine, die in Stories heruntergebrochen werden muss, die bequem in Sprints passen. Es ist nicht wirklich dazu gedacht, Geschichten in einer Kategorie zusammenzufassen.
Tun Sie jedoch das, was für Ihr Team am besten ist. Wenn Sie feststellen, dass die Gruppierung von technischen Schuldenaufgaben unter einem Epos Ihnen hilft, sie zu verfolgen, dann ist das in Ordnung.
Mein bevorzugter Ansatz in JIRA ist die Verwendung eines „technischen Schulden“-Labels für Storys/Aufgaben, die sich auf technische Schuldenarbeit beziehen. Auf diese Weise können Sie bei Bedarf technische Schuldenarbeiten ein-/ausfiltern.
Die richtige agile Richtlinie lautet, dass Sie das tun sollten, was für Sie und Ihr Team am besten funktioniert.
Es gibt kein Richtig oder Falsch bei der Verwendung eines Epic, um die technischen Schulden im Projekt zu kennzeichnen. Aber es ist auch nicht erforderlich, dass alle Geschichten mit einem Epic verknüpft sind.
Also müssen wir über technische Schulden diskutieren
Sie sammeln technische Schulden an, wenn Sie einen strategischen Kompromiss eingehen (um ein Datum einzuhalten oder etwas zu versenden), aber dies ist eine kurzfristige Sache, Sie sollten es so schnell wie möglich beheben , möglicherweise durch Hinzufügen einer neuen Geschichte im nächsten Sprint (wahrscheinlich als Teil des ursprünglichen Epos), um es zu beheben.
Wenn Sie eine große Ansammlung kompromittierter Elemente haben, an denen seit einiger Zeit nicht mehr gearbeitet wurde, handelt es sich nicht um technische Schulden, sondern um schlechtes Design oder schlechte Entwicklungspraktiken .
Sie müssen neue Geschichten erstellen, um diese zu beheben und sie zu priorisieren. Sie müssen wahrscheinlich etwas Zeit/Geschwindigkeit pro Sprint priorisieren, um sie zu bewältigen (anstelle neuer Arbeit).
Fügen Sie sie nicht zu einem Epos hinzu, sie werden am Ende depriorisiert und nie fertig. Sie können sich auch mit Geschwindigkeit belohnen, wenn Sie sich mit Dingen befassen, die beim ersten Mal richtig hätten sein sollen.
Sie müssen Zeit blockieren, um zu zeigen, dass die Beeinträchtigung von Ergebnissen wie dieser die Geschwindigkeit verringert und daher vermieden werden sollte.
Wie bereits gesagt, ist dies kein agiles Problem, sondern eher eine Frage, wie man bestimmte Probleme in JIRA gruppiert. Ich habe dafür die Sprints von JIRA verwendet. Es gibt keine automatische Gruppierung nach Label oder Epic im Backlog, daher ist es schwierig, alle Probleme mit „technischen Schulden“ an einem Ort zu sehen, es sei denn, Sie sortieren sie manuell. Also füge ich solche Probleme einem „Technical Debt“-Sprint hinzu, der kein Sprint an sich ist, sondern eine Möglichkeit, sie zu gruppieren.
Alan Larimer
Todd A. Jacobs