← Últimos artículos
💻 computer science

A Capacity-Aware Parr Model for Agile Projects

Este artículo propone una refactorización consciente de la capacidad del modelo clásico de Parr que integra la demanda de esfuerzo latente normalizada con trayectorias de capacidad observadas o planificadas para pronosticar el progreso de proyectos ágiles, el tiempo de finalización y los déficits de recursos sin asumir una dotación de personal sin restricciones.

Autores originales: Pedro E. Colla

Publicado 2026-07-03
📖 4 min de lectura☕ Lectura para el café

Autores originales: Pedro E. Colla

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que estás planificando un largo viaje por carretera. Tienes un mapa que muestra exactamente cuánto combustible deberías quemar en cada etapa del trayecto para llegar a tiempo. Esto es lo que hacen los modelos de software tradicionales: dibujan una curva que dice: "Para terminar este proyecto, necesitas un equipo enorme en la mitad, menos personas al principio y menos al final".

Pero aquí está el problema en el mundo real (especialmente en los equipos de software "Agile"): No puedes contratar a quien quieras, cuando quieras. Tu empresa tiene un equipo fijo de cinco personas. Tal vez solo pueden trabajar 40 horas a la semana. El mapa tradicional dice: "¡Necesitas 20 personas el próximo mes!", pero tu jefe dice: "No, solo tienes cinco".

Este artículo propone una nueva forma de mirar ese mapa. En lugar de tratar la curva como una regla estricta para la contratación, la trata como un hambre oculta de trabajo.

La idea central: El "Hambre" frente a la "Nevera"

El autor, Pedro Colla, sugiere separar dos cosas:

  1. El Hambre (Demanda Latente): Esta es la "Curva Parr". Representa cuánto trabajo quiere realizar el proyecto de forma natural en cualquier momento dado. Es como un estómago que tiene mucha hambre en la mitad del día y menos hambre por la mañana y por la tarde.
  2. La Nevera (Capacidad): Esto es lo que realmente tienes disponible. Tal vez solo tienes un sándwich (5 personas) cuando el estómago quiere un filete (20 personas).

La forma antigua: Los modelos antiguos asumían que si la curva decía que necesitabas un filete, debías conseguir un filete, o el proyecto fallaría. Intentaban forzar el tamaño del equipo para que coincidiera con la curva.

La forma nueva (Este artículo): El nuevo modelo dice: "Está bien, el proyecto tiene hambre de un filete, pero solo tenemos un sándwich. Comeremos el sándwich. Haremos todo lo que el sándwich nos permita, pero no fingiremos que nos comimos el filete".

Cómo funciona en lenguaje sencillo

El modelo utiliza una fórmula matemática simple para rastrear este "hambre". Hace tres preguntas:

  1. ¿Qué tan grande es la comida completa? (Esfuerzo total necesario).
  2. ¿Cómo es la curva de hambre? (¿Cuándo suele estar más ocupado el proyecto?).
  3. ¿Qué hay en la nevera hoy? (¿Cuántas personas hay realmente disponibles esta semana?).

El modelo luego calcula:

  • Progreso: ¿Qué parte de la comida comimos realmente esta semana?
  • La Brecha: ¿Tuvimos un "déficit de capacidad" (teníamos hambre pero no había comida)?
  • El Excedente (Slack): ¿Tuvimos comida extra en la nevera que no necesitamos comer?

La analogía del "Pronóstico Móvil"

Imagina que estás conduciendo y revisas tu GPS.

  • GPS antiguo: "Debes conducir a 100 mph para llegar a las 5 PM". (Ignora el tráfico o los límites de velocidad).
  • Este modelo: "Quieres conducir a 100 mph para llegar a las 5 PM, pero el límite de velocidad es 60. Así que llegarás más tarde. Recalculemos tu hora de llegada basándonos en el límite de 60 mph".

El artículo pone a prueba esta idea utilizando datos de un proyecto de software real (un equipo de 5 a 8 personas trabajando durante 22 semanas). Dividieron los datos a la mitad:

  1. Calibración: Utilizaron la primera mitad del viaje para ajustar la "curva de hambre" para que se ajustara a ese equipo específico.
  2. Predicción: Utilizaron la segunda mitad para ver si el modelo podía predecir el futuro basándose solo en el tamaño real del equipo, sin mirar los resultados finales.

Lo que encontraron (y lo que no encontraron)

El artículo es muy honesto sobre lo que logró:

  • Funciona internamente: El modelo rastreó con éxito el progreso del equipo e identificó cuándo estaban "pasando hambre" (falta de personas) o tenían "sobras" (capacidad extra).
  • Es simple: No intenta explicar por qué el equipo es lento (como mala comunicación o errores/bugs). Simplemente mide la brecha entre lo que el proyecto necesita y lo que el equipo puede hacer.
  • No es una bola de cristal mágica: Los autores admiten que solo probaron esto en un proyecto. No pueden decir que funcionará para todas las empresas del mundo todavía. Necesitan probarlo en muchos más proyectos para demostrar que es una regla universal.

La conclusión

Este artículo no inventa una nueva forma de construir software. En su lugar, inventa un mejor tablero de control (dashboard) para los gestores.

Deja de decirles a los gestores: "¡Debes contratar a 20 personas!" y comienza a decirles: "El proyecto tiene hambre de 20 personas, pero solo tienes 5. Aquí está exactamente qué tan lento irá el proyecto y aquí está exactamente cuándo terminarás si mantienes el tamaño del equipo en 5".

Convierte una curva matemática rígida en una herramienta flexible que respeta la realidad de los recursos limitados.

¿Ahogado en artículos de tu campo?

Recibe resúmenes diarios de los artículos más novedosos que coincidan con tus palabras clave de investigación — con resúmenes técnicos, en tu idioma.

Probar Digest →