Necesito a este bebé en un mes. ¡Envíame nueve mujeres!

¿En qué circunstancias, si es que hay alguna, agregar programas a un equipo realmente acelera el desarrollo de un proyecto que ya está retrasado?

Las circunstancias exactas son obviamente muy específicas para su proyecto (por ejemplo, equipo de desarrollo, estilo de gestión, madurez del proceso, dificultad del tema, etc.). Para comprender esto un poco mejor para que podamos hablar de eso en cualquier cosa que no sea simplificaciones excesivas, voy a repetir su pregunta:

¿En qué circunstancias, si las hay, puede agregar miembros del equipo a un proyecto de desarrollo de software que se está ejecutando tarde dar como resultado una reducción en la fecha de envío real con un nivel de calidad igual a eso si el equipo existente pudiera trabajar hasta su finalización?

Hay una serie de cosas que creo que son necesarias , pero no suficientes, para que esto ocurra (sin ningún orden en particular):

• Las personas propuestas para ser agregadas al proyecto deben tener:
  • Al menos una comprensión razonable del dominio del problema del proyecto.
  • Ser competente en el lenguaje del proyecto y las tecnologías específicas que utilizarían para las tareas que se les asignarían.
  • Su dominio debe / no / ser mucho menor o mucho mayor que el miembro existente más débil o más fuerte, respectivamente. Los miembros débiles agotarán a su personal existente con problemas terciarios, mientras que una persona nueva que sea demasiado fuerte perturbará al equipo con la forma en que todo lo que han hecho y están haciendo está mal.
  • Tener buenas habilidades de comunicación.
  • Estar altamente motivado (por ejemplo, ser capaz de trabajar independientemente sin presionar)
• Los miembros del equipo existentes deben tener:
  • Excelentes habilidades de comunicación
  • Excelentes habilidades de gestión del tiempo.
• El líder / gestión del proyecto debe tener:
  • Buenas capacidades de priorización y asignación de recursos.
  • Un alto nivel de respeto por parte de los miembros del equipo existentes.
  • Excelentes habilidades de comunicación
• El proyecto debe tener:
  • Una buena, completa y documentada especificación de diseño de software
  • Buena documentación de cosas ya implementadas
  • Un diseño modular para permitir que se formen claros trozos de responsabilidad.
  • Procesos automatizados suficientes para el aseguramiento de la calidad para el nivel de defecto requerido. Estos pueden incluir cosas tales como: pruebas unitarias, pruebas de regresión, implementaciones de compilación automatizadas, etc.)
  • Un sistema de seguimiento de errores / características que actualmente está en su lugar y en uso por el equipo (por ejemplo, trac, SourceForge, FogBugz, etc.).

Una de las primeras cosas que debe discutirse es si la fecha de envío se puede deslizar, si las características se pueden cortar y si algunas combinaciones de las dos le permitirán satisfacer la liberación con su personal actual. Muchas veces son un par de características las que realmente están acaparando los recursos del equipo que no ofrecerán un valor igual a la inversión. Por lo tanto, evalúe seriamente las prioridades de su proyecto antes que nada.

Si el resultado del párrafo anterior no es suficiente, visite la lista anterior. Si captó el boleto de horario temprano, la incorporación de los miembros correctos del equipo en el momento adecuado puede salvar el lanzamiento. Desafortunadamente, cuanto más se acerque a su fecha de envío esperada, más cosas pueden salir mal al agregar personas. En un momento, cruzará el "punto de no retorno" donde ninguna cantidad de cambio (aparte del envío de la rama de desarrollo actual) puede guardar su versión.

Podría seguir y seguir, pero creo que llegué a los puntos principales. Fuera del proyecto y en términos de su carrera, el éxito futuro de la compañía, etc., una de las cosas que definitivamente debe hacer es descubrir por qué llegó tarde, si se pudo haber hecho algo, lo alertó antes y qué medidas necesita tomar para prevenirlo en el futuro. Un proyecto tardío generalmente ocurre porque:

• Llegó tarde antes de comenzar (más cosas que tiempo) y / o
• se deslizó 1 hora, 1 día a la vez.

¡Espero que ayude!

Solo ayuda si tiene un proyecto basado en recursos.

Por ejemplo, considere esto:

Necesita pintar un póster grande, digamos 4 por 6 metros. Un póster tan grande, probablemente pueda poner a dos o tres personas delante y hacer que pinten en paralelo. Sin embargo, colocar a 20 personas delante no funcionará. Además, necesitará personas capacitadas, a menos que desee un póster horrible.

Sin embargo, si su proyecto es rellenar sobres con letras ya impresas (¡como podría haber ganado! ), Cuantas más personas agregue, más rápido será. Hay un poco de sobrecarga en repartir pilas de trabajo, por lo que no puede obtener beneficios hasta el punto en que tenga 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 pequeños trozos, 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 muchos proyectos son así en nuestro mundo, por lo que el consejo de docgnome sobre el libro Mythical Man-Month es un muy buen consejo.

Tal vez si se aplican las siguientes condiciones:

1. Los nuevos programadores ya entienden el proyecto y no necesitan ningún tiempo de aceleración.
2. Los nuevos programadores ya dominan 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.

Según el Mythical Man-Month, la razón principal por la que las personas se agregan a un proyecto tardío lo hace más tarde es la sobrecarga de comunicación O (n ^ 2).

He experimentado una excepción principal a esto: si solo hay una persona en un proyecto, casi siempre está condenado. Agregar un segundo lo acelera casi siempre. Esto se debe a que la comunicación no es una sobrecarga 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 Mythical Man-Month solo se aplica a proyectos tardíos . Si su proyecto aún no llega tarde, es muy posible que agregar personas no lo haga más tarde. Asumiendo que lo hagas correctamente, por supuesto.

Si los programadores existentes son totalmente incompetentes, puede ser útil agregar programadores competentes.

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

Básicamente, las referencias del Mes Mítico del Hombre son correctas, excepto en casos artificiales como el que inventé. El Sr. Brooks realizó una investigación sólida para demostrar que después de cierto punto, los costos de redes 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 tareas que no son de codificación, como diseño / diseño visual, ajuste / indexación de bases de datos o configuración del servidor / configuración de red) para que una persona pueda trabajar en eso mientras que 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 con el conocimiento de cuándo se pisarán los pies y cómo evitar hacerlo (esto, por supuesto, es bastante difícil de organizar si aún no es el caso)

Solo cuando tiene en esa etapa tardía algunas tareas independientes (casi 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 incorporación de un miembro del equipo tiene que minimizar la interrupción para el resto del equipo.

En lugar de agregar programadores, uno 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 cosas más prosaicas como obtener almuerzos.

Obviamente, cada proyecto es diferente, pero la mayoría de los trabajos de desarrollo pueden tener cierta colaboración entre los desarrolladores. Cuando este es el 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, esta puede ser su gente clave (por lo general, es la gente 'clave' la que tomaría el momento de educar a un nuevob). Cuando están al día, no hay garantías de que su trabajo se ajuste a las "reglas" o "cultura de trabajo" establecidas con el resto del equipo. De nuevo, puede hacer más daño que bien. Aparte de eso, estas son las circunstancias en las que podría ser beneficioso:

1) El nuevo recurso tiene una tarea difícil que requiere un mínimo de interacción con otros desarrolladores y un conjunto de habilidades que ya se ha demostrado. (es decir, portar código existente a una nueva plataforma, refactorizar 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 se pueda compartir el tiempo de otros miembros más importantes del equipo para ayudar a poner al día a los nuevos 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.

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 aquellos que no tienen experiencia.

EDITAR: Olvidé mencionar, este tipo de cosas no sucede con demasiada frecuencia. Por lo general, es bastante sencillo, como las pantallas de administración que hacen CRUD simple en una tabla. En estos días, este tipo de herramientas se pueden generar principalmente de todos modos.

Sin embargo, tenga cuidado con los gerentes que confían en este tipo de trabajo. Suena genial, pero en realidad generalmente no hay suficiente para recortar un tiempo significativo del proyecto.

• Módulos autónomos que aún no se han iniciado.
• Al carecer 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 para todo.

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

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 centrarme 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 motivados, que pueden heredar grandes proyectos y aprender de forma independiente. :-)

Si el recurso adicional complementa 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 ajustada en lugar de solo devolver buenos resultados (que su equipo conoce como expertos en el dominio), tomar prestado tiempo de un buen dba que trabaje en el próximo proyecto a los tuyos puede acelerar el equipo sin mucho costo de entrenamiento

Simplemente pon. Todo se reduce a comparar el tiempo restante y la productividad que obtendrá de alguien, excluyendo la cantidad de tiempo que toma los recursos adicionales para acelerar y ser productivo y restando el tiempo invertido en enseñarles los recursos existentes. Los factores clave (en orden de importancia):

1. Qué bueno es el recurso para recogerlo. Los mejores desarrolladores pueden acceder a un nuevo sitio y ser productivos reparando 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 recomendada y prácticas comunes bien documentadas, entonces un buen desarrollador puede quedarse atrapado de inmediato. Este factor más que ningún otro determinará cuánto tiempo tendrán los recursos existentes para invertir en la enseñanza y, por lo tanto, el impacto negativo inicial de los nuevos recursos.
4. La cantidad de tiempo restante. Esto a menudo también se estima mal. Con frecuencia, la lógica será que solo nos quedan x semanas y tomará x + 1 semanas poner a alguien al día. En realidad, el proyecto se va a resbalar y, de hecho, le quedan 2x semanas de desarrollo y obtener más recursos más pronto que tarde ayudará.

Cuando un equipo ya está acostumbrado a emparejar la programación, entonces agregar otro desarrollador que ya sea experto en emparejar puede no retrasar el proyecto, particularmente si el desarrollo continúa con un estilo TDD.

El nuevo desarrollador lentamente se volverá más productivo a medida que comprenda más la base del código, y cualquier malentendido será detectado muy pronto, ya sea por su pareja o por el conjunto de pruebas que se ejecuta antes de cada check-in (e idealmente debería haber 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.

Agregar desarrolladores tiene sentido cuando la productividad aportada por los desarrolladores adicionales excede la productividad perdida por la capacitación y la administración de esos desarrolladores.