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

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

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.

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.

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 .

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

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á.

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!

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.

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.

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

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.

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.

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.

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 :-).