Mejor práctica de usar componentes en proyectos de jira

Question

Estamos utilizando a Jira en gran medida en nuestro desarrollo diario. Me gustaría ver si hay algunas mejores prácticas para crear componentes de proyecto en Jira.

Por ejemplo, en su opinión, ¿es mejor crear un componente para cada módulo de desarrollo en Jira o quizás su equipo prefiera componentes de mayor precisión?

Answer 1

Combinaría los componentes con sus módulos/artefactos/jarrones, por lo que cada problema puede ser propiedad de un módulo particular (aunque puede tener dependencias/relaciones con otros también).

Si puede presentar argumentos sólidos para tener una administración de problemas más detallada que el nivel del módulo, considere por qué no separaría también el módulo asociado.

Tener esta asignación de 1-1 ayuda a aclarar su calendario de lanzamiento, puede fácilmente qué problemas tiene la versión X de su proyecto, y en qué módulos enfocar el esfuerzo. También ayuda a simplificar las asociaciones entre Jira, el sistema de compilación y el SCM, p. Si está utilizando Bamboo, es probable que tenga un proyecto de compilación por módulo, por lo que simplemente puede agregar la asociación.

Answer 2

Los componentes son como pequeños subproyectos. Los proyectos parecen ser más útiles cuando agrupan a las personas. Recomiendo a mis clientes que los proyectos de JIRA reflejen la organización social hasta cierto punto, al menos hasta que la cantidad de proyectos sea muy grande.

Además, evite el uso de un componente llamado "Misc" u "Otro". Tienden a convertirse en basureros de problemas que a nadie le importan.

Answer 3

Cree un componente para cada módulo principal, o tal vez incluso el nivel del sistema (por ejemplo, Backend, Frontend). No iría por debajo de la granularidad a nivel de módulo. Puede añadir componentes para las actividades de apoyo, como BA, Testing (coincidiendo con mdoar) ... componentes son ortogonales a las versiones/releases

Answer 4

Lo más importante acerca de los componentes es ser inequívoca y no demasiados. En nuestro equipo ahora, estamos migrando a la jerarquía de nivel 3 (en el sentido GreenHopper):

• en el nivel superior que tiene los componentes de BA, que son pocos y delineado por el equipo (infra, backend, GUI) - esto ayuda BA chicos enrutan la solicitud al gerente de equipo DEV correcto asignado como líder de componente.
• el segundo nivel es el proceso real (en el sentido Unix). Esta es una definición muy clara. En caso de que un problema se correlacione con múltiples procesos, se lo asignaremos a uno de ellos (BTW, GreenHopper no permite múltiples componentes de hojas, pero JIRA lo hace). Esto es hecho por el gerente de DEV.
• El tercer nivel es opcional y rara vez se utiliza, lo que denota el subsistema dentro del proceso. Lo usamos cuando una parte considerable de los problemas están relacionados con una parte bien definida del código y queremos rastrearlos por separado. Esto generalmente lo hace el desarrollador que trabaja en el problema.

Para que este refinamiento progresivo funcione, debe tener una idea de quién asigna qué componente y quién procesa los problemas que se le asignan. Este último se denota por Component Lead, el primero no es explícitamente compatible con JIRA (o podríamos decir que BA solo ve sus componentes, gestores de DEV, solo sus subcomponentes + todos BA, etc.)

Answer 5

Usamos una jerarquía de componentes de 2 niveles (gracias a greenhopper ...) - Temas y Epics. La construcción en Greenhopper Themes y Epics no nos permite agregar e informar de la manera que queremos, y esto funciona bastante bien.

Answer 6

A partir de 4.2.4, no es posible que los componentes de versión, sólo los proyectos. Tenga esto en cuenta si desea utilizar la función de mapa de carreteras.

Hay una (7 años) solicitud de larga data añadir las versiones de componentes:

http://jira.atlassian.com/browse/JRA-3501

Answer 7

Tengo otra toma en componentes ahora.
Con clientes me refiero al campo de componentes como:

A multiselect field that's useful for automatically assigning issues. Each of the things in this field has a potential assignee associated with it.

y entonces digo:

If you don't care about automatic assignment, just treat the components field as a convenient system field.

Así que para responder a la pregunta original de nuevo, se pregunta si asigna cuestiones de equipo o por el nivel fino al que se refiere?
Probablemente el primero.

Answer 8

JIRA diseñado para que cada componente del proyecto tenga el mismo conjunto de números de versión, por lo que si desea que los componentes tengan números de versión independientes, debe configurar un proyecto diferente para cada componente o usar un complemento desarrollado por mí que permite números de versión específicos del componente y al mismo tiempo permite la agrupación de componentes en un paquete. El complemento es "Component/Subcomponents/Bundle Versions for JIRA" y está disponible en Atlassian Marketplace. Más información está disponible en atlassian plugins help page. Otra opción es obligar a todos los componentes del equipo a tener el mismo conjunto de números de versión. De lo contrario, es muy difícil seleccionar los números de versión correctos para los componentes.