Necesito a este bebé en un mes, ¡envíame nueve mujeres!

Solo ayuda si tienes un proyecto basado en recursos.

Por ejemplo, considera esto:

Necesitas pintar un póster grande, digamos 4 por 6 metros. En un póster tan grande, es probable que puedas poner dos o tres personas enfrente y pintarlas en paralelo. Sin embargo, colocar a 20 personas delante de él no funcionará. Además, necesitarás personas capacitadas, a menos que quieras un póster de mierda.

Sin embargo, si su proyecto es rellenar sobres con letras ya impresas (como ¡PODRÍA haber ganado!) entonces, cuanta más gente agregue, más rápido irá. Hay una cierta sobrecarga en repartir pilas de trabajo, por lo que no puede obtener beneficios hasta el punto en que tiene una persona pr. sobre, pero puede obtener beneficios de mucho más que solo 2 o 3 personas.

Entonces, si su proyecto se puede dividir fácilmente en partes pequeñas, y si los miembros del equipo pueden ponerse al día rápidamente (como ... instantáneamente), agregar más personas lo hará más rápido, hasta cierto punto.

Lamentablemente, no hay muchos proyectos así en nuestro mundo, por lo que la sugerencia del docgnome sobre el libro del Mes del Hombre Mítico es un muy buen consejo.

Tal vez si se aplican las siguientes condiciones:

1. Los nuevos programadores ya entienden el proyecto y no necesitan tiempo de aceleración.
2. Los nuevos programadores ya son competentes con el entorno de desarrollo.
3. No se necesita tiempo administrativo para agregar los desarrolladores al equipo.
4. Casi no se requiere comunicación entre los miembros del equipo.

Te lo haré saber la primera vez que vea todo esto a la vez.

De acuerdo con el Mes-Hombre Mítico, la razón principal por la cual las personas se suman a un proyecto tardío hace que sea más tarde es la sobrecarga de comunicación O (n ^ 2).

He experimentado una excepción principal a esto: si solo hay na persona en un proyecto, casi siempre está condenada. Agregar un segundo lo acelera casi siempre. Eso es porque la comunicación no es gastos generales en ese caso, es una oportunidad útil para aclarar sus pensamientos y cometer menos errores estúpidos.

Además, como obviamente sabía cuando publicó su pregunta, el consejo del Mes-Mes mítico solo se aplica a tarde proyectos. Si su proyecto no llega tarde, es muy posible que agregar personas no lo haga más tarde. Suponiendo que lo hagas correctamente, por supuesto.

Si los programadores existentes son totalmente incompetentes, agregar programadores competentes puede ayudar.

Puedo imaginar una situación en la que tenías un sistema muy modular, y los programadores existentes ni siquiera tenían empezado en un módulo muy aislado. En ese caso, puede serle útil asignar esa parte del proyecto a un nuevo programador.

Básicamente, las referencias al Mes del Hombre Mítico son correctas, excepto en casos ideados como el que inventé. El Sr. Brooks realizó una investigación sólida para demostrar que, después de un cierto punto, los costos de red y comunicación de agregar nuevos programadores a un proyecto superarán cualquier beneficio que obtenga de su productividad.

• Si las nuevas personas se centran en las pruebas.
• Si puede aislar características independientes que no crean nuevas dependencias
• Si puede ortogonalizar algunos aspectos del proyecto (especialmente las tareas que no son de codificación, como el diseño/diseño visual, la optimización/indexación de la base de datos o la configuración del servidor/configuración de red) para que una persona pueda trabajar en eso mientras que las otras continúan con el código de la aplicación.
• Si las personas se conocen entre sí, y la tecnología, y los requisitos comerciales, y el diseño, lo suficientemente bien como para poder hacer cosas sabiendo cuándo pisarán los dedos de los demás y cómo evitar hacerlo (esto, por supuesto, es bastante difícil de arreglar si no es ya el caso)

En lugar de agregar programadores, se puede pensar en agregar ayuda administrativa. Cualquier cosa que elimine las distracciones, mejore el enfoque o mejore la motivación puede ser útil. Esto incluye tanto el sistema como la administración, así como otras cosas más prosaicas como conseguir almuerzos.

Solo cuando tiene en esa etapa tardía algunas tareas independientes (casi el 0% de interacción con otras partes del proyecto) que aún no han sido abordadas por nadie y puede traer al equipo a alguien que sea un especialista en ese dominio. La adición de un miembro del equipo tiene que minimizar la interrupción para el resto del equipo.

Supongo que agregar personas hacia el final del trabajo podría acelerar las cosas si:

1. El trabajo se puede hacer en paralelo.

2. La cantidad ahorrada por los recursos agregados es más que la cantidad de tiempo perdido al hacer que las personas con experiencia en el proyecto expliquen las cosas a quienes no tienen experiencia.

EDIT: me olvidé de mencionar, este tipo de cosas no sucede con demasiada frecuencia. Por lo general, es algo bastante sencillo, como las pantallas de administración que hacen CRUD simple a una tabla. En estos días, estos tipos de herramientas pueden ser en su mayoría autogeneradas de todos modos.

Sin embargo, tenga cuidado con los gerentes que realizan operaciones bancarias en este tipo de trabajo. Suena bien, pero en realidad no suele ser suficiente recortar un tiempo significativo fuera del proyecto.

Obviamente, cada proyecto es diferente, pero se puede garantizar que la mayoría de los trabajos de desarrollo tengan una cierta colaboración entre los desarrolladores. En este caso, mi experiencia ha sido que los recursos nuevos pueden en realidad desacelerar involuntariamente a las personas en las que confían para ponerlos al día y, en algunos casos, pueden ser sus personas clave (por cierto, generalmente son personas 'clave' las que tomarían El tiempo para educar a un nuevo. Cuando están actualizados, no hay garantías de que su trabajo se ajuste a las 'reglas' o 'cultura de trabajo' establecidas con el resto del equipo. Así que de nuevo, puede hacer más daño que bien. De modo que aparte, estas son las circunstancias en las que podría ser beneficioso:

1) El nuevo recurso tiene una tarea apretada que requiere un mínimo de interacción con otros desarrolladores y un conjunto de habilidades que ya se ha demostrado. (es decir, transferir el código existente a una nueva plataforma, refactorizando externamente un módulo muerto que actualmente está bloqueado en la base de código existente).

2) El proyecto se gestiona de tal manera que el tiempo de otros miembros del equipo de más alto nivel puede compartirse para ayudar a poner al día a los nuevos empleados y asesorarlos en el camino para garantizar que su trabajo sea compatible con lo que ya se ha hecho.

3) Los otros miembros del equipo son muy pacientes.

• Módulos autocontenidos que aún no se han iniciado.
• A falta de herramientas de desarrollo que puedan integrar (como un administrador de compilación automatizado)

Principalmente estoy pensando en cosas que les permiten mantenerse fuera del camino de las personas que se están desarrollando actualmente. Estoy de acuerdo con Mythical Man-Month, pero también creo que hay excepciones a todo.

Creo que agregar personas a un equipo puede acelerar un proyecto más que agregarlos al proyecto en sí.

A menudo me encuentro con el problema de tener demasiados proyectos concurrentes. Cualquiera de esos proyectos podría completarse más rápido si pudiera concentrarme solo en ese proyecto. Al agregar miembros del equipo, podría hacer la transición de otros proyectos.

Por supuesto, esto supone que ha contratado desarrolladores capaces y auto motivados, que pueden heredar grandes proyectos y aprender de forma independiente. :-)

Si el recurso adicional complemento su equipo existente puede ser ideal. Por ejemplo, si está a punto de configurar su hardware de producción y verifica que la base de datos esté realmente sintonizada en lugar de simplemente devolver buenos resultados (que su equipo conoce como expertos en dominios), tome tiempo prestado de un buen dba que trabaja en el próximo proyecto. A la tuya puedes acelerar el equipo sin mucho coste de entrenamiento.

Simplemente pon. Todo se reduce a comparar el tiempo restante y la productividad que obtendrá de alguien que excluye la cantidad de tiempo que toma los recursos adicionales para llegar a la velocidad y ser productivos, y restar el tiempo invertido en la enseñanza de los recursos existentes. Los factores clave (en orden de importancia):

1. Qué bueno es el recurso para recogerlo. Los mejores desarrolladores pueden ingresar a un nuevo sitio y ser productivos corrigiendo errores casi instantáneamente con poca ayuda. Esta habilidad es rara pero se puede aprender.
2. La segregabilidad de las tareas. Deben poder trabajar en objetos y funciones sin tropezar con los desarrolladores existentes y ralentizarlos.
3. La complejidad del proyecto y la documentación disponible. Si se trata de una aplicación ASP.Net de Vanilla con las mejores prácticas y de los escenarios empresariales bien documentados comunes, un buen desarrollador puede quedarse bloqueado de inmediato. Este factor más que cualquier otro determinará cuánto tiempo tendrán que invertir los recursos existentes en la enseñanza y, por lo tanto, el impacto negativo inicial de los nuevos recursos.
4. La cantidad de tiempo restante. Esto es a menudo mal estimado también. Con frecuencia, la lógica será que solo nos quedan x semanas y demorará x + 1 semanas para que alguien esté al día. En realidad, el proyecto IS va a fracasar y, de hecho, le quedan 2 semanas de desarrollo y obtener más recursos más pronto que tarde ayudará.

Agregar desarrolladores tiene sentido cuando la productividad contribuida por los desarrolladores adicionales supera la productividad perdida en la capacitación y la gestión de esos desarrolladores.

Cuando un equipo ya está acostumbrado a vincular la programación, luego agregar otro desarrollador que ya tiene experiencia en el emparejamiento no puede ralentizar el proyecto, especialmente si el desarrollo está avanzando con un estilo TDD.

El nuevo desarrollador se volverá más productivo lentamente a medida que comprendan más la base del código, y cualquier malentendido se detectará muy pronto, ya sea por su pareja o por el conjunto de pruebas que se ejecuta antes de cada registro (y lo ideal es que haya una verificación). en al menos cada diez minutos).

Sin embargo, los efectos de los gastos generales de comunicación adicionales deben tenerse en cuenta. Es importante no diluir demasiado el conocimiento existente del proyecto.