Einzelnes Jira-Projekt für mehrere Scrum-Teams

Ich habe festgestellt, dass Jira-Projekte Produkten am besten entsprechen. Dies ermöglicht eine bessere Nutzung der Funktionen rund um Releases, Komponenten und Testfallverwaltung (wenn Sie dies über ein Plugin in Ihre Jira-Instanz integrieren).

In Ihrem Fall müssen Sie entscheiden, ob Ihre Webanwendung ein Produkt ist oder ob die verschiedenen Microservices jeweils ein Produkt sind. Ich ziehe es vor, dass die kundenorientierte Einheit das Produkt ist, unabhängig von ihrer Architektur, aber ich sehe Vorteile für beide. Dies hängt mehr davon ab, wie Sie Revisionen des Systems verfolgen und steuern möchten. Ich persönlich bevorzuge die Versionierung des Systems als Ganzes, daher möchte ich das System jedes Mal aktualisieren, wenn sich ein Microservice ändert, und ich möchte Jira verwenden, um diese Systemebene zu verfolgen Versionen.

Mit dem Ein-Projekt-Ansatz können Sie separate Boards für jedes Team erstellen und dennoch das gesamte Product Backlog so nutzen, dass skalierte Frameworks wie LeSS und Nexus unterstützt und einige der integrierten Jira-Funktionen genutzt werden.

Ich würde alles im selben Projekt behalten, da Sie an einer einzigen Web-App arbeiten. Sie können mehrere Boards in Jira erstellen (eines für das Reach-Team) und die Arbeitsbelastung jedes Teams über diese Boards verwalten. Sprechen Sie mit Ihrem Jira-Administrator, um das Projekt zu entwerfen.

Die Produktarchitektur klingt nach Schichten (Front-End, Produkt-Microservices usw.). Klingt, als gäbe es mehrere Abhängigkeiten zwischen den Teams. Abgesehen vom Frontend (bei dem Sie vermutlich User Stories mit Akzeptanzkriterien verwenden) wie werden die Anforderungen an das Produkt Microservices gehandhabt?

Vielleicht könnten Sie darüber nachdenken, die Teams neu zu ordnen, damit sie Input/Fähigkeiten/Expertise aus allen Produktschichten haben. Unter Verwendung der Schichtkuchen-Analogie befasst sich jedes Team mit einem Stück des Kuchens, anstatt dass sich separate Teams mit jeder Schicht des Kuchens befassen. Das reduziert Abhängigkeiten zwischen den Teams. Stellen Sie einfach sicher, dass es eine Art architektonische Anleitung gibt, damit jedes Team die Ebenen auf die gleiche Weise handhabt. Jede Abweichung zwischen den Teams in der Herangehensweise an die Schichten kann als technische Schuld definiert und durch Refactoring in einer Reihe von Hardening-Sprints behandelt werden.

Erstellen Sie verschiedene Projekte

Vorteile:

• Probleme, die verschiedenen Teams zugewiesen sind, müssen nicht unterschieden werden. Allein die Tatsache, dass sie in einem bestimmten Projekt sind, sagt Ihnen, welches Team sich um sie kümmert
• Keine Probleme mit der in JIRA integrierten Scrum-Funktionalität, obwohl Sie möglicherweise einige Probleme mit Epics sehen (wenn Storys aus einem Epic von mehr als einem Team bearbeitet werden müssen).

Nachteile:

• Möglicherweise muss ein „Feeder“-Projekt vorhanden sein, das den Rückstand enthält, bevor er den Teams zugewiesen wird
• Möglicherweise müssen Sie Backlog-Elemente zwischen Projekten verschieben
• Es gibt keine einzelne, konsolidierte und priorisierte Ansicht des Rückstands

Ein Projekt

Vorteile:

• Eine Backlog-Ansicht (und Sie können Filter verwenden, um sie auf die Backlogs einzelner Teams einzugrenzen).
• Eine Priorisierung.
• Teamübergreifende Epics werden einfacher zu verwalten sein.

Nachteile:

• Sie werden eine Möglichkeit brauchen, um bei Problemen zwischen den Teams zu unterscheiden. Sie könnten beispielsweise ein benutzerdefiniertes Feld oder eine Bezeichnung verwenden.
• Sie müssen mehrere Boards erstellen, eines für jedes Team, und sie mithilfe von JQL-Filtern unterscheiden.
• Immer wenn Sie ein neues Problem hinzufügen, müssen Sie angeben, mit welchem ​​Team es verknüpft ist (indem Sie das benutzerdefinierte Feld festlegen oder eine entsprechende Bezeichnung hinzufügen).