¿Cómo actualizar a los nuevos miembros del equipo con el proyecto? [cerrado]

12

Estamos a punto de contratar 1-2 ingenieros nuevos 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:

  • lea la documentación (estándares de codificación, documentos en las metodologías de desarrollo que utilizamos)
  • haz que lean el código existente
  • asigne algunas tareas simples
  • al final, hazlos responsables de la parte del código

¿Qué más podríamos hacer?

El proyecto está en un sector médico (sistema de ultrasonido) y ya lleva 5 años. Tenemos versiones anuales y estamos a punto de terminar una versión, cuando queremos agregar 1-2 ingenieros.

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

    
pregunta BЈовић 19.04.2012 - 23:23

14 respuestas

9

Viniendo de alguien que ha tenido que ponerse al día en muchos códigos diferentes en mi carrera, esto es lo que sugeriría:

  1. Pase una breve cantidad de tiempo (quizás uno o dos días) en 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 & depure la aplicación sin tener que lidiar con aprender mucho de la arquitectura.
  3. Lo ideal es escribir una nueva característica pequeña que esté localizada. Esto les permite escribir un trozo de código y, a medida que lo escriban, se familiarizarán con los bits de código circundantes con los que necesita trabajar su nuevo código.

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

Evitaría leer solo las tareas (documentación o código). La lectura de la documentación se vuelve realmente aburrida realmente rápida y la lectura de códigos aleatorios no es útil, ya que no tendrán ningún contexto para trabajar. Es lo suficientemente difícil leer el código para las revisiones de código cuando ya conoce el producto y amp; codebase No puedo ver nada útil como resultado de tener un ingeniero nuevo que acaba de leer el código.

    
respondido por el 17 of 26 20.04.2012 - 15:12
5

Mi opinión es que la tolerancia de la mayoría de las personas a la lectura de documentos 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 una gran cantidad de funcionalidades con las que podrían "jugar" como usuario; Tendrán que ser capaces de probarlo con el tiempo, así que espero que sea muy 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 muy útil para tener una idea básica de cómo funcionan las cosas. Para ir a través de los tuercas y tornillos básicos de la aplicación principal. p.ej. entendiendo todos los subsistemas y cómo las cosas están vinculadas entre sí, sabiendo 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 puedan controlar 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 ponerlas al día por un tiempo (¿un par de semanas / meses?) - estarán en situaciones específicas. Las áreas de funcionalidad deben ser entendidas, probadas y depuradas; ayudando a desarrollar el conocimiento del código, los requisitos, las herramientas utilizadas por la empresa, los procesos de desarrollo y el (los) producto (s) en su conjunto, mientras que esperamos no tener que absorber demasiado tiempo del resto del equipo de desarrollo

    
respondido por el Ben Cottrell 20.04.2012 - 01:14
5

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

    
respondido por el Ben DeMott 21.04.2012 - 08:53
4

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

  • Hacer equipo con otros desarrolladores y observar cómo abordan los problemas.
  • La prueba del software me ayudó, necesitaría probar la función x, lo que significa que leí la documentación de la función x. Hice esto mucho, me ayudó.

Ambos me ayudaron un poco. Buena suerte.

    
respondido por el Tom 19.04.2012 - 23:32
3

Iría de alto nivel a bajo.

Demuestra 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 en la que va la aplicación.

Explica la arquitectura de alto nivel

Esto también es muy importante. Permita que el nuevo dev escuche y haga preguntas. Haga esto como un ejercicio grupal con los otros desarrolladores, quienes, con un poco de suerte, intervendrán y lo ayudarán. Esto permitirá que el nuevo desarrollador sepa que está bien hablar abiertamente y con honestidad.

Tenga preparado un excelente documento de incorporación

Tener un gran 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 decir cuántas veces utilicé nuestro sistema de integración para configurar mi entorno cuando obtengo una computadora nueva ...) Esto debería estar bien estructurado y al punto y no demorar y no ser un basurero para cada pequeño detalle

Anímelo a que haga preguntas (y esté disponible para responderlas)

Con las respuestas, guíalos, pero no les digas qué hacer. Déles pistas pero permítales finalmente entenderlas por sí mismos.

Ayuda a los demás 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 necesita tener las herramientas para dar la bienvenida al nuevo desarrollador también.

Permítales recoger una pequeña tarea o dos

Permítales agregar algo nuevo y visible al proyecto que sea demo-capaz. Cuando se demuestre, pregunte 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 se sienten parte del equipo. Cuanto más rápido se sientan capaces de hacer lo mejor que pueden.

Aliéntalos a participar en tareas más difíciles una vez que se sientan más cómodos

Los buenos candidatos lo harán naturalmente.

    
respondido por el c_maker 20.04.2012 - 19:09
1

Un flujo de "orientación" por el que he pasado (y me ha resultado útil) fue algo como:

  1. Una breve presentación que da al "panorama general" cuáles son los componentes, cómo se adaptan 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 asignados a mí. 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 se localizaron en gran medida en el componente que me asignaron y que son bastante simples).
  4. Se esperaba que depurara a través de la aplicación y pidiera ayuda con cosas que no podía descifrar.
  5. Después de que se realizó la corrección, me guiaron por el proceso (revisión de código, pruebas a nivel de desarrollo, etc.) de la liberación a la integración.
  6. Repita para las tareas / errores restantes asignados.

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

  • Esto fue más práctico y relativamente independiente (constante sin agarrar, 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 general, ya que se pueden resolver un par de errores / tareas de baja prioridad. La persona que ayuda a las nuevas personas también tiene más tiempo para ocuparse de las tareas asignadas, ya que no se requiere un control constante y se puede programar el tiempo específicamente para tratar los problemas o problemas que la nueva persona pueda enfrentar.
respondido por el Bhargav Bhat 20.04.2012 - 05:59
1

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 averiguar 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 puedan usar para ayudarlos a internalizar el código base. También ayuda si su ciclo de desarrollo, compromiso y despliegue es corto y pueden ver los frutos de su trabajo en acción lo más rápido posible.

    
respondido por el davidk01 20.04.2012 - 06:12
1

Esto es lo que hago

  1. Indíqueles algunas tareas relacionadas con el proyecto (por ejemplo, si su El proyecto es una aplicación de base de datos. Aplicación para conectar con la base de datos y realizar algunos sencillos. operación.)
  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ícese con los estilos y estándares de codificación
  5. Más adelante, entrégueles algunos ejercicios de depuración (para conocer el flujo del proyecto).
  6. Pídales que corrijan un punto que ya ha solucionado (solo para descubrir su lógica).
  7. Finalmente, hazlos parte del proyecto.

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

respondido por el Shirish11 20.04.2012 - 07:13
1

Número uno: primero aprenda cómo usar el software para descubrir qué problemas resuelve desde la perspectiva del usuario. Si no tiene una UI (por ejemplo, es un servicio backend o algo así), déjalos usar cualquier interfaz que esté disponible para consumirla. Obtener una nueva perspectiva de la vista de un usuario de su software siempre es bueno, y puede ayudar al nuevo empleado a ver cosas que 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 del código base existente. Escribir algo nuevo siempre será más fácil que realizar una corrección de errores, que puede requerir muchos cambios en muchos archivos de origen. En mi opinión, dar a un nuevo empleado una tarea de corrección de errores probablemente los apagará de su empresa.

    
respondido por el dodgy_coder 20.04.2012 - 07:55
1

Su esquema para familiarizar a los nuevos con el proyecto parece razonable. Pero tenga en cuenta que al principio tendrán mucho que aprender. 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 arriesgarás a que no pregunten e intentarán descubrir las cosas por sí solas, lo que quizás sea muy lento, pero a menudo imposible. También tendrán que aprender la jerga. La mayoría de los proyectos de equipos desarrollan su propio lenguaje. Al explicar conscientemente trata de evitar la jerga. Explica esto como lo explicarías a tu madre. De nuevo, se paciente.

Además, puede intentar integrarlos con los otros que ya están en el equipo al intentar algunas tareas de estilo de centro de evaluación, por ejemplo. construye 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.

    
respondido por el scarfridge 20.04.2012 - 09:08
1

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

2) Encuentre algunos pequeños errores o proyectos que son en gran medida independientes de otro código. Explique qué se debe hacer, dónde se encuentra en el código y revíselos regularmente.

3) Comience a darles proyectos cada vez más grandes y más grandes al mismo tiempo que los verifica cada vez menos.

4) Siéntate junto a ellos de vez en cuando. Puedes aprender mucho con solo mirar cómo alguien más aborda un problema. Cosas pequeñas 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 hacer?". Deben buscar primero una respuesta en Google y solo acudir a usted cuando no pueden encontrar una respuesta.

  • Y en 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.

respondido por el Carra 20.04.2012 - 16:19
1

Estos fueron mi fórmula y se usaron con varios recién llegados: estos pasos han demostrado 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 para escribir pruebas de Junit para el código que no tiene suficiente cobertura.

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

d) Asigna tareas complejas y listo.

    
respondido por el java_mouse 20.04.2012 - 15:58
1

Creo que simplemente asigne algunas tareas pequeñas, pídales que escriban algunas pruebas unitarias, que hagan que depuren algunas fallas de regresión. Nada demasiado grande o exigente, pero suficiente para tenerlos en pie.

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

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

    
respondido por el Fanatic23 20.04.2012 - 19:57
0

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

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

    
respondido por el Renato Dinhani 20.04.2012 - 19:35

Lea otras preguntas en las etiquetas