¿Dar a los nuevos reclutas un subproyecto separado de desarrolladores experimentados ayudará a los novatos a acelerar su desarrollo?

12

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 que "si contrata a más desarrolladores, solo perderá 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 menor de los dos subproyectos, mientras que el equipo actual trabaja en el proyecto principal. A saber, el nuevo equipo trabajará en la funcionalidad de pago, que eventualmente se convertirá en un servicio web independiente para reducir el acoplamiento. De esta manera, el nuevo equipo trabaja en proyectos con solo 100 mil líneas de código.

Mi pregunta es: ¿ayudará este enfoque 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 y luego errores?

=======

ACTUALIZACIÓN

Esta empresa falló completamente, pero no por las razones que mencionaron. En primer lugar, estaba mal informado sobre el tamaño y la capacidad del nuevo equipo. Debería haberlos evaluado yo mismo. Segundo, la contratación resultó ser un trabajo difícil en ese sitio. En el sitio de la oficina principal, la contratación era 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 aproximadamente 4,5 meses y fue cancelado en la mitad por la alta dirección.

Otro error que cometí (y que Alex D me advirtió al respecto) es que estaba tratando de vender refactorización 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 ocurrió se convirtió en deuda técnica: el sistema se hizo más monolítico y menos mantenible, y la productividad del desarrollador disminuyó gradualmente. No estoy en el equipo ahora, pero espero que lo completen en el futuro más cercano. De lo contrario, no daría un centavo por la supervivencia del proyecto.

    
pregunta Dmitry Negoda 26.01.2012 - 08:09

7 respuestas

1

Acepto, 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 querer probar, es darles pequeños fragmentos / módulos / formas / clases de su proyecto, para trabajar con ellos, en lugar de todo el proyecto.

Si usa una base de datos, puede querer hacer una copia de un D.B. con datos, y acceda a ellos desde el módulo o subsistema de código con el que se va a trabajar.

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

¿Tiene alguna documentación de la aplicación como: U.M.L., E.R., Codd-Yourdon, lo que sea?

Buena suerte.

    
respondido por el umlcat 27.01.2012 - 02:17
15
  

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

"Newbie" 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 de manera programada, 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 los que está intentando para construir.

  

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

  • Compre o otorgue una licencia a un producto existente en lugar de intentar construir su propio producto. ¿Usted realmente necesita 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, debes pensar en lo que necesitarán saber sobre tus cosas existentes. Asegúrate de reservar suficiente tiempo para las sesiones de entrenamiento para que estén al día.

  • ¿Ha creado un conjunto de requisitos por escrito? Si no, haz eso ahora. Si espera estar diseñando el proyecto en lugar de permitir que el nuevo equipo haga eso, también debe preparar un documento de diseño claro, pero debe estar abierto a los cambios en respuesta a los comentarios de los nuevos miembros del equipo.

  • ¿Tiene 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 un equipo de siete personas y hacer que trabajen de manera productiva en cuestión de semanas, pero quererlo no significa que pueda tener eso. Dependiendo de dónde se encuentre, puede llevar mucho más tiempo que un mes encontrar a siete personas adecuadas. Tratar de apresurar las cosas ahora solo causará dolor y gastos más adelante.

respondido por el Caleb 26.01.2012 - 08:29
12

En mi humilde opinión, poner a todos los nuevos desarrolladores en el nuevo proyecto, separados de su equipo existente, está obligado a traer problemas. Sí, esto (puede) permitir que su antiguo equipo continúe trabajando más o menos a su ritmo actual. Sin embargo, los nuevos muchachos no tendrán una pista sobre la arquitectura general y el panorama general, por lo que tardarán mucho tiempo en ponerse al día ... e incluso entonces podrían 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 asegurar que se mantenga una visión arquitectónica coherente y común.

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

    
respondido por el Péter Török 26.01.2012 - 11:13
9

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

Si está intentando cumplir con una fecha límite, ¿podría hacerlo de manera más confiable mediante el recorte de características? He encontrado que una excelente manera de hacer que los "plazos no cumplidos" sean aceptables para un cliente es hacer lanzamientos incrementales; libere una versión que tenga un subconjunto de las funciones requeridas, y luego, a medida que más funciones estén listas, libérelas de forma incremental, hasta la versión final.

    
respondido por el Alex D 26.01.2012 - 11:47
4

Entonces, estás tratando de ser el equipo que no sea víctima del Mythical Man Month . Tendrá varios problemas, alguien del equipo tendrá que hacer las entrevistas técnicas, luego tendrá que esperar unas semanas después de aceptar la posición 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 ser mentores, lo que disminuirá aún más la productividad.

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 vuelven más largas ...

Los traería en grupos más pequeños y sé que durante mucho tiempo la productividad no será proporcional al aumento de tamaño del equipo. Además, el gasto en el 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 que buscamos, su capacidad demostrada para ofrecer nuevas funciones". Así que cambie a un estilo de desarrollo que represente las funciones en partes más pequeñas, y más a menudo. Haga que los nuevos miembros del equipo prueben las nuevas funciones, que les ayudarán a entender el código base.

    
respondido por el mhoran_psprep 26.01.2012 - 14:46
2

Sería mejor no contratar a nadie nuevo y observar sus procesos para ver dónde puede hacer cambios para que las cosas vayan más rápido. Cuanto más pronto se encuentren los errores, menos tiempo se tardará en solucionarlos, entonces, ¿cómo están probando? ¿Estás haciendo revisiones de código? ¿Está prestando atención a la calidad del requisito? ¿Tiene procesos de compilación y desagregación automatizados? ¿Tienes pruebas automatizadas? ¿Está teniendo reuniones de pie diarias (¡qué asombroso es el desarrollo más rápido cuando alguien le preguntará por su progreso todos los días!)? ¿Estás utilizando procesos ágiles? ¿Tiene algunas fallas de diseño básicas que deben solucionarse para que el resto del desarrollo sea más rápido (un mal diseño puede ralentizar un proyecto de desarrollo increíblemente)?

Por favor lee el mes-hombre mítico. Es evidente que lo necesitará para poder decirle a la alta dirección por qué están tomando las decisiones más duras para acelerar un proyecto. .

    
respondido por el HLGEM 26.01.2012 - 16:14
0

¿Así que quieres tirarlos por un precipicio y ver si pueden volar? Creo que cuando descubres cosas por tu cuenta, tienden a quedarse contigo a largo plazo, en lugar de solo Tener soluciones dadas a ti. Sin embargo, eso supone que realmente descubres mejores soluciones. No entiendo por qué no puede permitir que este equipo tenga un líder calificado que les permita cometer algunos errores por su cuenta, además de brindarles orientación e instrucción aprendiendo de ejemplos de calidad.

    
respondido por el JeffO 26.01.2012 - 16:19

Lea otras preguntas en las etiquetas