Guía en profundidad
Simulador del cuello de botella entre QA y sprints: cuando los desarrolladores superan la capacidad de pruebas
Análisis ejecutivo del sector
Un equipo de software es un flujo de trabajo, y un flujo de trabajo no puede publicar más deprisa que su etapa más lenta. Cuando los desarrolladores terminan más funcionalidades de las que los probadores pueden verificar, el trabajo sobrante no desaparece; se incorpora a una cola. Los responsables ven desarrolladores ocupados y un tablero de sprint lleno, y concluyen que el equipo es productivo. Pero una funcionalidad construida y no probada no ha generado nada, y cada semana que espera pierde valor. Añadir desarrolladores en esa situación eleva a la vez la nómina y la longitud de la cola, y deja la producción publicada exactamente donde estaba.
La estructura del problema es la diferencia entre dos ritmos. La producción de los desarrolladores es el número de desarrolladores por las funcionalidades que termina cada uno. La capacidad de QA es el número de probadores por las funcionalidades que puede verificar cada uno. Las funcionalidades publicadas son el menor de los dos valores, y la diferencia entre ellos es el ritmo al que crece la cola. Como la cola se acumula mes tras mes, su coste no permanece constante; se va acumulando. Un equipo que está algo por encima de su capacidad parece estar bien en el primer sprint y claramente roto en el sexto, razón por la que el problema es fácil de ignorar hasta que ya es grande.
El efecto dominó muestra la secuencia. Una producción alta de los desarrolladores eleva la parte de la capacidad de QA demandada por encima del cien por cien. Esa carga hace crecer la cola, lo que retrasa cada funcionalidad que hay detrás. La espera cuesta valor directamente, y además hace que los desarrolladores vuelvan a trabajos antiguos por correcciones y consultas, de modo que su tiempo se pierde en cambios de contexto. Los probadores sobrecargados van con prisa y se escapan más defectos. Cada etapa alimenta la siguiente, de modo que una pequeña sobrecarga en la segunda casilla puede poner en rojo la última en pocos sprints.
El iceberg separa la nómina del coste del cuello de botella. Sobre la línea de flotación están los sueldos de desarrollo y de QA, que ve cualquiera. Bajo ella hay cuatro costes que rara vez tienen una partida: el valor perdido mientras las funcionalidades esperan, el coste de los errores que llegan a los clientes porque las pruebas se hicieron con prisa, el tiempo de desarrollo perdido en cambios de contexto y las horas extra que trabajan los probadores bajo sobrecarga. Juntos pueden superar el coste del probador adicional que los habría eliminado. Utilice el simulador para encontrar la proporción entre desarrolladores y QA a partir de la cual su flujo de trabajo deja de compensar y compárela con la incorporación de un probador.
Esquema de fórmulas y metodología
El modelo trabaja mes a mes en régimen estable. La producción de los desarrolladores es el número de desarrolladores por las funcionalidades de cada uno. La capacidad de QA es el número de probadores por las funcionalidades de cada uno. Las funcionalidades publicadas son el menor de los dos valores. La cola crece cada mes en la diferencia, y la cola media en una ventana de seis meses es la mitad de seis veces ese crecimiento. El coste del retraso es la cola media por el coste del retraso. Los desarrolladores pierden un 1 % de su tiempo en cambios de contexto por cada funcionalidad en cola, con un tope del 20 %. Los defectos que se escapan aumentan con la sobrecarga.
- Producción de los desarrolladores
- P = desarrolladores × funcionalidades por desarrollador
- Funcionalidades terminadas y entregadas a QA cada mes.
- Funcionalidades publicadas
- S = mín(P, probadores × funcionalidades por probador)
- El flujo de trabajo solo puede publicar lo que las pruebas verifican.
- Cola
- Q = máx(0, P − capacidad) × 3
- Número medio de funcionalidades en espera durante una ventana de seis meses, ya que la cola crece de forma lineal.
- Coste de los errores que se escapan
- E = S × (3 % + 15 % × sobrecarga) × 4.000
- Los defectos que llegan a los clientes aumentan cuando QA está sobrecargado, a un coste de 4.000 cada uno.
- Resultado del flujo de trabajo
- Neto = S × valor − nómina − Q × coste del retraso − E − coste de contexto − horas extra de QA
- Resultado mensual. La carga de equilibrio es aquella en la que esto llega a cero.
Elasticidad en cascada
La diferencia entre la producción de los desarrolladores y la capacidad de QA es el factor más elástico, porque determina a la vez la cola, el retraso, los cambios de contexto y los errores que se escapan. El valor por funcionalidad escala directamente la producción publicada. La nómina es lineal y actúa como umbral, razón por la cual añadir un probador suele amortizarse muchas veces su coste.
Tres casos prácticos reales
Inicio con recursos propios
Un equipo de producto de tres personas
Tres desarrolladores y un probador trabajan en un producto pequeño. Los desarrolladores terminan seis funcionalidades al mes y el probador puede verificar siete, así que nada se queda en cola. Cárguelo para ver un equipo pequeño equilibrado en el que publicar es igual a construir y no hay ningún cuello de botella que corregir.
Mediana empresa en crecimiento
Una organización equilibrada de veinticuatro desarrolladores
Una organización grande mantiene siete probadores para veinticuatro desarrolladores e invierte en automatización, de modo que QA supera ligeramente la producción de los desarrolladores. Las colas son mínimas y el valor publicado es alto. Cárguelo para ver por qué una proporción saludable mantiene rentable a un equipo grande.
Crisis de cisne negro
Diez desarrolladores y dos probadores sobrecargados
Diez desarrolladores rápidos terminan treinta funcionalidades al mes, pero dos probadores solo pueden verificar diez. La cola crece veinte funcionalidades al mes, se escapan errores y los desarrolladores vuelven una y otra vez a código antiguo. Cárguelo para ver cómo un problema de proporción convierte una nómina grande en una pérdida.
Matriz de referencias del sector
| Métrica | Zona de peligro | Promedio del sector | Élite (10 % superior) |
|---|---|---|---|
| Desarrolladores por probador | Más de 8:1 | 3–5:1 | Alrededor de 2–3:1 con automatización |
| Carga de QA (producción de los desarrolladores frente a la capacidad) | Más del 130 % | 90–105 % | Menos del 90 % |
| Cola media a la espera de pruebas | Más de 10 funcionalidades | 2–4 funcionalidades | Menos de 2 |
| Defectos que se escapan a producción por lanzamiento | Más del 10 % | 3–6 % | Menos del 2 % |
| Plazo desde que se termina hasta que se publica | Más de 4 semanas | 1–2 semanas | Menos de 3 días |
Variables y palancas
Desarrolladores
Ingenieros que construyen funcionalidades. Más desarrolladores elevan la producción, pero no la velocidad de las pruebas.
Palanca: No añada desarrolladores antes de que crezca la capacidad de pruebas; limite el trabajo en curso para que el equipo termine menos pero publique más.
Funcionalidades terminadas por desarrollador y mes
Funcionalidades que un desarrollador completa y entrega a QA en un mes.
Palanca: Limite las funcionalidades iniciadas por sprint a lo que QA pueda verificar, porque el trabajo terminado pero sin probar no genera nada.
Probadores de QA
Personas que verifican las funcionalidades antes del lanzamiento.
Palanca: Incorpore probadores o integre ingenieros de pruebas en el equipo, porque cada probador libera un bloque de funcionalidades que hoy esperan.
Funcionalidades verificadas por probador y mes
Cuántas funcionalidades puede probar, volver a probar y dar por válidas un probador en un mes.
Palanca: Automatice las pruebas de regresión y redacte los criterios de aceptación desde el principio, para que los probadores verifiquen trabajo nuevo en lugar de repetir comprobaciones antiguas.
Valor de una funcionalidad publicada
Ingresos, retención o ahorros que aporta una funcionalidad cuando llega a los usuarios.
Palanca: Priorice las funcionalidades por valor y descarte las de poco valor, ya que la capacidad de pruebas se gasta en lo que entre en la cola.
Coste del retraso por funcionalidad y mes
Lo que pierde cada funcionalidad por cada mes que espera en la cola, en ingresos perdidos o confianza del cliente.
Palanca: Publique incrementos más pequeños con más frecuencia, lo que acorta la espera de cada funcionalidad y reduce el coste del retraso.
Cómo usar este simulador
- 1Introduzca el número de desarrolladores y las funcionalidades que termina cada uno en un mes.
- 2Fije el número de probadores y cuántas funcionalidades puede verificar cada uno.
- 3Estime el valor de una funcionalidad publicada y el coste del retraso por funcionalidad y mes.
- 4Lea las cinco fichas del dominó y anote cuándo la carga de QA supera el cien por cien.
- 5Compare con el plan del probador adicional en la pestaña Universo paralelo y comparta el enlace.
Errores que conviene evitar
- Medir a los desarrolladores por las funcionalidades terminadas. El trabajo que espera a ser probado es inventario, no producción.
- Promediar durante un periodo largo. Una cola que crece cada mes parece pequeña al principio y grande después.
- Tratar a los probadores como un coste que recortar. En un cuello de botella, la capacidad de un probador es la capacidad más valiosa del flujo de trabajo.
- Contar solo el coste del retraso. Los errores que se escapan y los cambios de contexto suelen superarlo.
Preguntas frecuentes
¿Por qué añadir desarrolladores no aumenta la producción publicada?
Porque la publicación está limitada por la etapa más lenta. Los desarrolladores adicionales engrosan la cola delante de QA, lo que eleva el coste sin aumentar el ritmo de lanzamiento.
¿Basta con la proporción entre desarrolladores y probadores para planificar?
Es un comienzo, pero la comparación útil es la producción frente a la capacidad. La automatización, la calidad de los requisitos y el tipo de producto pueden cambiar mucho la proporción.
¿Cómo se estima el coste del retraso?
Como una pérdida mensual por funcionalidad en espera, en ingresos, retención o confianza perdidos. Es un supuesto, así que pruebe una cifra baja y otra alta y vea cuál predomina.
¿Por qué aumentan los defectos con la sobrecarga?
Los probadores con prisa se saltan casos y revisan menos. El modelo añade errores que se escapan en proporción a cuánto supera la demanda a la capacidad.
¿Qué muestra el escenario del probador adicional?
Muestra el beneficio de un probador más y de una regresión automatizada, que eleva la capacidad de QA y suele despejar la cola. La pestaña de 24 meses muestra cuándo se amortiza.
¿Qué grado de precisión tiene?
Es un modelo educativo de planificación con los supuestos mostrados, no asesoramiento de ingeniería ni financiero. Sustituya los datos por sus propias cifras de rendimiento y de costes.
Este es un modelo educativo de planificación con supuestos declarados. No constituye asesoramiento financiero, fiscal ni jurídico. Sustituya los datos por sus propias cifras y consulte las decisiones importantes con un profesional cualificado.