¿Por qué agregar más personas a un proyecto tardío lo hace más tarde?

25

Es un adagio bastante común que agregar más programadores a un proyecto tardío empeorará las cosas. ¿Por qué es esto?

project-management

— Enrique
fuente

14

El término para esto es la Ley de Brooks ( en.wikipedia.org/wiki/Brooks's_law ).

— Macneil

77

Consejo: lea "El mes mítico del hombre" de Brooks. Esto mostrará de dónde viene ese adagio, es un libro muy legible, y todos en el campo deberían leerlo de todos modos.

— David Thornley

Esa página de Wikipedia está muy bien escrita.

— Henry

Para obtener evidencia de cómo la productividad disminuye con el tamaño del equipo (más de 7 miembros del equipo obtiene rendimientos decrecientes), consulte qsm.com/process_improvement_01.html

— Joeri Sebrechts

33

Introducción gastos generales

Cada nuevo desarrollador tiene que ser presentado a la base del código y al proceso de desarrollo, lo que toma no solo el tiempo de la nueva persona sino que también requiere asistencia de [un] desarrollador (s) senior (guiándolos a través del proceso de construcción, explicar el proceso de prueba, ayudarlos con dificultades en la base de código, mucho más detallada las revisiones de código, etc) .

Por lo tanto, cuantos más nuevos desarrolladores agregue al proyecto, más tiempo tendrá que dedicar para llevarlos a un punto en el que realmente puedan contribuir al proyecto.

— Baelnorn
fuente

Entonces, si optimiza 'Introducción', ¿se reducirá el impacto?

— Henry

99

@Henry: el problema es que generalmente no puedes optimizar ese aspecto en un grado en el que no es el cuello de botella. Un nuevo programador al principio sabe exactamente 0 sobre su proyecto, su código y sus procesos. Es la misma sobrecarga que siempre se requiere al agregar un nuevo miembro del equipo. Pero cuando un proyecto ya se está retrasando, el equipo a menudo no tiene el tiempo para hacer una presentación adecuada, y si lo hace, ese tiempo falta en el desarrollo real. Por lo tanto, generalmente es una situación de perder para el equipo y la nueva persona tarda mucho más hasta que pueda contribuir de manera significativa al proyecto.

— Baelnorn

Con respecto al costo de hacer una introducción, ¿no se puede grabar en video una vez y luego transmitir a muchos, para que pueda capacitar a un gran número de nuevos programadores a la vez? (Ejemplos: reuniones o conferencias de desarrolladores).

— rwong

77

@rwong: No es una mala idea, pero esto generalmente no es práctico. No puede simplemente presentar la información, debe asegurarse de que los nuevos muchachos la entiendan. Además, si son realmente nuevos (graduados recientes), generalmente hay demasiada información para presentarlos a todos a la vez. Hemos descubierto que un wiki funciona bien, ya que toda la información está en un solo lugar, y las personas pueden publicar preguntas si hay partes que no entienden.

— TMN

Una posibilidad es asignar una nueva persona muy competente y hacer que realicen tareas específicas sin molestar a los demás. Se tambalearán mal y trabajarán lentamente, y algunos gerentes y / o equipos no pueden soportar ver esto. Sin embargo, el nuevo desarrollador puede ser una ventaja neta cuando se gestiona de esa manera.

— David Thornley

32

Además de las otras respuestas: Otro factor a considerar es la comunicación.

El peor caso para la cantidad de canales de comunicación en un equipo (que no es raro), es un gráfico completo . Como puede imaginar, agregar solo 1 desarrollador puede aumentar mucho los canales de comunicación. Con métodos de comunicación más simplificados, el impacto es menor ... pero aún suma.

— Steven Evers
fuente

¡Estaba escribiendo lo mismo casi al mismo tiempo! pero no sabía que tenía un nombre (un gráfico completo) y su explicación es mejor, así que ahí va mi voto.

— Miguel Veloso

+1. De acuerdo, este es el mayor problema al agregar más miembros del equipo.

— Martin Wickman

+1 para el problema a más largo plazo al agregar personas a un proyecto.

— indyK1ng

23

El problema citado en el libro que originalmente promulgó esta ley, The Mythical Man-Month , es la comunicación. Comienza diciendo:

Los hombres y los meses son productos intercambiables solo cuando una tarea puede dividirse entre muchos trabajadores sin comunicación entre ellos. Esto es cierto para cosechar trigo o recoger algodón; ni siquiera es aproximadamente cierto en la programación de sistemas.

Él menciona la capacitación como parte del problema:

La carga adicional de la comunicación se compone de dos partes: capacitación e intercomunicación. Cada trabajador debe estar capacitado en la tecnología, los objetivos del esfuerzo, la estrategia general y el plan de trabajo. Esta capacitación no se puede dividir, por lo que esta parte del trabajo varía linealmente con el número de trabajadores.

... pero señala que la intercomunicación es con mucho el factor más importante:

Dado que la construcción de software es inherentemente un esfuerzo de sistemas, un ejercicio de interrelaciones complejas, el esfuerzo de comunicación es excelente, y domina rápidamente la disminución del tiempo de tarea individual provocado por la partición. Agregar más hombres alarga, no acorta, el horario.

También vale la pena señalar que Fred Brooks (el autor) tiene los antecedentes para saber de qué está hablando. La mayor parte del libro se basa en su experiencia en la gestión del proyecto OS / 360 de IBM. A pesar de décadas de adherentes que predican todo tipo de métodos de gestión "mejorados", y algunos incluso inventan nombres geniales (eXtreme, Agile, Scrum, etc.) cuando se llega a ello, poco de la esencia ¹ parece haber cambiado desde entonces.

¹ Para la definición de "esencia", vea el mismo autor "No Silver Bullet: Essence and Accident in Software Engineering", incluido en la edición del ^vigésimo aniversario de The Mythical Man-Month .

— Jerry Coffin
fuente

12

No es simplemente un adagio; Es verificable. Echa un vistazo al mes-hombre mítico de Brooks .

— John
fuente

1

Es un adagio. Puede o no ser verificable, pero eso no impide que sea un adagio.

— Peter Boughton

3

No tengo este libro (obviamente). ¿Está respaldado por números duros o es anecdótico?

— Henry

2

@Henry: Ha pasado un tiempo desde que lo leí, pero IIRC, ambos están presentes en cantidad suficiente para hacer el punto de manera concluyente.

— Steven Evers

@ Peter: Edité mi respuesta.

— John

@PeterBoughton Es un adagio. Además, no es simplemente un adagio.

— SantiBailors

6

Aquí hay algunas ideas sobre este tema ...

Necesita utilizar los recursos actuales para actualizar los nuevos recursos sobre lo que está sucediendo con el proyecto.
Es posible que el nuevo recurso no esté familiarizado con la base del código, por lo que se requirió más tiempo para aclimatarse al código.

ahora, agregar nuevos recursos para la prueba podría no ser una mala idea ... podría acelerar el proceso de prueba (si sus casos de prueba están bien escritos), y sí, usar herramientas de prueba también ayudará.

— aggietech
fuente

1

+1 por agregar recursos a las pruebas, no al desarrollo.

— Baelnorn

4

Porque la programación no es un trabajo básico de línea de producción. Ponerse al día en un proyecto de software lleva tiempo. Las personas nuevas necesitan hacer muchas preguntas que conducen a una productividad negativa (es decir, aprendizaje de personas nuevas, personas mayores que les enseñan -> no se realiza ningún trabajo real).

Para simplificarlo, imagine un proyecto unipersonal relativamente simple que está programado para una semana: el jueves, se da cuenta de que no se realizará a tiempo, que en lugar de eso tomaría más de 6 a 7 días. de 5. Si agrega otro programador en ese punto, necesitarán trabajar con el programador1 durante al menos unas horas o un día más o menos, hacer muchas preguntas para ponerse al día, etc. Probablemente no obtendrá cualquier productividad positiva neta para el resto de la semana. Es probable que el nuevo programador también introduzca algunos errores adicionales (ya que no conocerán el código existente tan bien como el programador1), por lo que eliminará la implementación y el ciclo de prueba un día o dos más. ¡El proyecto durará fácilmente dos semanas completas en lugar del original!

— Mesas Bobby
fuente

Bueno, su ejemplo está un poco ideado por el poco realista plazo que le queda al proyecto. Cámbielo a un mes y verá que no es necesariamente cierto. Personalmente creo que se abusó de la cita. Es cierto cuando se considera un programador mediocre / promedio. Si tiene un buen programador y la fecha límite no es poco realista como 1 día o 1 semana, entonces la cita es incorrecta: se puede hacer (ayude al proyecto).

— n1ckp

@ n1ck Es una generalización, como "demasiados cocineros". El punto clave es que simplemente arrojar mano de obra al proyecto no necesariamente hará que se resuelva más rápido. 1 persona a 2? Probablemente lo hará. 2 a 4? Demasiadas variables: depende del tamaño y la estructura del proyecto. 4 -> 8? Definitivamente cada vez más marginal (al menos en términos de rentabilidad del costo).

— Murph

@Murph: parece estar pensando sobre todo en las mismas cosas que yo, pero olvidó una variable muy importante en su ecuación: el nivel de habilidad de la mano de obra agregada. Estaba en mi último comentario, así que me parece extraño que te lo hayas perdido. Por supuesto, agregar mano de obra a ciegas no es la solución. Por supuesto, agregar mano de obra muy especializada (no necesita muchos) puede ayudar y es lo que faltaba en la mítica cita del mes del hombre. Ese fue mi punto. De lo contrario, ya sé lo que significa la cita.

— n1ckp

Ok, el ejemplo podría ser mejor, pero la generalización sigue siendo válida.

— Murph

1

He pasado por esto suficientes veces para saber que es una de esas cosas que PODRÍA funcionar en casos muy especializados, pero el 99% de las veces no lo hará. No importa cuán bien se vea en teoría en ese momento. Dicho eso, sí, no es un absoluto en blanco y negro. Es más como decir, cómo las relaciones abiertas no funcionan. La teoría es agradable y tentadora;) .... pero la naturaleza de la bestia es tal que en la mayoría de los casos termina fallando. Una especie de cosa de "las excepciones prueban la regla".

— Bobby Tables

4

Fred Brooks escribió un libro completo "The Mythical Man-Month" respondiendo esta pregunta.

Aquí está la versión rápida y sucia:

1) Hay un límite en cuanto a cuánto puede dividir un proyecto en partes distintas para asignar a más programadores.

2) Dividir un proyecto entre más personas aumenta la cantidad de comunicación requerida para coordinar todas las partes de la aplicación. Más comunicación = más trabajo.

3) Por cada persona que agregue al proyecto, agregue más de un canal de comunicación que se debe navegar al equipo. Este número crece geométricamente y aumenta la cantidad de comunicación que debe ocurrir. Más comunicación = más trabajo.

4) Hay una "Curva J" cuando agrega a cada miembro del equipo. Es decir, los recursos productivos existentes tienen que dedicar tiempo a poner al día a las nuevas personas que de otro modo podrían haber pasado trabajando en el proyecto. En última instancia, puede aumentar la capacidad, pero ralentiza temporalmente el proyecto. Cuanto más tarde en el proyecto, más se debe aprender, por lo tanto, más pronunciado es el efecto.

— JohnFx
fuente

4

Otro factor que no he visto mencionado es que algunas tareas deben realizarse en un orden específico. No puede hacer la tarea 4 hasta que se complete la tarea 3 porque depende de 3. No sirve de nada contratar a alguien para que haga la tarea 4 al mismo tiempo que alguien está haciendo la tarea 3. A menudo al final de un proyecto , aquellas tareas que necesitan completar otras cosas primero son las tareas restantes.

También son a menudo algunas de las tareas más complejas que deben realizarse, las mismas que requieren la mejor comprensión de todo el diseño para evitar romper lo que ya se ha completado. También suelen requerir el conocimiento más extenso del dominio empresarial. Después de trabajar en el proyecto durante meses, podría hacer la tarea en una semana o menos. Alguien nuevo pasaría más de una semana poniéndose al día (y alejándome de mis tareas durante un buen tiempo para responder preguntas) y probablemente incluso si fuera extremadamente hábil tomara más tiempo hacer la tarea. No se debe a que él o ella no sea competente, sino por la falta de familiaridad con la estructura real del proyecto o el backend de la base de datos.

— HLGEM
fuente

+1. Este fue un problema importante en mi último trabajo. La gerencia estaba en mega "mes del hombre agregando" locura por un proyecto importante sin pensarlo bien. En un momento, nuestro equipo fue perforado por ser lento, porque nuestras cosas necesitaban integrarse con ese gran proyecto. Pero entonces, las nuevas contrataciones en el proyecto principal no pudieron alcanzar la velocidad lo suficientemente rápido, por lo que NOSOTROS nos adelantamos demasiado (en cosas que necesitaban completar sus backends). En un momento estábamos desarrollando partes frontales para backends a medio cocer y arneses de prueba. No es un buen flujo.

— Bobby Tables

2

El adagio que siempre funcionó para mí es que no puedes lograr que nueve mujeres tengan un bebé en un mes.

— repetición
fuente

Si crees que un proyecto de software es como un bebé, no vives en el mundo real. Hay algo de verdad en la cita, pero este es el ejemplo perfecto de sacar las cosas de contexto: -1

— n1ckp

1

Obviamente no. Pero las personas con las que también vendes los plazos no entienden el desarrollo de software. Las analogías son exactamente para ese propósito que relacionan un concepto desconocido con una entidad conocida.

— volver a ejecutar el

2

Otra analogía que Brooks hace es la comida en un restaurante. Una cocina bien administrada puede hacer muchas comidas en paralelo, pero hay límites en cuanto a qué tan rápido puede hacer una sola comida sin cocinarla o quemarla.

— David Thornley

@rerun: el problema con su analogía es que no existe una analogía laboral para una mujer embarazada. Las mujeres en su caso podrían compararse más fácilmente con la empresa , no con los trabajadores. Es por eso que falla tanto en mi opinión. Lo más cercano que se me ocurre sería la comida, pero sería más como una línea de códigos, así que no, no trabajadores.

— n1ckp

1

@ n1ck: Mi impresión es que no estás de acuerdo porque no lo entiendes, para ser honesto. Brooks no estaba hablando de reemplazar a las personas inútiles por personas competentes, porque se encontraba en una situación en la que todos los empleados todavía se consideraban competentes.

— David Thornley

2

También sugeriría "Peopleware" de DeMarco y Lister.

Y "The Deadline" de DeMarco presenta esto, y una serie de otras enfermedades y falacias de gestión de proyectos de software de una manera alegre y muy legible.

También profundiza en la dinámica de las personas que realizan proyectos / trabajo en equipo, y detalla cómo las cosas como la comunicación y la presentación agotan el tiempo de trabajo disponible de un equipo.

Estos libros son bastante baratos, te sugiero que los obtengas (Amazon o The Book Depository los tienen) y que los leas. Las respuestas cortas aquí realmente no pueden hacer justicia a la pregunta formulada.

— rápidamente_ahora
fuente

2

Porque nadie se toma el tiempo para tener un proceso bien pensado, planificado y probado para: contratar, capacitar, desarrollar y supervisar programadores, y mucho menos ponerlos al día en un proyecto en particular.

Si está gestionando un equipo de desarrolladores, debe tener varios contactos en este momento de personas que le gustaría contratar si tiene una apertura. Únete a grupos de desarrolladores.

¿Qué tan rápido puede obtener una nueva configuración de máquina de desarrollo y lista para usar?

¿Alguna vez ha probado la documentación y las especificaciones de su proyecto mostrándolas a un desarrollador en otro proyecto? ¿Lo miraron y determinaron que podrían comenzar a trabajar en el proyecto si fuera necesario?

¿Qué tan actualizado está cualquier cronograma del proyecto?

Ahorre para un día lluvioso porque cuando un proyecto se queda atrás es más como un huracán.

— JeffO
fuente

1

Además del problema de comunicación (del cual creo que todas las otras respuestas están hablando), también es muy posible que una persona agregada a un proyecto cree errores, porque todavía no conocen muy bien el código.

Cada vez que me agregan a un proyecto, siempre trato de no romper cosas. Esto significa que soy mucho más lento al arreglar las cosas al principio.

— Paul D. Waite
fuente

0

Me gustaría señalar algo totalmente ignorado hasta ahora por las otras respuestas.

Para cuando se agregan personas a un proyecto tardío, generalmente muchas cosas han salido mal en toda la organización. La gerencia y el cliente no están contentos. La gente ha sido presionada para seguir adelante. Las cosas están bastante tensas.

Ahora imagina que estás en ese equipo. Obviamente, nada de esto es tu culpa. La planificación (ninguna de las cuales fue suya) ha sido demasiado optimista. Se tomaron todas las decisiones equivocadas sin consultarlo. Estás tratando de sacar el máximo provecho y, de repente, un montón de personas nuevas están siendo transportadas. ¿Qué mensaje transmite esto?

La gente de arriba obviamente ha perdido la fe en ti. Llamaron a los muchachos grandes para compensar lo que arruinaste.

¿Seguirás motivado para que esto sea un éxito? O ... ¿te sentirás cada vez más frustrado y prefieres ver que todo se derrumba después de todo?

Tome su tiempo :-).

— Martin Maat
fuente