Ley de brooks

Brooks' La ley es una observación sobre la gestión de proyectos de software según la cual agregar mano de obra a un proyecto de software que está atrasado lo retrasa aún más. Fue acuñado por Fred Brooks en su libro de 1975 The Mythical Man-Month. Según Brooks, bajo ciertas condiciones, una persona incremental cuando se agrega a un proyecto hace que tome más tiempo, no menos.

Explicaciones

Según el propio Brooks, la ley es una "simplificación exagerada", pero captura la regla general. Brooks señala los principales factores que explican por qué funciona de esta manera:

1. Se necesita algún tiempo para que la gente añada a un proyecto para llegar a ser productiva. Brooks lo llama la hora de "arreglar". Los proyectos de software son complejos esfuerzos de ingeniería, y los nuevos trabajadores en el proyecto deben primero ser educados sobre el trabajo que les ha precedido; esta educación requiere desviar recursos ya trabajando en el proyecto, disminuyendo temporalmente su productividad mientras que los nuevos trabajadores todavía no están contribuyendo significativamente. Cada nuevo trabajador también necesita integrarse con un equipo compuesto por varios ingenieros que deben educar al nuevo trabajador en su área de experiencia en la base de código, día a día. Además de reducir la contribución de los trabajadores experimentados (por la necesidad de formar), los nuevos trabajadores pueden incluso hacer contribuciones negativas, por ejemplo, si introducen errores que mueven el proyecto más lejos de completarse.
2. La comunicación aumenta a medida que aumenta el número de personas. Debido a la explosión combinatoria, el número de canales de comunicación aumenta rápidamente con el número de personas. Todo el mundo que trabaja en la misma tarea necesita mantenerse en sincronía, así como más personas se agregan pasan más tiempo tratando de averiguar lo que todos los demás están haciendo.
3. Añadiendo a más personas a una tarea muy divisible, como salas de limpieza en un hotel, disminuye la duración general de la tarea (hasta el punto en que los trabajadores adicionales se interponen entre sí). Sin embargo, otras tareas incluyendo muchas especialidades en proyectos de software son menos divisibles; Brooks señala esta divisibilidad limitada con otro ejemplo: mientras que toma una mujer nueve meses para hacer un bebé, "niñas mujeres pueden hacer un bebé en un mes".

Excepciones y posibles soluciones

Hay algunos puntos clave en la ley de Brooks que permiten excepciones y abren la puerta a posibles soluciones.

El primer punto es tener en cuenta que la ley de Brooks solo se aplica a los proyectos que ya están retrasados. Los proyectos se pueden volver a controlar (o mantener) si se agregan personas antes en el proceso. También es importante determinar si el proyecto está realmente retrasado o si el cronograma originalmente era demasiado optimista. Los errores de programación representan una gran cantidad de proyectos atrasados. Corregir el cronograma es la mejor manera de tener un marco de tiempo significativo y confiable para la finalización del proyecto.

También se debe tener en cuenta la cantidad, la calidad y el rol de las personas agregadas al proyecto. Una forma sencilla de eludir la ley en un proyecto de sobrecostos es agregar más personas de las necesarias, de tal manera que la capacidad adicional compense los gastos generales de capacitación y comunicación. Se pueden agregar buenos programadores o especialistas con menos gastos generales para la capacitación. Se pueden agregar personas para realizar otras tareas relacionadas con el proyecto, por ejemplo, control de calidad o documentación; dado que la tarea es clara, el tiempo de aceleración se minimiza.

Una buena segmentación ayuda a minimizar la sobrecarga de comunicación entre los miembros del equipo. Los subproblemas más pequeños son resueltos por un equipo más pequeño, y un equipo de alto nivel es responsable de la integración de sistemas. Para que este método funcione, la segmentación del problema debe realizarse correctamente en primer lugar; si se hace incorrectamente, esto puede empeorar el problema, no mejorarlo, al impedir la comunicación entre los programadores que trabajan en partes del problema que en realidad están estrechamente acopladas, incluso cuando el plan del proyecto ha decretado que no lo están.

Un ejemplo de segmentación son los patrones de diseño que simplifican la distribución del trabajo, porque todo el equipo puede hacer su parte dentro del marco proporcionado por ese patrón. El patrón de diseño define las reglas que siguen los programadores, simplifica la comunicación mediante el uso de un lenguaje estándar y proporciona consistencia y escalabilidad.

El plan Bermuda, donde la mayoría de los desarrolladores de un proyecto son eliminados ("enviados a las Bermudas") y los restantes quedan para completar el software, se ha sugerido como una forma de eludir la ley de Brooks.