Epen vs. Projekte vs. etwas anderes

Wir haben gerade angefangen, JIRA zu verwenden, und ich richte es jetzt ein.

Wir haben ein riesiges Produkt und ein externes Team, das das Produkt entwickelt und unterstützt.

Unser Produkt umfasst viele Projekte. Das Entwicklungsteam wird in jedem Sprint an mehreren verschiedenen Projekten arbeiten.

Wie können wir dafür einen Workflow in JIRA einrichten?

Sollten wir alle unsere Projekte als ein einziges Projekt in JIRA kombinieren?

Wie können wir Geschichten aus verschiedenen Projekten in einem einzigen Sprint kombinieren?

Vielleicht sollten unsere Projekte eigentlich Epics sein? Oder etwas anderes?

UPD

Entschuldigung für die Verspätung. "Projekt" ist für uns ein Teil unserer großen Website. Zum Beispiel „Suche 2.0“ oder „Integration mit XYZ“. Projekt hat Fristen. "Projekt" kann durchgeführt werden. Es hat nicht von Anfang an Umfang und Team.

Können Sie uns näher erläutern, wie diese „Projekte“ aussehen? Meinen Sie Projekt im Sinne einer „Tätigkeit zur Erreichung eines Ziels“ oder meinen Sie Projekt wie in „Codelösung“.
Wird nach der Frage von rb erwartet, dass sich die Projekte ständig weiterentwickeln oder nicht miteinander verbunden sind?
Entschuldigung für die Verspätung. siehe upd.

Antworten (2)

Wenn Sie möchten, dass sich mehrere „Projekte“ auf demselben Scrum-Board-Sprint befinden, können Sie dies erreichen, indem Sie ein Board mit dem JQL-Filter so einstellen, dass es aus mehreren JIRA-Projekten liest (z. B. „Projekt = MultiTestOne ODER Projekt = MultiTestTwo ORDER BY Rang ASC'). Boards und Projekte werden standardmäßig 1-zu-1 eingerichtet, wenn Sie ein Projekt erstellen, aber nichts hindert Sie daran, die JQL später zu ändern.

Was Epics angeht: Ohne weitere Informationen darüber, was genau Sie mit "Projekt" meinen, kann ich keine Meinung darüber abgeben, ob sie über Epics Sinn machen würden oder nicht. Wenn es funktioniert und jeder in Ihrem Team damit einverstanden ist, sehe ich nicht ein, warum nicht. Im Kern sind alle Epics in JIRA einfach eine Möglichkeit, Issues zu gruppieren.

Ohne weitere Informationen kann ich unmöglich für Sie entscheiden, welche der beiden (oder vielleicht dritten) Optionen für Ihre Situation die beste ist. Sie müssen mit dem Team besprechen, was am sinnvollsten ist.

Als Nebenbemerkung hast du das gesagt

Das Entwicklungsteam wird in jedem Sprint an mehreren verschiedenen Projekten arbeiten.

Was ist der Grund dafür? Sind die Projekte eng miteinander verbunden? Sind sie nur so klein, dass es unmöglich ist, nur ein einziges Projekt pro Sprint durchzuführen? Wenn das Entwicklungsteam während eines Sprints an einer Vielzahl unabhängiger Aufgaben arbeitet, sollten Sie einen anderen Ansatz als Scrum in Betracht ziehen, z. B. Kanban.

Warum arbeitet devteam an vielen Projekten? Weil sie für uns groß und äußerlich sind. Wir bereiten Geschichten aus verschiedenen Projekten für unser großes Entwicklerteam vor. Vielleicht ist es nicht der effektivste Ansatz. Aber es ist so.

Verwenden Sie JQL, um Projekte in einem einzigen Board anzuzeigen, dann können Sie Sprints mit Problemen aus mehreren Projekten planen,

Da das Team / die Rollen jedoch gleich sind (ich gehe davon aus, dass die Projekte Zweige eines großen Produkts sind), verwenden Sie denselben Workflow für alle Projekte (nicht unbedingt erforderlich, aber einfacher für die Berichterstattung).

Auch Ihre Projekte müssen in diesem Szenario nicht nur Epics sein. Wenn sich die kleineren Projekte zu großen Produkten entwickeln, wird der Ärger ausreichen, um Selbstmord zu begehen.

siehe auch https://answers.atlassian.com/questions/64932/combining-multiple-projects-into-1-sprint

Bleib ruhig und JQL es.

Epen vs. Projekte vs. etwas anderes
AntwortenHierDatenschutz-Bestimmungen1y, 0v