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

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.

  

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.

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.

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.

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.

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

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