stringtranslate.com

Ley de Brooks

La ley de Brooks es una observación sobre la gestión de proyectos de software que dice que "Añadir mano de obra a un proyecto de software que se encuentra en una fase avanzada hace que éste se retrase". [1] [2] Fue acuñada por Fred Brooks en su libro de 1975 The Mythical Man-Month . Según Brooks, en determinadas condiciones, cuando se añade una persona adicional a un proyecto, este tarda más, no menos tiempo.

Explicaciones

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

  1. A las personas que se suman a un proyecto les lleva un tiempo volverse productivas . Brooks lo llama el tiempo de " inicio rápido ". Los proyectos de software son tareas de ingeniería complejas y los nuevos trabajadores del proyecto primero deben formarse sobre el trabajo que los ha precedido; esta formación requiere desviar recursos que ya están trabajando en el proyecto, lo que disminuye temporalmente su productividad mientras los nuevos trabajadores aún no están contribuyendo de manera significativa. Cada nuevo trabajador también necesita integrarse con un equipo compuesto por varios ingenieros que deben capacitar al nuevo trabajador en su área de especialización en la base de código, día a día. Además de reducir la contribución de los trabajadores experimentados (debido a la necesidad de capacitación), los nuevos trabajadores pueden incluso hacer contribuciones negativas, por ejemplo, si introducen errores que alejan el proyecto de su finalización.
  2. La sobrecarga de comunicación aumenta a medida que aumenta el número de personas. Debido a la explosión combinatoria , la cantidad de canales de comunicación diferentes 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.
  3. Añadir más personas a una tarea altamente divisible, como limpiar habitaciones en un hotel, disminuye la duración total de la tarea (hasta el punto en que los trabajadores adicionales se interponen entre sí). Sin embargo, otras tareas, incluidas muchas especialidades en proyectos de software, son menos divisibles; Brooks señala esta divisibilidad limitada con otro ejemplo: mientras que una mujer tarda nueve meses en 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 sólo se aplica a proyectos que ya están retrasados. [6] Los proyectos pueden volver a estar bajo control (o mantenerse bajo control) si se incorporan personas antes en el proceso. [7] También es importante determinar si el proyecto está realmente retrasado o si el cronograma originalmente era demasiado optimista. Los errores de programación son la causa de una gran cantidad de proyectos retrasados. Corregir el cronograma es la mejor manera de tener un marco temporal significativo y confiable para la finalización del proyecto. [8]

También se debe tener en cuenta la cantidad, la calidad y el papel de las personas que se incorporan al proyecto. Una forma sencilla de eludir la ley sobre un proyecto que excede los tiempos previstos es añadir más personas de las necesarias, de forma que la capacidad adicional compense los gastos de formación y comunicación. [9] Se pueden añadir buenos programadores o especialistas con menos gastos de formación. [10] Se pueden añadir personas para realizar otras tareas relacionadas con el proyecto, por ejemplo, control de calidad o documentación; dado que la tarea está clara, se minimiza el tiempo de puesta en marcha. [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, en lugar de mejorarlo, 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, ya que todo el equipo puede hacer su parte dentro del marco que proporciona 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 coherencia y escalabilidad.

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

Véase también

Notas

  1. ^ de Frederick P. Brooks, Jr. El mes mítico del hombre . 1995 [1975]. Addison-Wesley.
  2. ^ Maggie Fox NBC News, 21 de octubre de 2013, Better use the phone: Why Obamacare website is such a fail. Consultado el 21 de octubre de 2013. "Y enviar a demasiados de los 'mejores y más brillantes' tal vez tampoco sea la solución adecuada, señalan los expertos en software. A menudo citan la Ley de Brooks, que sostiene que agregar personas a un proyecto lo ralentiza".
  3. ^ James Taylor, "A Survival Guide for Project Managers", 2.ª edición, AMACOM [ aclaración necesaria ] , 2006, ISBN  978-0814408773 , pág. 21.
  4. ^ "A pesar de la ley de Brooks, agregar personas a un proyecto que se encuentra en una etapa avanzada sigue siendo algo común"... "Yo mismo he predicado muchas veces este viejo dicho de la ingeniería de software, pero ya no creo que sea cierto". (McConnell, 1999)
  5. ^ "El problema es que hay excepciones importantes que mucha gente no se toma el tiempo de considerar cuando utiliza la ley de Brooks para justificar algo". (Berkun, 2006)
  6. ^ "En esos proyectos está implícito que se aplica únicamente a las fases finales de un proyecto. La pregunta es: ¿cómo saber si se está en las fases finales de un proyecto?" (McConnell, 1999)
  7. ^ "Hemos descubierto que añadir personal a un proyecto que se retrasa siempre aumenta su coste, pero el proyecto no siempre se retrasa, ya que puede haber suficiente tiempo para absorberlos y el proyecto puede no tener la dotación máxima de personal. Sólo bajo cierto grado de restricciones secuenciales entre las tareas del proyecto el proyecto se retrasará." (Hsia, Hsu, Kung, 1999)
  8. ^ Los proyectos caóticos que se retrasan mucho más de lo que el director del proyecto piensa, no se completarán en tres semanas, sino en seis meses. No deje de contratar personal. Tendrá tiempo para que se vuelvan productivos. El proyecto seguirá atrasándose con respecto a su plan, pero eso no es resultado de la ley de Brooks, sino de haber subestimado el proyecto desde el principio. (McConnell, 1999)
  9. ^ "Gordon y Lamb estudiaron la ley de Brooks y sugirieron que la mejor manera de recuperarse de un retraso en el cronograma es incorporar más personal del que se espera que sea necesario, y hacerlo lo antes posible". (Hsia, Hsu, Kung, 1999)
  10. ^ "La ley supone que todo el trabajo añadido es igual, lo cual no es cierto. Si tuviera que elegir entre añadir un buen programador, que conozca el código base y sea amigo de la mitad del equipo, lo consideraría." (Berkun, 2006)
  11. ^ "El enfoque triste pero popular es incluir a la gente sin demasiadas explicaciones y dejar que cada uno resuelva el problema por sí solo. Pero si el gerente aclara por qué se incorporan Sally y Rupert y define los roles adecuados para ellos, con el aporte del equipo, estarán preparados para hacer una transición sin problemas". (Berkun, 2006)
  12. ^ Shea, Tom (7 de mayo de 1984). "Los desarrolladores revelan 'vaporware'". InfoWorld . 6 (19). InfoWorld Media Group: 48. ISSN  0199-6649 . Consultado el 13 de abril de 2010 .
  13. ^ Bruno, Eric J. (6 de febrero de 2023). "Corchetes n.° 9: ¿Fred Brooks se equivocó con respecto a los proyectos de software tardíos?". Revista Java . Oracle Corporation.

Referencias