La diferencia de Jira Epics y Components

Cuando se acerque a JIRA, es mejor recordar que la herramienta comenzó inicialmente como un sistema de seguimiento de errores.

Componentes

Un componente es un componente de software/hardware que se puede compartir entre equipos, departamentos o en toda la empresa.

Al etiquetar sus historias con un componente, todo permite que las unidades formales de gestión de lanzamientos vean exactamente qué componentes van a un UKDT (Ticket de implementación) o un Registro de lanzamiento si los está utilizando.

Ejemplos

• SecureSphere
• MongoDB
• Bóveda de Hashicorp
• WordPress
• Cromo 54.X
• Objetos de negocio
• oráculo x

Beneficios de una buena administración de componentes

Al etiquetar sus historias de usuario con componentes, también puede admitir informes detallados de Jira

project = YOURPROJECT AND status = Blocked AND component = "Active Directory"

Este informe le indicará qué historias de Active Directory están bloqueadas en su proyecto, pero teóricamente podría expandir esta consulta de búsqueda a múltiples componentes o múltiples proyectos para obtener informes realmente perspicaces de Portafolio/Sistema/Programa para apoyar a las partes interesadas, decisiones comerciales o incluso detectar impedimentos.

También puede desglosar las versiones de su producto por versión (1.0, 1.1, 2.8, etc.) por componente para ver qué hay en cada versión.

Como ScrumMaster, puede configurar un filtro para mostrar los componentes por cesionario y ver si los mismos desarrolladores se agrupan en torno a los mismos componentes. Ese mapa de calor luego forma la base de la capacitación cruzada del equipo. ¿Es muy fácil decírselo al Product Owner y/o al equipo?

Paul siempre está trabajando en las historias de Terraform. De 19 historias, ha hecho 18 de ellas. Me gustaría sugerirle al equipo una sesión de capacitación cruzada, pero la entrega puede verse afectada a corto plazo, ya que perdemos 1/2 día. ¿Puede gestionar a sus partes interesadas mientras hacemos esto?

epopeyas

Las épicas son probablemente uno de los términos más ambiguos de la comunidad Agile. En mi experiencia, muy pocos equipos usan Temas, por lo que todo lo que es más grande que una historia de usuario simplemente se incluye bajo el título Épico.

La guía oficial de Jira es

Una epopeya captura una gran cantidad de trabajo. Es esencialmente una gran historia de usuario que se puede dividir en varias historias más pequeñas. Puede tomar varios sprints para completar una epopeya. Una epopeya puede abarcar más de un proyecto, si se incluyen varios proyectos en el tablero al que pertenece la epopeya.

Mike Cohn también dice lo siguiente

Una epopeya de Scrum es una gran historia de usuario. No hay un umbral mágico en el que llamemos épica a una historia en particular. Simplemente significa "gran historia de usuario". Entonces, "épica" es solo una etiqueta que aplicamos a una gran historia. Llamar a una historia épica a veces puede transmitir un significado adicional. Suponga que me pregunta si tuve tiempo ayer para escribir las historias de los usuarios sobre la parte de informes mensuales del sistema. “Sí”, respondo, “pero en su mayoría son épicas”. Eso te dice que si bien los escribí, no tuve la oportunidad de dividir la mayoría de ellos en historias que probablemente sean lo suficientemente pequeñas como para implementarlas directamente.

Ejemplos de epopeyas

• Entregar la API de pagos para todos los métodos de pago aceptados
• Cree un firewall de aplicaciones web
• Desarrollar el nuevo sandbox
• Capacidad antimalware
• Instalar y configurar el IDS

Beneficios de una buena administración épica

Si bien es importante comenzar a entregar software que funcione lo antes posible, es igualmente importante planificar su producto de manera efectiva.

Las epopeyas son el primer bloque de construcción para producir hojas de ruta coherentes y creíbles. Al poner el andamiaje de Epic en Jira primero, puede construir su backlog de Jira de una manera lógica y demostrar a las partes interesadas qué Epics son el enfoque para las próximas 4 a 12 semanas y qué paquetes de funcionalidad se entregarán más adelante en la hoja de ruta.

También se beneficia de la precisión de los informes articulados anteriormente. Si una parte interesada pregunta

¿Cuándo estará listo el Firewall de aplicaciones web?

Puede decir rápidamente que estimamos que el WAF está en algún lugar en la región de 25 historias de usuarios, de las cuales 6 están completas. Si considera que el WAF es la prioridad más alta, potencialmente podemos entregarlo en X cantidad de Sprints/semanas según nuestras estimaciones/planificación de capacidad.

Además, si se suscribe al tamaño promedio de la historia de usuario para la estimación (como lo hago yo), puede decirle rápidamente a la gente cuánto tiempo llevará cada épica (dentro de lo razonable) una vez que la mayoría de las historias de usuario estén completas.

Por último; si usted es un ScrumMaster o BA, entonces revisar los Epics con regularidad le dará a su Product Owner una buena orientación sobre qué áreas se ven menos definidas y necesitan un trabajo significativo para poblar con historias.

Desde mi punto de vista, los componentes pueden abarcar muchas epopeyas. Los componentes típicos pueden ser 'DatabaseManager' (que puede contener múltiples epics) o 'GUI Layer'. Las epopeyas son trabajos a nivel de funciones que abarcan muchas historias de usuarios.

Re: componentes y epopeyas, creo que esta será una muy buena lectura para ti.

La conclusión más importante allí, y creo que la mayor distinción entre Componentes y Epopeyas, es que los Componentes son atemporales y categóricos, mientras que las Epopeyas son cuerpos de trabajo limitados en el tiempo.