Cuando el plazo está a punto de vencer y queda mucho trabajo pendiente, a cualquiera se le ocurre una idea parecida. Si se incorpora a más personas, ¿no se terminará antes? Hay casos en los que, sin duda, cuantas más manos ayudan, antes se acaba el trabajo, como al cargar los enseres de una mudanza o al arar un campo.
Sin embargo, en el desarrollo de software suele ocurrir lo contrario. Si se incorpora a más personas a un proyecto que ya va con retraso, el calendario se retrasa aún más. Esta regla empírica se conoce como «ley de Brooks (Brooks's Law)», por la persona que la formuló por primera vez.
Este artículo explica paso a paso cómo surgió la ley de Brooks, qué idea equivocada encierra la unidad llamada persona-mes, por qué incorporar a más personas no acelera el trabajo, cómo se calcula el aumento de las vías de comunicación y cuáles son los límites de la ley y las formas de evitar sus efectos.
Fundamentos y aplicación de la ley de Brooks
El origen de la ley y el espejismo de la persona-mes
Frederick P. Brooks Jr. fue un científico de la computación que, en la década de 1960, dirigió en IBM, en Estados Unidos, el desarrollo del ordenador central System/360 y de su sistema operativo OS/360. OS/360 fue uno de los proyectos de software más grandes de su época y, aunque participaron numerosos desarrolladores, el calendario siguió acumulando retrasos.
A partir de aquella experiencia, Brooks publicó en 1975 el libro «El mítico hombre-mes (The Mythical Man-Month)». En él escribió: «Añadir personal a un proyecto de software que va con retraso lo retrasa aún más (Adding manpower to a late software project makes it later)». Esta frase pasó a conocerse como la ley de Brooks.
La persona-mes (Man-Month) es una unidad que representa la cantidad de trabajo que realiza una persona en un mes. Así, se calcula que un trabajo de 10 personas-mes puede terminarlo una persona en diez meses o diez personas en un mes. Brooks señaló que este cálculo solo es válido cuando el trabajo puede repartirse en partes iguales sin que las personas tengan que comunicarse entre sí, y que la propia idea de que las personas y los meses son intercambiables es una ilusión.
Medio siglo después, este libro sigue considerándose un clásico de la ingeniería de software. La edición conmemorativa del aniversario número 20, publicada en 1995, incluyó también el ensayo «No hay bala de plata (No Silver Bullet)», en el que sostiene que no existe un método mágico que permita aumentar considerablemente la productividad de un solo golpe. Brooks recibió el Premio Turing (Turing Award) en 1999 por sus contribuciones a la arquitectura de computadores y a la ingeniería de software.
Por qué incorporar a más personas no acelera el trabajo
Cuando se incorpora a alguien a un proyecto que va con retraso, en un primer momento parece que hay más manos para trabajar. En la práctica, el calendario tiende a retrasarse aún más por los siguientes motivos.
(1) Aprender lleva tiempo
Quien se incorpora debe familiarizarse con la estructura del proyecto, las decisiones tomadas hasta entonces y la forma de trabajar antes de poder hacer su parte. Mientras tanto, quienes ya estaban en el equipo tienen que interrumpir sus tareas para enseñarle, de modo que el ritmo general disminuye durante las primeras semanas.
(2) Hay tareas que no se pueden dividir
Algunas tareas deben seguir un orden establecido por muchas personas que se incorporen. Brooks lo explicó así: «Tener un bebé lleva nueve meses. Da igual cuántas mujeres se asignen a la tarea».
(3) Aumenta el trabajo de hacer encajar las partes
Cuanto más se divide el trabajo, más esfuerzo se requiere para volver a unir las partes, comprobar que encajan y llegar a un entendimiento común. A medida que aumenta el número de personas, el tiempo que exige esta coordinación crece rápidamente.
Cuando coinciden estos tres factores, el calendario previsto se desbarata antes de que las nuevas incorporaciones empiecen a hacer su parte. Por eso, intentar compensar un retraso aumentando el número de personas suele provocar un retraso aún mayor.
Cómo se calcula el aumento de las vías de comunicación
El número de vías de comunicación es lo que mejor ilustra la ley de Brooks. Si todos los miembros del equipo tienen que comunicarse entre sí y n es el número de personas, habrá n(n-1)/2 vías de comunicación. Aunque el número de personas aumente de una en una, el número de vías crece mucho más rápido.
- En un equipo de 3 personas (Team of 3) hay 3 vías de comunicación.
- En un equipo de 5 personas (Team of 5), el número de vías de comunicación aumenta a 10.
- En un equipo de 10 personas (Team of 10) hay 45 vías de comunicación.
- En un equipo de 20 personas (Team of 20), el número de vías de comunicación llega a 190.
Si se duplica el número de personas, el número de vías casi se cuadruplica. Las reuniones, los mensajes y las comprobaciones aumentan en la misma medida, y queda menos tiempo para programar. Se llega a un punto en el que incorporar a más personas hace que disminuya la productividad del conjunto.
Cómo evitar los efectos de la ley y cuáles son sus límites
La ley de Brooks viene a decir que conviene decidir con cuidado cuándo y cómo ampliar el equipo, sin descartar por completo esa posibilidad. En la práctica, los equipos de desarrollo intentan evitar este problema de las siguientes maneras.
- Equipo pequeño (Small Team). Mantener un número reducido de integrantes por equipo limita las vías de comunicación. La regla de los «equipos de dos pizzas» de Amazon es un ejemplo conocido.
- Modularidad (Modularity). Dividir el trabajo en partes independientes y definir con claridad los acuerdos entre ellas reduce lo que los equipos necesitan comunicarse.
- Incorporación temprana (Early Staffing). Si hace falta personal, incorporarlo al comienzo del proyecto, antes de que el calendario se retrase, le da tiempo para familiarizarse con el trabajo.
- Ajuste del alcance (Scope Cut). Si el proyecto ya va con retraso, muchas veces es preferible reducir las funcionalidades o replantear el calendario antes que incorporar a más personas.
Esta ley también tiene límites. El propio Brooks reconoció más tarde que era una formulación demasiado simplificada. Si las tareas son fáciles de dividir, como las pruebas o la redacción de documentación, o si se incorpora alguien que ya conoce bien el proyecto, ampliar el equipo puede acelerar el trabajo. Hoy, los avances en las herramientas de colaboración y en la automatización han reducido el esfuerzo que exige la comunicación, por lo que la intensidad con que se manifiesta la ley depende del equipo y de la naturaleza del trabajo.
La ley de Brooks nos recuerda que el ritmo de trabajo depende de más factores que el número de personas. Antes de incorporar a más gente, examinar cómo se divide el trabajo y cómo se relacionan quienes lo realizan es el primer paso para cumplir el calendario de desarrollo.
