La Ley de Brooks es un principio utilizado en el desarrollo de software que afirma que "añadir más efectivos a un proyecto de software en retraso, lo retrasará más". Fue acuñado por Fred Brooks en su trabajo de 1975 The Mythical Man-Month. El corolario de la ley de Brooks es que cuando se incorpora una persona en un proyecto, este se ralentiza en lugar de acelerarse. Brooks también afirmó que "Nueve mujeres no pueden tener un bebé en un mes".
Según el propio libro de Brooks, la ley es una "frívola sobresimplificación", pero se hace eco de la idea. Brooks destaca dos factores principales que explican el porqué de la ley:
La ley de Brooks se cita a menudo para justificar que los proyectos no se terminan a tiempo, a pesar de los esfuerzos gestores. Sin embargo, hay algunos puntos clave de la ley de Brooks que permiten excepciones y abren la puerta a posibles soluciones.
El primer punto es que la ley de Brooks se suele aplicar a proyectos que tienen retraso. Se puede volver a controlar (o mantener bajo control) si se refuerza el equipo en fases previas. También es importante determinar si un proyecto se encuentra realmente en retraso o si las estimaciones iniciales fueron demasiado optimistas, algo frecuente. Corregir la planificación es la mejor manera de disponer de una ventana de tiempo fiable y útil para finalizar el proyecto.
La cantidad, calidad y papel de la gente que se incorpora al proyecto son factores a tener en cuenta. Una vía simple de evitar la ley en un proyecto en retraso es añadir más gente de la necesaria, de forma que la capacidad extra compensa el overhead en comunicación y formación. Los buenos programadores o especialistas se pueden incorporar con menos necesidad de tiempo para su formación. También se puede incorporar personal para realizar otras tareas relacionadas con el proyecto, por ejemplo documentación o garantía de calidad en caso de que la tarea esté disponible, así se disminuye el tiempo de la rampa de subida.
Una buena labor de gestión y desarrollo también ayuda a reducir el impacto de la ley de Brooks. Las prácticas modernas de integración continua, desarrollo guiado por pruebas, y desarrollo iterativo reducen significativamente el overhead de comunicación entre los desarrolladores, permitiendo mejor escalabilidad. También nuevas herramientas para el desarrollo de software y su documentación son de ayuda a minimizar el tiempo de rampa de subida, haciendo más sencilla la incorporación al proyecto. Los patrones de diseño simplifican la distribución del trabajo, dado que el equipo completo puede realizar el trabajo dentro del patrón que se le asignó. Los patrones de diseño definen las reglas que han de seguir los programadores, simplifica la comunicación por medio del uso de un lenguaje estándar y proporciona consistencia y escalabilidad. Finalmente, una buena segmentación ayuda minimizando el overhead entre los miembros del proyecto. Los problemas menores se resuelven en equipos pequeños y un equipo superior es responsable de la integración del sistema. Para poder trabajar así es necesario segmentar el problema de forma correcta; en caso contrario, puede empeorar el problema, impidiendo la comunicación entre los programadores que trabajan en diferentes partes del problema que están directamente relacionados, aunque el plan del proyecto afirme que no los están.
Algunos autores -véase, por ejemplo, Creating a Software Engineering Culture de Karl E. Wiegers – han recalcado la importancia de los aspectos sociales y políticos del clima de trabajo como determinantes de la efectividad de los programadores individuales y del equipo del proyecto como un todo. En lugar de depender de "héroes" para llevar a cabo la tarea con esfuerzos extraordinarios, Wiegers afirma que un equipo de individuales de cualidades ordinarias pueden proveer resultados a tiempo de forma periódica con el ambiente de trabajo correcto. Los esfuerzos para mejorar la efectividad de los equipos puede mitigar sino eliminar, las consecuencias de la ley de Brooks.
En comparación con el desarrollo de software tradicional, los proyectos de código abierto tienen una metodología diferente (véase La catedral y el bazar). Los proyectos de código abierto de gran escala tienen un vasto número de participantes que se encargan de programar y garantizar la calidad, utilizando canales de comunicación de bajo coste (como el correo electrónico) para comunicarse. Este tipo de proyectos se escalan bien, a pesar de la Ley de Brooks, debido a varias razones:
Algunas de estas razones, tales como el trabajo en paralelo, podrían aplicarse teóricamente a ambos, los proyectos abiertos y los cerrados.
Escribe un comentario o lo que quieras sobre Ley de Brooks (directo, no tienes que registrarte)
Comentarios
(de más nuevos a más antiguos)