Ich kämpfe mit Jira und Confluence. Mein Team und ich entwickeln eine Anwendung und sind uns nicht sicher, wie wir unsere JIRA-Umgebung perfekt strukturieren sollen. Für unseren Entwicklungsprozess verwenden wir Kanban.
Jetzt haben wir für jede App (Android, iOS, Web und das Backend) separate Projekte in JIRA. Wir müssen also jedes Epos und jede Geschichte 4 Mal erstellen. Das ist nicht sehr effizient. Ist es besser, ein Projekt in JIRA zu erstellen, zB "Software Project", und dort mehrere Boards für jede App darin zu erstellen?
Ist es richtig, mit der Erstellung einer Produktanforderung in Confluence zu beginnen, dort unsere User Story zu definieren und diese Stories in JIRA zu erstellen? Ich meine, jede App hat die gleichen Epen und Geschichten, aber sie haben unterschiedliche Aufgaben. Wie gehen wir damit um?
Was ist die perfekte Struktur in JIRA und der beste Workflow zwischen Confluence und JIRA für unseren Workflow? Wir freuen uns darauf, Portfolio zu verwenden. Ist es empfehlenswert?
Es hört sich so an, als ob Sie an Ihrem aktuellen Setup hängen könnten, aber ich würde Ihnen empfehlen, die vierfachen Geschichten zu überdenken.
Behaupten Sie wirklich, dass Sie mit dem Android-Element fertig sind, aber nicht mit dem Back-End, und Sie können mit dem nächsten Android-Element fortfahren?
Stattdessen würde ich empfehlen, dass Sie ein einzelnes Element auf Ihrem Kanban-Board haben und dass es alle Ebenen (Android, iOS, Web und Back-End) umfasst.
Das Element „Ich möchte meinen Benutzernamen ändern“ ist nur fertig , wenn es auf allen Plattformen funktioniert.
Dies setzt voraus, dass Ihre Anwendung auf allen Plattformen gleich sein soll. Wenn Sie damit einverstanden sind, dass Ihre iOS-App drei Monate hinter der Webversion zurückliegt, sind separate Elemente sinnvoll.
Es hört sich so an, als wären Sie besser dran, wenn Sie Ihre Projekte in Epics (Android, iOS, Web und Back-End) umwandeln, da dies Ihnen in Kanban eine bessere Sichtbarkeit einer Swimlane-Ansicht der Aufgaben in Jira verschaffen würde.
Dies würde es Ihnen auch ermöglichen, gemeinsam genutzte Funktionen, die nur einmal für die drei Versionen des Produkts ausgeführt werden müssen, wie Back-End-Prozesse, einfacher zu identifizieren. Sie würden auch weniger Duplizierung von Geschichten haben.
Sie könnten mehr geräteübergreifende Epics verwenden und vor den Stories weiter aufschlüsseln (z. B. UI, Admin-Panel, Checkout).
@Fred vom Jupiter, können Sie uns mitteilen, wie viele Teams und welche Domänen Sie pro Team haben? Wie ich sehe, haben Sie 4 Produkte:
Wenn Sie ein einzelnes Team haben, das all diese Projekte abwickelt. Ich sehe keinen Sinn darin, jeweils 4 Projekte zu erstellen. Denken Sie an Projekte, nicht nur aus Produkt-POV, sondern auch aus Team-POV.
Manchmal finde ich es besser, Projekte von Teams zu organisieren, die an Produkten arbeiten.
Beispiel:
Team 1 (T1) – Arbeitet an Produkt 1 (P1), Produkt (P2); Team 2 (T2) – Arbeitet an Produkt 3 (P3); Team 3 (T3) – Arbeitet an Produkt 4 und gelegentlich an P2 und P3;
Ich werde zwei JIRA-Projekte:
Wenn T3 jedoch Geschichten übernehmen oder an Geschichten von JIRA1 arbeiten muss, werde ich diese Geschichten auf sie übertragen.
Normalerweise verwende ich Labels, um nachzuverfolgen, welche Funktion von welchem Produkt stammt, da Anforderungen von Produkten manchmal projektübergreifend oder projektübergreifend sein können.
Denken Sie daran, dass Sie Geschichten nach dem Prinzip des Kuchens schneiden sollten. Vielleicht möchten Sie überdenken, wie Teams strukturiert sind, um den Funktionsfluss zu optimieren, anstatt sie in Abteilungs-/Funktionsbereichen zu halten.
Todd A. Jacobs