Proyecto único de Jira para múltiples equipos Scrum

I've found that Jira projects best equate to products. This enables better use of the functionality around Releases, Components, and test case management (if you integrate that with your Jira instance through a plugin).

In your case, you need to decide if your web application is a product or if the different microservices are each a product. I prefer to have the customer-facing entity be the product, regardless of its architecture, but I can see advantages to both. This depends more on how you want to track and control revisions to the system - I personally favor versioning the system as a whole, so I would want to uprev the system every time any microservice changed and would want to use Jira to track those system level versions.

Con el enfoque de un solo proyecto, puede crear tableros separados para cada equipo y aprovechar la cartera de productos general de una manera que admita marcos escalables como LeSS y Nexus y aproveche algunas de las funciones integradas de Jira.

Mantendría todo en el mismo proyecto ya que está trabajando en una sola aplicación web. Puede crear varios tableros en Jira (uno para el equipo de alcance) y administrar la carga de trabajo de cada equipo a través de estos tableros. Habla con tu administrador de Jira para diseñar el proyecto.

La arquitectura del producto suena como si estuviera en capas (front-end, microservicios del producto, etc.). Parece que hay múltiples dependencias entre los equipos. Además del Front-end (para el que supongo que está utilizando historias de usuario con criterios de aceptación), ¿cómo se manejan los requisitos para los microservicios del producto?

Tal vez podría pensar en reorganizar los equipos para que tengan aportes/habilidades/experiencia de todas las capas de productos. Usando la analogía del pastel en capas, en lugar de tener equipos separados que se ocupen de cada capa del pastel, cada equipo se ocupa de una porción del pastel. Eso reduce las dependencias entre equipos. Solo asegúrese de que haya algún tipo de guía arquitectónica para que cada equipo maneje las capas de la misma manera. Cualquier divergencia entre los equipos en la forma en que abordan las capas puede definirse como deuda técnica y tratarse mediante la refactorización en una serie de sprints de endurecimiento.

Crear diferentes proyectos

ventajas:

• No es necesario diferenciar los problemas asignados a diferentes equipos. Solo el hecho de que estén en un proyecto determinado te dice qué equipo está tratando con ellos.
• No hay problemas con la funcionalidad Scrum incorporada de JIRA, aunque es posible que vea algunos problemas con las épicas (si las historias de una épica deben ser trabajadas por más de un equipo).

Desventajas:

• Es posible que deba haber un proyecto 'alimentador' que contenga el trabajo pendiente antes de que se asigne a los equipos.
• Es posible que deba mover elementos de la cartera de pedidos entre proyectos
• No existe una vista única, consolidada y priorizada del backlog

un proyecto

ventajas:

• Una vista de trabajos pendientes (y puede usar filtros para reducirla a los trabajos pendientes de cada equipo).
• Una priorización.
• Las epopeyas entre equipos serán más fáciles de administrar.

Desventajas:

• Necesitará alguna forma de diferenciar entre los equipos sobre los problemas. Por ejemplo, podría usar un campo personalizado o una etiqueta.
• Necesitarás crear varios tableros, uno para cada equipo y diferenciarlos usando filtros JQL.
• Cada vez que agregue un nuevo problema, deberá indicar a qué equipo está asociado (estableciendo el campo personalizado o agregando una etiqueta apropiada).