Estaba teniendo una discusión en el equipo para crear una Epic
para todos technical-debts
en 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.
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.
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.
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.
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.
alan larimer
Todd A. Jacobs