Cuellos de botella en la entrega de software con lead time y cycle time

En resumen

El lead time es cuánto tarda una solicitud desde que se pide hasta que se entrega. El cycle time es cuánto tarda desde que alguien empieza a trabajar en ella. Una gran diferencia entre los dos significa que el trabajo está esperando, no avanzando. Mide ambos por etapa, confirma el patrón con el equipo, cambia una sola cosa y vuelve a medir.

Cuatro números que describen el flujo

Métrica	Qué mide
Lead time	Desde la solicitud hasta la entrega, incluida toda la espera
Cycle time	Desde que empieza el trabajo hasta la entrega
Trabajo en curso (WIP)	Cuántos elementos están abiertos al mismo tiempo
Throughput	Cuántos elementos se terminan por semana o por sprint

Están conectados. La ley de Little dice que, en promedio, el cycle time es igual al trabajo en curso dividido por el throughput. En la práctica: si un equipo empieza más trabajo del que termina, todo tarda más, aunque todos estén ocupados. Reducir el trabajo en curso suele ser la forma más rápida de acelerar la entrega.

Un quinto número, la eficiencia de flujo, es la parte del cycle time en la que alguien está trabajando activamente en un elemento. En muchos equipos es sorprendentemente baja, porque la mayor parte del tiempo se va en esperar una revisión, pruebas, una decisión u otro equipo.

Los cinco pasos

Mide ambos tiempos en cada historia. Divide el cycle time en las etapas de tu flujo de trabajo, como en progreso, en revisión, en pruebas y esperando despliegue.
Encuentra la desviación. Busca la etapa donde el tiempo crece más respecto a lo normal.
Confirma que es un patrón. Compara a lo largo del sprint o de la versión. Una historia lenta es ruido; la misma etapa volviéndose lenta en cada sprint es un cuello de botella.
Habla con los ingenieros involucrados. Los datos muestran dónde; las personas explican por qué. Las causas comunes son dependencias de otros equipos, requisitos poco claros y revisiones de código lentas.
Cambia una sola cosa y vuelve a medir. Ajusta prioridades, el flujo de trabajo o el proceso de revisión, y luego revisa si los números se mueven.

Causas comunes y soluciones

Dónde crece el tiempo	Causa probable	Qué suele ayudar
Antes de empezar	Requisitos poco claros	Refinar las historias con producto antes del sprint, con criterios de aceptación claros
En progreso	Esperando a otro equipo	Hacer visibles las dependencias en la planeación y acordar temprano los contratos de las APIs
En progreso	Demasiado trabajo en curso	Poner límites de WIP y terminar antes de empezar algo nuevo
En revisión	Las revisiones se acumulan	Pull requests más pequeños, tiempos de revisión acordados y una primera revisión asistida por IA
En pruebas	Pruebas manuales	Pruebas automatizadas en CI, con asistentes de IA que ayuden a escribirlas

Dónde ayuda la IA, y el nuevo cuello de botella que crea

Las herramientas de IA ayudan en los dos extremos del proceso:

Análisis. Exporta el historial de tickets de Jira o los datos de pull requests de GitHub, y un asistente de IA puede calcular el tiempo por etapa, detectar valores atípicos y sugerir patrones en minutos. Trata sus hallazgos como hipótesis por verificar, no como conclusiones.
Soluciones. Los asistentes de programación con IA ayudan a escribir las pruebas que faltan, y las herramientas de revisión con IA pueden hacer una primera pasada sobre los pull requests, para que los revisores humanos se concentren en el diseño y el riesgo.

Pero cuando un equipo adopta asistentes de programación con IA, escribir código se vuelve más rápido, y llega más código a revisión y a pruebas al mismo tiempo. El cuello de botella se mueve hacia adelante. Si el cycle time no mejora después de adoptar IA, mira primero las etapas de revisión y pruebas. La solución suele ser pull requests más pequeños, expectativas de revisión claras y mejores pruebas automatizadas, no generar más código.

Dónde se movió el cuello de botella en mi equipo

En Cedar Planters tenemos un equipo pequeño y con mucha experiencia. Seguimos trabajando con Scrum, y ahora usamos IA en todo el proceso: Claude, Visual Studio Code y modelos de código abierto. Uno de los cambios más útiles fue en el propio Jira. Usamos IA para llevar a las tareas de Jira los detalles que estaban repartidos entre correos e hilos de Slack, así cada historia tiene todo su contexto y no solo un título de una línea.

Cuándo	Dónde esperaba más el trabajo
Antes de la IA	Aclarando requisitos, y en pruebas
Después de la IA	Revisando pull requests que se habían vuelto mucho más grandes

Con tareas más completas hubo menos idas y vueltas antes de empezar, y los asistentes hicieron más rápido escribir código. Pero los pull requests crecieron, y los revisores tenían que revisarlo todo de una vez. Ese paso no lo saltamos: mantener a una persona en el proceso es lo que hace seguro publicar código escrito con IA. Así que el tiempo se movió del inicio del proceso a la revisión.

Lo notamos por las quejas en las reuniones diarias y en las retrospectivas, un recordatorio de que el equipo suele sentir un cuello de botella antes de que lo muestre un tablero. Seguimos trabajando en ello, ajustando nuestras prácticas ágiles y nuestras herramientas de IA, con el objetivo de unir todo en un solo flujo de trabajo. Si ves el mismo patrón, la fila de revisión en la tabla de arriba es por donde yo empezaría.

Por qué validar con las personas

Los números sin contexto llevan a la solución equivocada. Una etapa de revisión larga puede significar que los revisores están sobrecargados, o que los pull requests son demasiado grandes para revisar, y cada caso necesita un cambio distinto. Preguntar primero mantiene la solución enfocada y conserva la confianza del equipo.

Mira el conjunto completo de métricas que sigo: Cómo mido la salud de un equipo de ingeniería.

Erwin MonguiDirector de Tecnología en Cedar Planters e ingeniero certificado en Inteligencia Artificial, en Toronto.