La ley de Brooks 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 tardío lo hace más tarde". [1] [2] 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 lleve más tiempo, no menos.
Explicaciones
Según el propio Brooks, la ley es una "simplificación excesiva escandalosa", [1] pero captura la regla general. Brooks señala los principales factores que explican por qué funciona de esta manera:
- Se necesita algo de tiempo para que las personas agregadas a un proyecto se vuelvan productivas . Brooks llama a esto el tiempo de " aceleración ". Los proyectos de software son esfuerzos de ingeniería complejos , y los nuevos trabajadores del proyecto deben primero informarse sobre el trabajo que les ha precedido; esta educación requiere desviar recursos que ya están trabajando en el proyecto, disminuyendo temporalmente su productividad mientras los nuevos trabajadores aún no están contribuyendo de manera significativa. Cada nuevo trabajador también debe integrarse con un equipo compuesto por varios ingenieros que deben educar al nuevo trabajador en su área de especialización en el código base, día a día. Además de reducir la contribución de los trabajadores experimentados (debido a la necesidad de capacitarse), los nuevos trabajadores pueden incluso hacer contribuciones negativas, por ejemplo, si introducen errores que hacen que el proyecto esté más lejos de su finalización.
- Los gastos generales de comunicación aumentan a medida que aumenta el número de personas. Debido a la explosión combinatoria , el número de diferentes canales de comunicación aumenta rápidamente con el número de personas. [3] Todos los que trabajan en la misma tarea deben mantenerse sincronizados, por lo que a medida que se agregan más personas, pasan más tiempo tratando de averiguar qué están haciendo los demás.
- Agregar más personas a una tarea altamente divisible, como limpiar habitaciones en un hotel, disminuye la duración general de la tarea (hasta el punto en que los trabajadores adicionales se interponen en el camino de los demás). Sin embargo, otras tareas que incluyen muchas especialidades en proyectos de software son menos divisibles; Brooks señala esta divisibilidad limitada con otro ejemplo: mientras que a una mujer le toma nueve meses tener un bebé, "nueve mujeres no pueden tener 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. [4] [5]
El primer punto es señalar que la ley de Brooks solo se aplica a proyectos que ya están retrasados. [6] Los proyectos se pueden volver a poner (o mantener) bajo control si se agregan personas antes en el proceso. [7] También es importante determinar si el proyecto está realmente retrasado o si el cronograma fue originalmente demasiado optimista. Los errores de programación explican una gran cantidad de proyectos retrasados. Corregir el cronograma es la mejor manera de tener un marco de tiempo significativo y confiable para la finalización del proyecto. [8]
También se debe tener en cuenta la cantidad, calidad y rol de las personas agregadas al proyecto. Una forma sencilla de eludir la ley en un proyecto sobrepasado 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. [9] Se pueden agregar buenos programadores o especialistas con menos gastos de capacitación. [10] 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. [11]
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 mejorar, al impedir la comunicación entre los programadores que trabajan en partes del problema que en realidad están estrechamente relacionadas, 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 Bermuda") y los restantes se dejan para completar el software, se ha sugerido como una forma de eludir la ley de Brooks. [12]
Ver también
Notas
- ^ a b Frederick P. Brooks, Jr. El mes del hombre mítico . 1995 [1975]. Addison-Wesley.
- ^ Maggie Fox NBC News, 21 de octubre de 2013, mejor use el teléfono: por qué el sitio web de Obamacare es un fracaso . Consultado el 21 de octubre de 2013. "Y enviar demasiados de los" mejores y más brillantes "puede que tampoco sea la solución correcta, señalan los expertos en software. A menudo citan la Ley de Brooks, que sostiene que agregar personas a un proyecto lo ralentiza ".
- ^ James Taylor, "Una guía de supervivencia para directores de proyectos", 2ª edición, AMACOM [ aclaración necesaria ] , 2006, ISBN 978-0814408773 , p. 21.
- ^ "A pesar de la ley de Brooks, agregar personas a un proyecto tardío sigue siendo un lugar común" ... "Yo mismo he evangelizado muchas veces esta vieja y gastada ingeniería de software, pero ya no creo que sea cierto". (McConnell, 1999)
- ^ "El problema es que hay excepciones importantes que muchas personas no se toman el tiempo de considerar cuando utilizan la ley de Brooks para justificar algo". (Berkun, 2006)
- ^ "Implícito en esos proyectos es que se aplica solo a las fases finales de un proyecto. La pregunta es, ¿cómo saber si estás en las fases finales de un proyecto?" (McConnell, 1999)
- ^ "Hemos descubierto que agregar personas a un proyecto tardío siempre aumentará su costo, pero es posible que el proyecto no siempre llegue tarde, ya que puede haber un cronograma suficientepara absorberlos y el proyecto puede no tener el máximo de personal. Solo bajo cierto grado de restricciones secuenciales entre las tareas del proyecto se retrasará el proyecto ". (Hsia, Hsu, Kung, 1999)
- ^ Es probable que los proyectos caóticos tardíos lleguen mucho más tarde de lo que piensa el director del proyecto: la finalización del proyecto no está a tres semanas, sino a seis meses. Continúe y agregue personal. Tendrá tiempo para que se vuelvan productivos. Su proyecto seguirá siendo posterior a su plan, pero eso no es el resultado de la ley de Brooks. Es el resultado de subestimar el proyecto en primer lugar ". (McConnell, 1999)
- ^ "Gordon y Lamb estudiaron la ley de Brooks y sugirieron que la mejor manera de recuperarse de un horario irregular es agregar más personas de las que cabría esperar que fueran necesarias, y agregarlas pronto". (Hsia, Hsu, Kung, 1999)
- ^ "La ley asume que toda la mano de obra agregada es igual, lo cual no es cierto. Dada la opción de agregar un buen programador, que conozca el código base y sea amigo de la mitad del equipo, lo consideraría". (Berkun, 2006)
- ^ "El enfoque triste pero popular es incluir a la gente sin mucha explicación y dejar que todos lo resuelvan por sí mismos. Pero si el gerente aclara por qué Sally y Rupert se están uniendo, y define buenos roles para ellos, con el aporte del equipo, se configurará para hacer una transición sin problemas ". (Berkun, 2006)
- ^ Shea, Tom (7 de mayo de 1984). "Los desarrolladores revelan 'Vaporware ' " . InfoWorld . InfoWorld Media Group. 6 (19): 48. ISSN 0199-6649 . Consultado el 13 de abril de 2010 .
Referencias
- Steve McConnell. "Ley de Brooks derogada", IEEE Software, vol. 16, no. 6, págs. 6-8, noviembre / diciembre de 1999. También disponible en el sitio web de los autores ( ¿se derogó la ley de Brooks? ).
- Pei Hsia, Chih-tung Hsu, David C. Kung. "Revisión de la ley de Brooks: un enfoque de dinámica de sistemas", compsac, p. 370, Vigésimo Tercera Conferencia Anual Internacional de Aplicaciones y Software de Computación, 1999.
- RL Gordon y JC Lamb. "Una mirada cercana a la ley de Brooks", Datamation, junio de 977, págs. 81-86.
- Berkun, Scott (11 de enero de 2006). "Excepciones a la ley de Brooks" . Consultado el 28 de julio de 2008 .
- La ley de Brooks es aplicable a muchas actividades colaborativas de personas