Seguimiento del Progreso y Métricas Ágiles

El seguimiento y control es la disciplina continua de medir el avance real del software frente a lo planificado, detectando desviaciones tempranas en el cronograma, el alcance o la calidad para aplicar medidas correctivas de inmediato.

En el desarrollo moderno de software, el seguimiento combina tableros visuales interactivos con métricas ágiles de flujo y entrega continua.

1. Métricas de Flujo en Software: Lead Time y Cycle Time #

Para medir la eficiencia del equipo desde que surge una necesidad hasta que está en manos del usuario, se utilizan dos métricas de tiempo cruciales:

1Petición del Cliente           Inicio del Desarrollo             Despliegue a Producción
2           │                                 │                                  │
3           ▼                                 ▼                                  ▼
4           ┌─────────────────────────────────┬──────────────────────────────────┐
5           │        Tiempo en Backlog        │       Tiempo de Desarrollo       │
6           └─────────────────────────────────┴──────────────────────────────────┘
7           ▲                                                                    ▲
8           └────────────────────────── LEAD TIME ───────────────────────────────┘
9                                             ▲                                  ▲
10                                             └────────── CYCLE TIME ────────────┘

• Lead Time (Tiempo de Entrega): Tiempo total transcurrido desde que una historia de usuario o bug se registra en el backlog hasta que se entrega en producción.
• Cycle Time (Tiempo de Ciclo): Tiempo transcurrido desde que un desarrollador empieza a trabajar activamente en la tarea (In Progress) hasta que se despliega.
• Throughput (Rendimiento): Número de historias o tareas completadas y entregadas por unidad de tiempo (ej. 12 tareas por semana).

2. Herramientas Visuales de Seguimiento #

1BURNDOWN CHART (Sprint Scrum):                      TABLERO KANBAN CON LÍMITES WIP:
2Puntos                                              ┌─────────────┬─────────────┬─────────────┐
3100│\                                               │ BACKLOG     │ IN PROGRESS │ DONE        │
4 80│ \   Línea Ideal                                │             │ (WIP: max 3)│             │
5 60│  \                                             ├─────────────┼─────────────┼─────────────┤
6 40│   \--- Real (con retraso)                      │ [Tarea 4]   │ [Tarea 1]   │ [Tarea A]   │
7 20│       \                                        │ [Tarea 5]   │ [Tarea 2]   │ [Tarea B]   │
8  0└────────\────── Día                             │             │ [Tarea 3]   │             │
9   0  2  4  6  8 10                                 └─────────────┴─────────────┴─────────────┘

Burn-down Chart frente a Burn-up Chart #

• Burn-down Chart: Gráfica que muestra el trabajo pendiente restante en el sprint día a día. Si la línea real está por encima de la línea ideal, el equipo va retrasado.
• Burn-up Chart: Gráfica que muestra el trabajo total acumulado completado hacia arriba junto a la línea de alcance total. Es ideal para detectar si un retraso se debe a baja velocidad o a que el cliente aumentó el alcance (Scope Creep).

Tablero Kanban y Límites WIP (Work In Progress) #

• Organiza las tareas en columnas: Backlog $\rightarrow$ Ready for Dev $\rightarrow$ In Progress $\rightarrow$ Code Review $\rightarrow$ QA Testing $\rightarrow$ Done.
• Límite WIP: Restringe el número máximo de tareas simultáneas que pueden estar en una columna (ej. In Progress (WIP: 3)).
• Principio Kanban: "Deja de empezar y empieza a terminar" (Stop starting, start finishing). Evita la multitarea ineficiente y reduce los cuellos de botella.

Diagrama de Flujo Acumulado (Cumulative Flow Diagram - CFD) #

Gráfica de áreas apiladas que muestra la cantidad de tareas en cada estado a lo largo del tiempo. Las bandas ensanchadas revelan de inmediato cuellos de botella (por ejemplo, muchas tareas atascadas en Code Review esperando aprobación).

3. Principales Herramientas Digitales de Gestión #

4. Caso Práctico: Detección de Cuellos de Botella #

Un equipo de 4 desarrolladores utiliza un tablero Kanban. Tras dos semanas, observan que la columna In Progress tiene 2 tareas, pero la columna Code Review tiene 11 Pull Requests pendientes de revisión desde hace 5 días.

1. ¿Qué problema de flujo está ocurriendo? Un cuello de botella en la fase de revisión de código (Code Review).
2. ¿Qué impacto tiene en el Cycle Time? Dispara el tiempo de ciclo, retrasando las entregas a producción a pesar de que los desarrolladores programan rápido.
3. ¿Qué acción correctiva debe tomar el equipo? Establecer un límite WIP estricto en Code Review (ej. máximo 2) y acordar que ningún desarrollador comience una tarea nueva sin haber revisado antes los PRs pendientes de sus compañeros.