¿Cuál es la mejor manera de involucrar a un desarrollador junior en el diseño de una aplicación desde cero? [cerrado]

Somos un equipo de 3 desarrolladores (2 desarrolladores experimentados y un junior).

Acabamos de comenzar un nuevo proyecto. Hemos diseñado la aplicación, hemos concentrado esfuerzos en elegir la arquitectura correcta y ahora estamos estableciendo las primeras líneas de código. Estamos escribiendo el núcleo de esto, lo que será la base de toda la aplicación.

Esta no es una aplicación fácil tampoco. Requisitos de rendimiento estrictos, modelo de entidad complejo distribuido masivamente, etc.

Todos estamos fuera de nuestra zona de confort, especialmente los junior. No tiene la experiencia para crear un buen diseño por adelantado. Sin embargo, eso no es un problema porque yo y el otro desarrollador estamos allí para ayudar y ambos creemos en la tutoría y en la formación de equipos, pero ... no sabemos exactamente cuál sería la mejor manera de hacerlo, para que él obtenga Una experiencia agradable y aprende la máxima cantidad de habilidades.

Ambos nos dimos cuenta de que no teníamos un junior en nuevos proyectos, solo en los existentes donde era más fácil para el junior porque tenía una base de código completa para aprender e inspirar. Pero para esta aplicación casi no tenemos código. Acabamos de empezar.

Estábamos pensando en algunos enfoques:

• haga que lo intente solo durante un par de días, luego intervenga y refactorice el código junto con él, guíelo en la dirección correcta y luego repita => Puede que no sea una experiencia divertida para él, ya que señalaremos sus errores en cada refactorizador ;
• que empareje la programación con uno de nosotros => podría convertirse en un simple "espectador" y estar de acuerdo con todo lo que hacemos, sin realmente aprender mucho o digerir mucha información;
• hacer que construyamos el esqueleto de cada módulo, con un diseño sólido y luego darle el módulo para que agregue las piezas que faltan => podría no ser divertido recogerlo después de nosotros y existe el riesgo de que solo preste atención a llenar los vacíos y no a todo el diseño.

¿Cómo podemos involucrarlo en el diseño para que no se sienta excluido de alguna manera y para que aprenda mucho de la experiencia y gane suficiente confianza para probarlo por su cuenta?

Recomiendo las siguientes pautas:

• Involucre al desarrollador junior en sus reuniones de diseño y solicite su opinión. Esto lo hará pensar en el panorama general, incluso si no está listo para hacer el diseño de alto nivel él mismo.
• Intente aislar y definir claramente un módulo de la aplicación para asignar al desarrollador junior. Describa por escrito cuáles son las entradas / salidas y otros requisitos del módulo. Evite asignarle un módulo que no se pueda probar fácilmente o que solo se pueda probar cuando se integre con otros módulos aún por escribir.
• Quizás el desarrollador junior podría ayudar de otras maneras además de codificar la aplicación principal. Por ejemplo, él podría escribir el código de prueba. Lejos de ser un trabajo de baja categoría, escribir buenos guiones de prueba hace una valiosa contribución al proyecto y también le da al desarrollador junior una comprensión sólida del proyecto.

Creo que depende de qué área quieres que mejore ese desarrollador junior. Cuando era (muy) junior, solían darme API que necesitaba para construir una cosa confinada en particular, como:

• esta función proporciona N número de personal de la tabla de personal
• Esta función proporciona estadísticas de personal dada la identificación del personal

->

Tarea: construya una página con una lista de personal que muestre sus estadísticas cuando se hace clic en un registro de personal. Aquí hay una página de muestra simple construida antes en el proyecto.

El aspecto más importante de la tarea dada es ser solucionable con esos recursos dados y no requiere ningún cambio en ellos.

Las 3 formas me parecen bien. En realidad, probar 10 formas ágiles diferentes al mismo tiempo debería darte buenos resultados pronto, al menos sabrás qué forma funciona y cuál no (cuál funcionará mejor depende en gran medida de las personalidades de los jugadores).

El problema de programación de pares no se producirá si se atiene al proceso con los sombreros de escritura / pensamiento cambiando cada 10 minutos (más o menos), sin excepción, siguiendo el proceso originalmente descrito por Kent Beck (no recuerdo dónde)

En cuanto a involucrar a otras personas en el diseño, lo que hemos encontrado que ayuda es si durante la fase de diseño se crean algunos documentos de diseño (con algunos modelos UML). Las otras personas (su menor) pueden leerlas, revisarlas, jugar al abogado del diablo. Esta función de un tercero independiente virgen puede ser realmente muy beneficiosa, por ejemplo, para pruebas exploratorias: http://www.softwaretestinghelp.com/exploratory-testing-beyond-traditional-testing-boundaries