¿Deberíamos crear un Epic para deudas tecnológicas?

Estaba teniendo una discusión en el equipo para crear una Epicpara todos technical-debtsen el proyecto. El problema es que, por definición, Epic no debería generar más de una cuarta parte, pero si creamos un Epic para la deuda técnica, puede ejecutarse durante la duración del proyecto. Navegué en Internet pero no pude encontrar nada. Por favor, ayuda con las pautas ágiles correctas.

Los consultores venden A gile; existe la filosofía ágil .
¿Qué estás tratando de hacer al convertir toda tu deuda tecnológica en una epopeya? ¿Es esto para seguimiento de tiempo, trazabilidad o...? Desde una perspectiva ágil, es probable que esto sea un antipatrón, pero desde la perspectiva de JIRA podría ser un caso comercial.

Respuestas (4)

Una epopeya es una gran historia . Uno que debe dividirse en historias que encajen cómodamente dentro de los sprints. Realmente no está destinado a ser utilizado como una forma de agrupar historias en una categoría.

Habiendo dicho eso, haz lo que sea mejor para tu equipo. Si encuentra que agrupar las tareas de deuda técnica en una epopeya lo ayuda a rastrearlas, entonces está bien.

Mi enfoque preferido en JIRA es usar una etiqueta de "deuda técnica" en historias/tareas relacionadas con el trabajo de deuda técnica. De esa manera, puede filtrar elementos de trabajo de deuda técnica de entrada/salida si es necesario.

No estoy seguro de por qué esta respuesta atrajo un voto negativo. Creo que el caso de uso de seguimiento es razonable, y usar etiquetas en lugar de épicas parece una buena solución centrada en JIRA en muchos casos.
+1 para etiquetas. Además, le permite ejecutar una consulta rápida para ver cuántas historias de deudas tecnológicas están apareciendo, lo que le brinda otro punto de datos en el equipo para apoyarlos. ¿Están siendo presionados? ¿Es codificación drive-by? ¿Se están apresurando a cerrar las entradas? ¿El código base se está volviendo difícil de manejar? etcétera etcétera

La directriz ágil correcta es que debe hacer lo que mejor funcione para usted y su equipo.

No hay nada correcto o incorrecto en el uso de Epic para etiquetar la deuda técnica en el proyecto. Pero tampoco hay ningún requisito de tener todas las historias asociadas con una epopeya.

Todavía no voté esta respuesta, pero: 1) creo que es más un comentario que una respuesta; y 2) hay compensaciones y mejores prácticas, por lo que agitar la mano tampoco responde la pregunta. Considere mejorar su respuesta antes de votarla.

Por lo tanto, tenemos que discutir la deuda técnica

Acumulas deuda técnica cuando haces un compromiso estratégico (para cumplir con una fecha o enviar algo), pero esto es algo a corto plazo , se supone que debes arreglarlo lo antes posible , posiblemente agregando una nueva historia en el próximo sprint (probablemente como parte de la epopeya original) para arreglarlo.

Si tiene una gran acumulación de elementos comprometidos en los que no se ha trabajado durante algún tiempo, esto no es una deuda técnica, es un diseño deficiente o malas prácticas de desarrollo .

Necesitas crear nuevas historias para corregirlas y priorizarlas. Es probable que necesite priorizar algo de tiempo/velocidad por sprint para lidiar con ellos (en lugar de un nuevo trabajo).

No los agregues a una epopeya, terminarán siendo despriorizados y nunca se terminarán. También puede recompensarse con velocidad por lidiar con cosas que deberían haber salido bien la primera vez.

Necesitas bloquear el tiempo para mostrar que entregar entregas comprometedoras como esta reduce la velocidad, por lo que debe evitarse.

La deuda tecnológica también podría ser un artefacto de un pivote de diseño o mejores prácticas en evolución, pero de lo contrario, +1, la deuda tecnológica debe pagarse en pequeñas cuotas frecuentes.
De acuerdo con el cuadrante de la deuda tecnológica, existen múltiples razones por las que podría aparecer la deuda tecnológica. Para obtener más matices, entonces te estás besando ... Una opinión respaldada y respaldada por Martin Fowler. Por ejemplo... la falta de conocimiento del desarrollador es una deuda técnica. martinfowler.com/bliki/TechnicalDebtQuadrant.html

Como ya se dijo, este no es un problema ágil, sino más bien una pregunta sobre cómo agrupar ciertos problemas en JIRA. He estado usando los sprints de JIRA para eso. No hay agrupación automática por etiqueta o épica en la cartera de pedidos, por lo que es difícil ver todos los problemas de "deuda técnica" en un solo lugar, a menos que los clasifique manualmente. Así que agrego esos problemas a un sprint de 'Deuda técnica', que no es un sprint per se, sino una forma de agruparlos.