stringtranslate.com

ley de brooks

La ley de Brooks es una observación sobre la gestión de proyectos de software de que "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 éste lleve más tiempo, no menos.

Explicaciones

Según el propio Brooks, la ley es una "simplificación excesiva y escandalosa", [1] 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 las personas agregadas a un proyecto se vuelvan productivas . Brooks llama a esto el tiempo de " intensificación ". Los proyectos de software son tareas de ingeniería complejas y los nuevos trabajadores del proyecto primero deben informarse sobre el trabajo que los precedió; 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 contribuyen de manera significativa. Cada nuevo trabajador también necesita 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 capacitarlos), 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.
  2. Los gastos 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 descubrir qué están haciendo los demás.
  3. Agregar más personas a una tarea altamente divisible, como limpiar habitaciones en un hotel, reduce la duración total de la tarea (hasta el punto en que los trabajadores adicionales se interponen entre 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 sólo se aplica a proyectos que ya están retrasados. [6] Los proyectos pueden recuperarse (o mantenerse) bajo control si se agregan personas en una etapa más temprana del proceso. [7] También es importante determinar si el proyecto realmente está retrasado o si el cronograma era originalmente demasiado optimista. Los errores de programación representan 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 función de las personas agregadas al proyecto. Una forma sencilla de eludir la ley en un proyecto desbordado 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 generales 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, se minimiza el tiempo de preparación. [11]

Una buena segmentación ayuda a minimizar los gastos generales de comunicación entre los miembros del equipo. Los subproblemas más pequeños los resuelve un equipo más pequeño y un equipo de alto nivel es responsable de la integración de los 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 haya 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 coherencia y escalabilidad.

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

Ver también

Notas

  1. ^ ab Frederick P. Brooks, Jr. El mes del hombre mítico . 1995 [1975]. Addison-Wesley.
  2. ^ Maggie Fox NBC News, 21 de octubre de 2013, Utilice mejor 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' podría tampoco ser 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".
  3. ^ James Taylor, "Una guía de supervivencia para directores de proyectos", segunda edición, AMACOM [ se necesita aclaración ] , 2006, ISBN  978-0814408773 , p. 21.
  4. ^ "A pesar de la ley de Brooks, agregar personas a un proyecto tardío sigue siendo algo común" ... "Yo mismo he evangelizado muchas veces este trillado problema de la ingeniería de software, pero ya no creo que sea cierto". (McConnell, 1999)
  5. ^ "El problema es que existen excepciones importantes que muchas personas no se toman el tiempo de considerar cuando utilizan la ley de Brooks para justificar algo". (Berkun, 2006)
  6. ^ "En esos proyectos está implícito que se aplica sólo a las fases finales de un proyecto. La pregunta es: ¿Cómo sabes si estás en las fases finales de un proyecto?" (McConnell, 1999)
  7. ^ "Hemos descubierto que agregar personas a un proyecto tardío siempre aumentará su costo, pero es posible que el proyecto no siempre se retrase, ya que puede haber suficiente cronograma para absorberlos y es posible que el proyecto no tenga la dotación máxima de personal. Solo bajo cierto grado de restricciones secuenciales entre las tareas del proyecto harán que el proyecto se retrase". (Hsia, Hsu, Kung, 1999)
  8. ^ 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ás 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)
  9. ^ "Gordon y Lamb estudiaron la ley de Brooks y sugirieron que la mejor manera de recuperarse de un cronograma descendente es agregar más personas de las que se esperaría que fueran necesarias y agregarlas temprano". (Hsia, Hsu, Kung, 1999)
  10. ^ "La ley supone que toda la mano de obra agregada es igual, lo cual no es cierto. Si tuviera 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)
  11. ^ "El enfoque triste pero popular es incluir a las personas sin muchas explicaciones y dejar que todos lo resuelvan por sí mismos. Pero si el gerente aclara por qué se unen Sally y Rupert y define buenos roles para ellos, con el aporte del equipo, ellos Estaremos preparados para hacer una transición sin problemas". (Berkun, 2006)
  12. ^ Shea, Tom (7 de mayo de 1984). "Los desarrolladores presentan 'Vaporware'". InfoMundo . 6 (19). Grupo de medios InfoWorld: 48. ISSN  0199-6649 . Consultado el 13 de abril de 2010 .
  13. ^ Bruno, Eric J. (6 de febrero de 2023). "Llaves rizadas n.° 9: ¿Se equivocó Fred Brooks acerca de los proyectos de software tardíos?". Revista Java . Corporación Oráculo.

Referencias