Organizar tareas con un backlog en GitHub Projects te permite visualizar el flujo de trabajo de un equipo DevOps desde la planeación hasta la entrega. Aquí descubrirás cómo crear un proyecto, vincularlo a un repositorio y mover issues entre estados como backlog, ready, in progress, review y done.

¿Qué es un backlog y cómo se traslada a GitHub Projects?

Un backlog es la lista priorizada de tareas pendientes que tu equipo ejecutará a lo largo de un proyecto. Después de planear con el método que prefieras, ya sea con Post-its físicos, virtuales o apps como To Do, el siguiente paso es llevar esa lista a GitHub para centralizar el trabajo junto al código.

¿Qué es un backlog? Es una lista priorizada de tareas pendientes que un equipo trabajará por etapas. Cada tarea avanza por estados hasta marcarse como completada.

La ventaja de usar GitHub Projects es que un mismo proyecto puede vincularse a varios repositorios. No es una relación uno a uno, y aunque al inicio cuesta acostumbrarse, después encuentras muchos beneficios al manejar trabajo distribuido en distintas bases de código.

¿Cómo se crea un proyecto con plantilla de desarrollo iterativo?

Dentro de tu repositorio entras a la pestaña Projects y eliges crear un nuevo proyecto. GitHub muestra varias plantillas, y aunque parezcan rígidas, todo se puede manipular después sin problema.

La plantilla recomendada para flujos DevOps es la de desarrollo iterativo, porque trae configurada la estructura de columnas que necesitas para trabajar por sprints. Al seleccionarla, le pones un nombre que te sirva como referencia, por ejemplo Curso DevOps, para identificar el proyecto asociado al repositorio.

¿Qué columnas trae la plantilla iterativa?

Esta plantilla genera por defecto cinco estados que reflejan el ciclo de vida de cada tarea:

• Backlog: tareas registradas pero no priorizadas para el sprint actual.
• Ready: tareas listas para iniciar.
• In progress: tareas en ejecución.
• Review: tareas en revisión por el equipo.
• Done: tareas completadas.

El objetivo como programador es tomar una tarea del backlog y no descansar hasta llevarla a done, pasando por todas las etapas intermedias.

¿Cómo se crea un issue dentro del proyecto y se asigna al sprint actual?

Desde la columna backlog agregas un nuevo ítem, por ejemplo método para agregar contactos. GitHub te ofrece tres opciones: crear un nuevo issue, crear un draft o agregar un ítem desde un repositorio existente. Para vincularlo directo al código, lo mejor es crear un nuevo issue.

Al crearlo seleccionas el repositorio donde quieres trabajar. Aquí aparece un detalle interesante: GitHub muestra todos los repositorios de la organización, lo que confirma que un mismo proyecto puede alimentarse desde múltiples fuentes. Si no tienes una plantilla configurada para issues, la opción en blanco funciona perfecto.

¿Por qué un issue nuevo no aparece en el tablero? Porque la vista tiene un filtro de iteración activo. El ítem existe, pero está oculto hasta que lo asignes al sprint actual o quites el filtro.

¿Cómo asignar el issue a la iteración actual?

Al abrir el issue recién creado, configura dos cosas clave para que aparezca en el tablero del sprint:

1. Asignación: asígnate la actividad a ti mismo para marcar responsabilidad.
2. Iteration: selecciona current para vincularlo a la iteración activa, que por defecto dura dos semanas, una duración ideal para trabajar con tu equipo.

Una vez aplicado el filtro Iteration: Current en la vista, solo verás las tareas del sprint en curso. Esto evita la distracción de mirar todo el backlog cuando solo importa lo que estás ejecutando ahora.

¿Cómo mover una tarea de backlog a ready?

Con el issue asignado y dentro de la iteración actual, puedes arrastrarlo de la columna backlog a ready. Ese movimiento indica que la tarea está priorizada y lista para que comience el trabajo técnico. A partir de ahí seguirá avanzando hacia in progress, review y finalmente done.

Este flujo refleja la lógica de los sprints dentro de metodologías ágiles: ciclos cortos de trabajo donde cada tarea atraviesa estados claros y medibles, lo que facilita la coordinación del equipo y la trazabilidad del avance.

Reto práctico para dominar el backlog en GitHub

Antes de avanzar, te recomiendo crear entre cuatro y cinco issues adicionales que correspondan a los Post-its que diseñaste para tu proyecto. No necesitas trabajar el mismo proyecto del curso: puedes practicar con una API del clima o una API de personajes de Marvel y DC.

Lo importante es que tu backlog refleje todas las tareas que imaginas para tu producto, las muevas por las columnas y experimentes el flujo completo. ¿Qué tipo de proyecto vas a usar para practicar? Cuéntalo en los comentarios.