¿Dar a los nuevos reclutas un subproyecto separado de los desarrolladores experimentados ayudará a los novatos a aumentar más rápidamente?

Tenemos 7 desarrolladores en un equipo y necesitamos duplicar nuestro ritmo de desarrollo en un corto período de tiempo (alrededor de un mes). Sé que hay una regla de sentido común que dice "si contrata a más desarrolladores, solo pierde productividad durante los primeros meses". El proyecto es un servicio web de comercio electrónico y tiene alrededor de 270 mil líneas de código.

Mi idea por ahora es dividir el proyecto en dos subproyectos más o menos independientes y dejar que el nuevo equipo trabaje en el más pequeño de los dos subproyectos, mientras que el equipo actual trabaja en el proyecto principal. Es decir, el nuevo equipo trabajará en la funcionalidad de pago, que eventualmente se convertirá en un servicio web independiente para disminuir el acoplamiento. De esta manera, el nuevo equipo trabaja en proyectos con solo 100K líneas de código.

Mi pregunta es: ¿este enfoque ayudará a los desarrolladores novatos a adaptarse fácilmente al nuevo proyecto? ¿Cuáles son otras formas de extender el equipo de desarrollo rápidamente sin esperar dos meses hasta que los novatos comiencen a producir más software que errores?

=======

ACTUALIZAR

Esta empresa fracasó por completo, pero no por las razones que ustedes mencionaron. En primer lugar, estaba mal informado sobre el tamaño y la capacidad del nuevo equipo. Debería haberlos evaluado yo mismo. En segundo lugar, la contratación resultó ser un trabajo duro en ese sitio. En el sitio de la oficina principal, la contratación fue mucho más fácil, pero en la ciudad del segundo equipo aparentemente había escasez de desarrolladores con la calificación requerida. Como resultado, en lugar de 1,5 meses proyectados, el trabajo se extendió a unos 4,5 meses y fue cancelado en el medio por la alta dirección.

Otro error que cometí (y Alex D me lo advirtió) es que estaba tratando de vender refactorizaciones a la alta dirección. Nunca vendes refactorización, solo características.

La puesta en marcha resultó ser exitosa de todos modos. La refactorización que nunca sucedió se convirtió en una deuda técnica: el sistema se volvió más monolítico y menos mantenible, la productividad del desarrollador disminuyó gradualmente. Ahora no estoy en el equipo, pero espero que lo completen en el futuro más cercano. De lo contrario, no daría un centavo por la supervivencia del proyecto.

Pensé, estoy de acuerdo como todos los demás aquí, que:

"... agregar más desarrolladores a un proyecto retrasado, hace que el proyecto demore más ..."

Tengo la sensación de que lo vas a hacer en cualquier lugar, así que ...

Su idea puede ayudar, si su proyecto existente está suficientemente organizado, por módulos, subsistemas o subproyectos.

Lo que puede intentar es darles pequeñas piezas / módulos / formas / clases de su proyecto, para que trabajen, en lugar de todo el proyecto.

Si usa una base de datos, es posible que desee hacer una copia de una base de datos que funcione con datos y acceder a ellos desde el módulo o subsistema de código con el que va a funcionar.

Tener nuevos desarrolladores que conozcan el lenguaje de programación o el entorno de programación no es suficiente, las aplicaciones de software pueden volverse muy complejas.

¿Tiene alguna documentación de la aplicación como: UML, ER, Codd-Yourdon, lo que sea?

Buena suerte.

Mi pregunta es si este enfoque ayudará a los desarrolladores novatos a adaptarse fácilmente al nuevo proyecto.

"Novato" puede significar algo nuevo para usted, o puede significar algo nuevo para trabajar como desarrolladores de software. Si va a contratar a un grupo de desarrolladores para trabajar en un proyecto importante en un horario, asegúrese de que al menos la mayoría de los nuevos empleados sean desarrolladores experimentados, y preferiblemente aquellos que hayan escrito proyectos similares a lo que está intentando para construir.

¿Cuáles son otras formas de extender el equipo de desarrollo rápidamente sin esperar dos meses hasta que comiencen a producir más software que errores?

• Compre o licencia un producto existente en lugar de tratar de construir el suyo propio. ¿ Realmente necesitas reinventar la rueda de pago?

• Como dije anteriormente, contrate personas que tengan experiencia en la construcción del tipo de sistema que desea.

• Incluso antes de contratar a este nuevo equipo, debe pensar en lo que necesitarán saber sobre sus cosas existentes. Asegúrese de reservar suficiente tiempo para las sesiones de entrenamiento para ayudarlos a ponerse al día.

• ¿Has creado un conjunto de requisitos por escrito? Si no, hazlo ahora. Si espera diseñar el proyecto en lugar de dejar que el nuevo equipo lo haga, también debe preparar un documento de diseño claro, pero debe estar abierto a los cambios en respuesta a las aportaciones de los nuevos miembros del equipo.

• ¿Tienes un proceso de desarrollo bien definido? Base de datos de errores? ¿Control de versiones? Proceso de revisión de código? ¿Guía de estilo? Pon esas cosas en su lugar.

• No esperes milagros. Usted quiere contratar a un equipo de siete personas y hacer que trabajar de forma productiva en cuestión de semanas, pero queriendo esto no significa que usted puede tener eso. Dependiendo de dónde se encuentre, puede llevar mucho más de un mes encontrar a siete personas adecuadas. Intentar apresurar las cosas ahora solo causará dolor y gastos más adelante.

En mi humilde opinión, poner a todos los nuevos desarrolladores en el nuevo proyecto, separados de su equipo existente, seguramente traerá problemas. Sí, esto (puede) permitir que su antiguo equipo siga trabajando más o menos a su ritmo actual. Sin embargo, los nuevos muchachos no tendrán ni idea de la arquitectura general y el panorama general, por lo que tomarán mucho tiempo para ponerse al día ... e incluso pueden estar yendo en la dirección equivocada.

Sugiero dividir su equipo existente en dos y contratar nuevos miembros en ambos equipos. De esta manera, hay personas en ambos equipos que pueden guiar a los recién llegados y garantizar que se mantenga una visión arquitectónica común y coherente.

De lo contrario, estoy de acuerdo con Caleb en cuanto a documentar requisitos claros, definir el proceso de desarrollo y las herramientas, y reservar tiempo para la capacitación ... y también en que esperar que un equipo de 7 sea contratado y se ponga al día dentro de un mes es irrealista.

Dmitry, duplicar tu ritmo de desarrollo en poco tiempo es un objetivo increíblemente ambicioso. Algunas buenas sugerencias han sido publicadas aquí; pero, no importa lo que intentes, ten en cuenta que puede no suceder . Si su ritmo de desarrollo no se duplica, ¿cuáles serían las consecuencias, desde una perspectiva comercial? ¿Estás tratando de presionar para cumplir con una fecha límite?

Si está tratando de cumplir con una fecha límite, ¿podría hacerlo de manera más confiable cortando funciones? He encontrado que una excelente manera de hacer que los "plazos vencidos" sean aceptables para un cliente es hacer lanzamientos incrementales; publique una versión que tenga un subconjunto de las funciones requeridas y, a medida que haya más funciones listas, publíquelas de forma incremental, hasta la versión final.

Entonces estás tratando de ser el equipo que no es víctima del Mes del Hombre Mítico . Tendrá varios problemas, alguien en el equipo tendrá que hacer las entrevistas técnicas, luego tendrá que esperar unas semanas después de que acepten el puesto antes de que puedan comenzar. Pueden pasar dos meses antes de que los nuevos desarrolladores estén frente a sus teclados.

Cada nuevo empleado tiene una productividad negativa en los primeros meses. Se agrava porque los desarrolladores actuales necesitarán guiarlos, disminuyendo aún más la productividad de los equipos.

La otra parte del MMM fue que a medida que el equipo crece, también lo hacen los problemas de comunicación. Las reuniones se hacen más grandes, las cadenas de correo electrónico se hacen más largas ...

Los reuniría en grupos más pequeños y sé que durante mucho tiempo la productividad no será proporcional al aumento del tamaño del equipo. También tenga en cuenta que el drenaje del flujo de efectivo durante los primeros meses puede ser significativo, debido a los costos de embarque y al equipo.

En su comentario a Alex D mencionó "No son los plazos los que buscamos, es su capacidad demostrable para ofrecer nuevas funciones". Así que cambie a un estilo de desarrollo que destaque las características en fragmentos más pequeños y con mayor frecuencia. Haga que los nuevos miembros del equipo prueben las nuevas características, que los ayudarán a comprender la base del código.

Sería mejor no contratar a nadie nuevo y mirar sus procesos para ver dónde puede hacer cambios para que las cosas vayan más rápido. Cuanto antes se encuentren los errores, menor será el tiempo necesario para solucionarlos, entonces, ¿cómo los está probando? ¿Estás haciendo revisiones de código? ¿Estás prestando atención a la calidad del requisito? ¿Tiene compilaciones automatizadas y procesos de despliegue? ¿Tienes pruebas automatizadas? ¿Está teniendo reuniones diarias de pie (¡Increíble cuánto más rápido puede llegar el desarrollo cuando alguien le pedirá su progreso todos los días!)? ¿Estás utilizando procesos ágiles? ¿Tiene algunos defectos de diseño básicos que deben abordarse para acelerar el resto del desarrollo (un mal diseño puede ralentizar increíblemente un proyecto de desarrollo).

Por favor lea el mes mítico del hombre. Claramente va a necesitarlo para poder decirle a la alta gerencia por qué están tomando las decisiones correctas para acelerar un proyecto. .

Entonces, ¿quieres tirarlos por un acantilado y ver si pueden volar? Creo que cuando descubres las cosas por tu cuenta, a la larga tienden a quedarte contigo en lugar de solo darte soluciones. Sin embargo, eso supone que realmente descubres mejores soluciones. No veo por qué no puede permitir que este equipo tenga un líder calificado que equilibre y permita que cometan algunos errores por sí mismos, además de brindarles orientación e instrucción al aprender de ejemplos de calidad.