¿Cómo poner al día a los nuevos miembros del equipo con el proyecto? [cerrado]

Estamos a punto de contratar 1-2 nuevos ingenieros para el equipo de software (que consta de 3 desarrolladores, 1 probador).

¿Cuáles son los pasos para integrarlos en el equipo?

Mis ideas son:

• leer documentación (estándares de codificación, documentos en metodologías de desarrollo que utilizamos)
• hacer que lean el código existente
• asignarles algunas tareas simples
• al final, hacerlos responsables de la parte del código

¿Qué más podriamos hacer?

El proyecto se encuentra en un sector médico (sistema de ultrasonido) y ya lleva 5 años. Tenemos lanzamientos anuales y estamos a punto de terminar un lanzamiento, cuando queremos agregar 1-2 ingenieros.

El proyecto se encuentra en la fase de mantenimiento (refactorizando el código heredado y agregando nuevas funciones). Las cosas están más o menos a tiempo (más o menos).

Viniendo de alguien que ha tenido que acelerar muchas bases de código diferentes en mi carrera, esto es lo que sugeriría:

1. Dedique un poco de tiempo (tal vez uno o dos días) a las actividades relacionadas con el uso del producto para que puedan familiarizarse con lo que hace el producto. Esto podría ser verificar errores o ejecutar planes de prueba de control de calidad o pasar por la capacitación del usuario.
2. Trabaja en pequeños errores localizados. Esto hace que el ingeniero se familiarice con cómo construir y depurar la aplicación sin tener que lidiar con el aprendizaje de una gran parte de la arquitectura.
3. Idealmente, escriba una pequeña característica nueva que esté localizada. Esto les permite escribir un fragmento de código y, a medida que lo escriben, se familiarizarán con los bits de código circundantes con los que su nuevo código necesita trabajar.

A partir de ahí, expanda el alcance y la complejidad de las tareas a lo largo del tiempo dependiendo del nivel de experiencia y aptitud del ingeniero. Eso permitirá al desarrollador ampliar su conocimiento de la base de código de forma natural.

Evitaría leer solo tareas (documentación o código). Leer la documentación se vuelve realmente aburrido muy rápido y leer código aleatorio no es útil ya que no tendrán ningún contexto con el que trabajar. Ya es bastante difícil leer el código para las revisiones de código cuando ya conoce el producto y la base de código. No puedo ver nada útil al tener un nuevo ingeniero leyendo el código.

Mi sensación es que la tolerancia de la mayoría de las personas para leer la documentación es bastante baja (bueno por un día o dos, pero más allá de eso, probablemente estarán ansiosos por hacer algo un poco más práctico).

No creo que realmente puedas entender el código de una aplicación sin una comprensión razonable de la aplicación en sí. El software presumiblemente tiene muchas funcionalidades con las que podrían 'jugar' como usuario; necesitarán poder probarlo eventualmente, por lo que espero que sea bastante importante que sepan cómo instalarlo, configurarlo y realizar tareas comunes con él.

Personalmente, considero que una descripción general de la arquitectura de alto nivel suele ser bastante útil para tener una idea básica de cómo funcionan las cosas. Las tuercas básicas de la aplicación principal. por ejemplo, comprender todos los subsistemas y cómo se unen las cosas, saber qué bits son manejados por software / bibliotecas de terceros y qué bits deben mantenerse internamente. (A menos que su organización tenga documentación actualizada de una calidad verdaderamente excepcional, supongo que no hay forma de que controlen ese tipo de cosas sin que alguien se las explique directamente usando una pizarra: ))

En cuanto a darles algo "práctico", las tareas de mantenimiento / búsqueda de errores pueden ser una buena manera de ponerlos al día por un tiempo (¿un par de semanas / meses?): Estarán en situaciones donde áreas específicas de funcionalidad necesita ser entendido, probado y depurado; ayudando a desarrollar el conocimiento del código, los requisitos, las herramientas utilizadas por la empresa, los procesos de desarrollo y los productos en su conjunto, mientras que con suerte no necesitará dedicar demasiado tiempo al resto del equipo de desarrollo

Como líder, paso al menos 2 días con nuevos desarrolladores. Descubrí que desarrollar una relación en la que se siente cómodo hacer la inevitable pregunta "¿cómo es su progreso?" es un deber. Hay miedo en cualquier comunidad nueva para encajar ... ocultamos errores, actuamos de manera perfecta, hacemos las cosas mejor de lo que son, disminuimos la dificultad. Un gerente que pase 2 días con alguien les hará saber que no se trata de su cultura y les permitirá liderar con el ejemplo. Los nuevos programadores necesitan una lección de historia sobre de dónde vienes y qué tan lejos estás. Los documentos simplemente no le hacen justicia a la tarea.

Solo he estado trabajando en la industria durante 10 meses (en colocación) pero descubrí que lo siguiente me ayudó:

• Trabajando en equipo con otros desarrolladores y observando cómo abordan los problemas.
• Ayudar a probar el software, necesitaría probar la función x, lo que significa que leí la documentación sobre la función x. Hice esto mucho, me ayudó.

Ambos me ayudaron un poco. Buena suerte.

Iría de alto nivel a bajo.

Demuestre la aplicación lo antes posible

Una de las cosas más importantes es que el desarrollador tiene una idea de en qué trabajará. Durante la demostración, señale algunas de las cosas que se han desarrollado recientemente y la dirección de la aplicación.

Explicar la arquitectura de alto nivel.

Esto también es muy importante. Permita que el nuevo desarrollador escuche y haga preguntas. Haga esto como un ejercicio grupal con los otros desarrolladores, que con suerte intervendrán y lo ayudarán. Esto le permitirá al nuevo desarrollador saber que está bien hablar abierta y honestamente.

Tenga listo un excelente documento de incorporación

Tener un excelente documento de incorporación no solo ayuda a los nuevos desarrolladores, sino también a los antiguos. Puede contener expectativas, enlaces útiles e información de configuración del entorno. (No puedo decirle cuántas veces utilicé nuestra incorporación para configurar mi entorno cuando obtengo una nueva computadora ...) Esto debería estar bien estructurado y al punto y no quedarse y no ser un vertedero para cada pequeño detalle

Aliéntelo a hacer preguntas (y esté disponible para responderlas)

Con las respuestas, guíelos, pero no les diga qué hacer. Déles pistas pero permítales que finalmente lo descubran ellos mismos.

Ayuda a los otros miembros del equipo a dar la bienvenida al recién llegado

Hay dos caras de la moneda cuando alguien se une a un equipo. El equipo también necesita tener las herramientas para dar la bienvenida al nuevo desarrollador.

Déjelos tomar una tarea pequeña o dos

Permítales agregar algo nuevo y visible para el proyecto que sea demostrable. Cuando se muestre, indique quién lo hizo y qué buen trabajo hicieron. Esto realmente puede aumentar la autoestima. Cuanto más rápido sienten que están agregando valor, más rápido sienten que son parte del equipo. Cuanto más rápido se sientan capacitados para hacer lo mejor que puedan.

Anímelos a realizar tareas más difíciles una vez que se sientan más y más cómodos

Los buenos candidatos harán esto naturalmente.

Un flujo de "orientación" por el que he pasado (y que encontré útil) fue algo similar a:

1. Una breve presentación que da al "panorama general" cuáles son los componentes, cómo encajan y la arquitectura general.
2. Una descripción general del código, introducción a las funciones que manejan la lógica principal de los componentes que me asignaron. Cubrió algunas cosas relacionadas con las convenciones de codificación y el estilo.
3. Se asignaron un montón de problemas abiertos y errores de baja prioridad (que estaban localizados en gran medida en el componente que me asignaron y bastante simples).
4. Se esperaba que depurara a través de la aplicación y pidiera ayuda con cosas que no pude descifrar.
5. Después de que se realizó la solución, me guiaron por el proceso (revisión de código, prueba de nivel de desarrollo, etc.) de liberar a la integración.
6. Repita para las tareas / errores restantes asignados.

Creo que este enfoque (y sus variaciones) será útil porque:

• Esto fue más práctico y relativamente independiente (constante sin agarre de la mano, etc.). Por lo tanto, proporciona suficiente espacio / tiempo para que la nueva persona se acostumbre al código y la forma en que se hacen las cosas en el equipo.
• También es beneficioso para el equipo en su conjunto ya que se pueden resolver un par de tareas / errores de baja prioridad. La persona que ayuda a las personas nuevas también tiene más tiempo para ocuparse de las tareas que se les asignaron, ya que no se requiere una mano constante y se puede programar específicamente un tiempo para tratar los problemas / problemas que la nueva persona podría enfrentar.

Las contrataciones iniciales necesitan una tarea pequeña, pero no demasiado pequeña y bien definida para trabajar. De esta manera, pueden comenzar a tener una idea de cómo está estructurado el código al tratar de descubrir cómo realizar su tarea. En el proceso surgirán preguntas y en ese momento puede dirigirlas a la documentación u otros recursos que pueden usar para ayudarlos a internalizar la base del código. También ayuda si su ciclo de desarrollo, compromiso e implementación es corto y pueden ver los frutos de su trabajo en acción lo más rápido posible.

Así es como hago

1. Déles algunas tareas relacionadas con el proyecto (por ejemplo: si su proyecto es una aplicación de base de datos, pídales que simplemente creen una aplicación para conectarse con la base de datos y realizar una operación simple).
2. Cuando descubras que han entendido la idea de trabajar, dales una demostración del Proyecto
3. Pídales que lean la documentación.
4. Familiarícelos con los estilos y estándares de codificación
5. Más tarde, bríndeles algunos ejercicios de depuración (para conocer el flujo del proyecto).
6. Pídales que arreglen un punto que ya ha solucionado (solo para descubrir su lógica con él).
7. Finalmente hágales parte del proyecto.

Recuerde: no importa cuánto lo intente, hasta que y a menos que el participante comprenda el proyecto por completo, no podrá realizar el trabajo de manera más eficiente.

Número uno: primero aprenda a usar el software para descubrir qué problemas resuelve desde la perspectiva del usuario. Si no tiene una interfaz de usuario (por ejemplo, es un servicio de fondo o algo así), permítales usar cualquier interfaz disponible para consumirla. Obtener una nueva visión de la vista de un usuario de su software siempre es bueno, y podría ayudar al nuevo empleado a ver cosas que usted no puede, debido a que ya está incrustado en el proyecto.

Después de esto, un buen primer proyecto podría ser algo así como un módulo adicional o nuevo para agregar al software, minimizando la cantidad de conocimiento necesario de la base de código existente. Escribir algo nuevo siempre será más fácil que realizar una corrección de errores, lo que puede requerir muchos cambios en muchos archivos fuente. En mi opinión, dar a un nuevo empleado una tarea de corrección de errores probablemente los desconectará de su empresa.

Su esquema para familiarizar a los nuevos con el proyecto parece razonable. Pero tenga en cuenta que tendrán mucho que aprender al principio. Esta suele ser una situación abrumadora. Tendrá que ser paciente y responder las mismas preguntas repetidamente. Esto es normal, los nuevos desarrolladores tienen que aprender mucho, no subestimes esto. Si te enojas por estas preguntas repetidas, te arriesgas a que no te pregunten y tratarás de descubrir cosas solas que tal vez sean muy lentas en el mejor de los casos, pero con frecuencia imposibles. También deberán aprender la jerga. La mayoría de los proyectos de equipos desarrollan su propio lenguaje. Cuando explique conscientemente trate de evitar la jerga. Explique estas cosas como le explicaría a su madre. De nuevo, sé paciente.

Además, podría intentar integrarlos con los demás miembros del equipo probando algunas tareas de estilo de centro de evaluación, por ejemplo, construir un puente en 45 minutos a partir de 4 hojas de papel que sostienen una taza de café. Utilizamos esta técnica en un curso práctico de ingeniería de software para lograr que un grupo de 8 estudiantes rompa el hielo antes de trabajar en un solo proyecto durante 3 semanas. Ayuda a acelerar las fases de formación del equipo.

1) Déles una explicación de las reglas y pautas de su código. También dé una explicación general de cómo funciona su aplicación y la estructura general del código.

2) Encuentra algunos pequeños errores o proyectos que son en gran medida independientes de otro código. Explique lo que debe hacerse, en qué parte del código y verifíquelos regularmente.

3) Comience lentamente a darles proyectos cada vez más grandes mientras los revisa cada vez menos.

4) Siéntate junto a ellos de vez en cuando. Puedes aprender mucho simplemente mirando cómo alguien más aborda un problema. Pequeñas cosas como "oh, puedes buscar funciones en tu código presionando ctrl-". Son muy útiles.

Ahora, he descubierto que hay dos extremos :

• Alguien que hace una pregunta cada cinco minutos. "¿Qué hace este Path.Join?". Primero deben buscar una respuesta en Google y solo acudir a usted cuando no puedan encontrar una respuesta.

• Y el otro extremo, alguien que trabaja durante medio día sin hacer una sola pregunta. Deberían sentir que es bueno hacer preguntas. Solo quiero que primero lo prueben ellos mismos.

Esta fue mi fórmula y se usó con varios recién llegados; estos pasos demostraron ser altamente efectivos.

a) Todos los nuevos desarrolladores recibirán una introducción sobre los requisitos del proyecto y los procesos de desarrollo durante 2 días.

b) Asignar la tarea de 3 semanas de escribir pruebas Junit para el código que no tiene suficiente cobertura.

c) Una vez hecho 3, asigne tareas pequeñas

d) Asignar tareas complejas y realizadas.

Creo que solo asigne algunas tareas pequeñas, pídales que escriban algunas pruebas unitarias, haga que depuren algunos errores de regresión. Nada demasiado grande o exigente, pero lo suficiente como para tenerlos en pie.

También debe asignar un desarrollador senior, preferiblemente por nuevo desarrollador que pueda ayudar a guiar al candidato.

Y sí, haga que documenten lo que están aprendiendo sobre el sistema. Asumo aquí que tienes algún tipo de páginas wiki internas. Si no, definitivamente es una necesidad tanto a largo como a corto plazo, una forma sorprendentemente rápida de hacer que la gente se incremente. Las páginas Wiki no solo deben contener la documentación del código, sino también cosas como limitaciones conocidas (esto es software: D), soluciones, métricas de rendimiento de tiempo / memoria, etc.

No explique solo las buenas prácticas y estándares de codificación, sino explique cómo está estructurado el código de lectura. Explique qué se supone que debe hacer el software y cómo se logra o se logrará esto.

No lo entenderán hasta que haya algún trabajo que hacer, por lo que sugiero que se divida en dos partes, una antes de comenzar el trabajo real, y la segunda, después de que comiencen a trabajar. Buscarán en algún código o documentación y pensarán "¡¿ WTF !? ". Cuando esto ocurra, alguien los acompañará y les explicará los detalles menores.