JIRA: Epics vs Labels vs Components


83

Este blog tiene una definición de epopeyas en JIRA:

Las epopeyas son cuerpos de trabajo significativamente más grandes. Las épicas son trabajos a nivel de funciones que abarcan muchas historias de usuarios. Usando el ejemplo anterior, una epopeya podría ser la función de administración de cuenta completa y la capacidad de ver compras anteriores.

Entonces, si (como propietario de un producto) tengo una función grande que quiero que se entregue que comprenda muchas tareas más pequeñas y probablemente abarque sprints, entonces una épica es una buena opción.

Sin embargo, podría crear fácilmente un componente de "Administración de cuentas" (usando el ejemplo del blog), y cualquier tarea relacionada con esa función tiene ese componente asignado.

De manera similar, también podría usar fácilmente una etiqueta de "Account_Management", y cualquier historia / ticket que sea parte de la función Account Management simplemente se etiquetará con esa etiqueta.

Entonces mi pregunta: ¿por qué / en qué circunstancias usarías una epopeya? ¿Por qué / en qué circunstancias usaría un componente? ¿Por qué / en qué circunstancias usaría una etiqueta? Es decir, los tres (epopeyas, etiquetas, componentes) parecen tener propósitos muy similares (agrupar una colección de problemas), ¿cuál es la diferencia?

Respuestas:


64

Con etiquetas y componentes, si desea seleccionar un grupo de ellos, debe utilizar la búsqueda de problemas. Si está usando épicos, también puede usar la búsqueda de problemas, pero también obtiene la funcionalidad incorporada en JIRA Agile.

En la vista de la lista de trabajos pendientes de un tablero JIRA Agile, tiene una pestaña Épica. Esta pestaña le permite seleccionar los problemas asociados con las epopeyas individuales. Además, tiene una funcionalidad que simplifica la adición de nuevos temas a una épica. La ventaja final es que el nombre épico se muestra con colores brillantes junto a los problemas de la lista. Esto puede ser muy útil al ver el trabajo pendiente y tener una idea del trabajo que viene a continuación.

Puedes ver más sobre épicas en la página de Atlassian Working with Epics .

Los componentes son útiles para el equipo técnico, ya que pueden abarcar muchas epopeyas. Un componente típico podría ser 'base de datos' o 'UI'. JIRA ofrece la opción de asignar trabajo para un componente en particular a un usuario de JIRA en particular. Por ejemplo, todos los problemas creados con un componente de 'base de datos' podrían asignarse a Jill Smith.

Las etiquetas son mucho más adaptables y tienen la ventaja de permitir múltiples asignaciones (por lo que se puede asociar más de una etiqueta con un problema). Con las etiquetas, depende en gran medida de usted cómo las use.


5
Yo agregaría que las etiquetas son transversales. Puede etiquetar varios tipos de problemas en Jira con la misma etiqueta. De esta manera, puede crear una bandera personalizada como TODO, NECESITA ATENCIÓN, REQUIERE DOCUMENTACIÓN, etc. No crearía épicas o componentes para eso.
Benny Bottema

37

Las epopeyas, por definición, son problemas de corta duración en comparación con el proyecto en su conjunto. Los componentes y las etiquetas, por otro lado, son para siempre. Y debe seguir utilizándolos por su verdadero significado, por muy tentador que sea de otra manera.

Crea Epics para funciones , o como lo menciona @Sateesh, para historias más importantes. Deben resolver su propósito, y una vez que la necesidad comercial está terminada, deben cerrarse / terminarse .

Los componentes no son características . Son las partes técnicas del sistema. También se pueden utilizar para categorizar sus piezas o ... bueno, componentes: P ... de su producto.

Las etiquetas pueden ser cualquier cosa, como lo menciona @barnaby. Por lo general, son palabras clave, eslogan, palabras con las que la gente puede querer relacionarse con una tarea, etc. Lo uso principalmente para hacer que los problemas se puedan buscar mejor desde una perspectiva a largo plazo. Hay un complemento JIRA que le brinda una nube de etiquetas JIRA (para fines puramente elegantes, creo: D) que también podría interesarle.


"Los componentes no son características". - esa es una distinción interesante, ¿cuál es la diferencia? ¿Existe algún peligro en tener una asignación aproximada de 1: 1 de componente a función?
Adam Parkin

No existen peligros como tales. Simplemente ineficaz, terminará usándolos de una sola manera (como componente o característica) o mezclándolos, eso es todo. Pensé mucho en cómo explicar la diferencia exactamente, y espero que lo siguiente sea un buen ejemplo.
Krishnan

2
Tomaré una tarea de deuda técnica (grande) como ejemplo, porque en sí misma es un problema muy técnico , pero ayuda a ver mejor la brecha. Decir "Refactor Payment Module" es (se supone que es) una tarea gigantesca que abarca múltiples sprints. Por lo tanto, querrá crear esto como un Epic . Y, los componentes para este problema serían el Módulo de pago . Hmmm ... solo pensé en esto: en otras palabras, los Epics describen los objetivos más amplios a alcanzar, y una vez logrados, deberían morir , mientras que los Componentes simplemente denotan partes o áreas de aplicación, que tendrán significado para siempre.
Krishnan

No estoy seguro de que estas delimitaciones realmente resuelvan la cuestión en cuestión. Los componentes y las etiquetas no son para siempre: el diseño de un sistema puede cambiar de manera que un componente dado ya no exista. Una etiqueta puede volverse irrelevante por diversas razones. Cuando lo desglosas todo, una epopeya, una etiqueta y un componente son simplemente categorizaciones con restricciones variadas sobre lo que puedes hacer con ellos (aunque restricciones extrañas: ¿una historia no puede ser requerida por dos epopeyas? dos componentes?). No encuentro el diseño de Atlassian muy profético.
Eric

Parece que los componentes realmente permiten múltiples asignaciones, lo cual es bueno, por lo que la delimitación entre componentes y etiquetas se vuelve más útil ya que los componentes se controlan de forma centralizada mientras que las etiquetas son de forma libre.
Eric

25

Además: Atlasian ahora ha creado un nuevo artículo que explica esto desde su perspectiva.

https://www.atlassian.com/agile/delivery-vehicles

Mi opinión / uso.

Las etiquetas y los componentes son casi sencillos y ya están bien respondidos.

Ejemplos de componentes

  • Aplicación cliente de Android
  • API del servidor
  • Base de datos, etc.

Ejemplos de etiquetas .

  • Sectores de lógica empresarial (ex pedidos, facturas, usuarios, productos)
  • Mejora de la calidad del código
  • Refactor
  • Usabilidad
  • Solicitud / queja del usuario Generalmente, cualquier cosa que ayude a categorizar las cosas.

Pero déjame dar mi granito de arena sobre Epics porque encuentro esta frase demasiado genérica.

Las epopeyas son cuerpos de trabajo significativamente más grandes

Más grande? 10 Sprints? 10 historias? 20 historias? ¿o que?

Personalmente , clasificaría las épicas como metas .

En una retrospectiva anual / trimestral, su empresa se reúne con todos los miembros y partes interesadas, y concluye con lo siguiente

  1. Necesitamos apuntar a más plataformas (épico = Plataforma en expansión )
  2. Nuestro personal de soporte necesita más herramientas para manejar problemas. ( Enriquecer herramientas de soporte )
  3. ¡El software es demasiado difícil de usar! ( Rediseño de UI UX )

Esto significaría 3 epopeyas con un conjunto de historias para cubrir cada uno de esos requisitos genéricos.


En el contexto de la conversación aquí, hay otro término Iniciativas que podría ser sinónimo de Épicas . Las iniciativas de la OMI son más comprensibles, mientras que Epic, como podemos ver, es confuso. Sin embargo, siempre que su equipo (s) esté en la misma página que la definición, puede hacer lo que quiera, en general.
Max Cascone

4
Esta debería ser la respuesta. Tantas respuestas que veo aquí e Internet sin ejemplos. Este es el único con el ejemplo: la respuesta original es patética @BarnabyGolden
TheBlackBenzKid

6

Las epopeyas son historias más importantes que requieren más de un sprint para completarse. One Epic puede involucrar varias historias de usuarios. Cada historia de usuario puede pertenecer a uno o más componentes. Digamos que tiene una búsqueda épica de disponibilidad de aerolíneas. Esto puede tener múltiples historias de usuario como búsqueda OW, búsqueda RT, etc. Algunas o todas pueden involucrar componentes como caché, política de viajes y motor de reservas.

Las etiquetas son solo por conveniencia. Puede que no tenga un significado físico.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.