Onboarding proceso de integración para un nuevo integrante

Estimados, me gustaría compartir con ustedes una presentación de Onboarding “proceso de integración para un nuevo integrante”, de Pamela Canchanya, en la cuál se platean ideas para integrar de forma ágil a nuevos integrantes, en particular he utilizados algunas técnicas como la configuración one click y el checklist de conocimientos necesarios que debe adquirir un nuevo integrante, los cuales han ayudado mucho a acelerar el proceso de adaptación y la integración del equipo.

Acá la presentación.
http://www.slideshare.net/PamelaCanchanya/strategias-onboardingequipos<img

Acá una foto del checklist que utilizamos, la idea es que en un transcurso determinado de tiempo los nuevos integrantes adquieran una serie de características, el encargado de que esto se logré es todo el equipo.

2 Me gusta

Gracias, está buenísimo el tema del onboarding, especialmente eso del code review y del pair programming…

Pero… he tenido malas experiencias con empresas que hacen code review… pero sin code conventions… o sea, cambia el nombre de la variable… y te proponen un nombre peor… y tienes que pasar 3 code reviews para hacer un sólo commit… y los 3 tipos no se ponen de acuerdo…

Otra cosa que no me gustó de la presentación, aunque está buenísima en un 96,9%… ¿se le enseña al desarrollador a hacer deployment a producción? ¿No es automatizado? ¿O sea que puedo hacer deployment a producción desde mi máquina y ese código ni siquiera está en el servidor Hg?

Otro problema: ¿ocupan arquitecturas orientadas a servicios y ni siquiera tienen un registro de los servicios que existen? ¿A nadie se le ocurre utilizar un wiki para eso?

Para mi gusto y según mi experiencia, es mucho más fácil hacer onboarding usando “prototipos”. Por ejemplo “escribe una wiki” como prototipo. Eso puede sonar tonto, pero supongamos que estamos en un proyecto que requiere de una wiki… ¿escribes esa wiki directo en el proyecto? ¿O la metes primero en un prototipo? ¿Qué pasa si luego te das cuenta que está mal?

Porque el nivel de maldad puede ser:

  1. Defecto de requerimiento.
  2. Defecto de diseño.
  3. Defecto de código.

Cada nivel de maldad se debe manejar de manera diferente. Tener el código con interdependencias es super mala idea. Pero si lo ponemos en un prototipo aparte es imposible que haya interdependencias…

Así el programador aprende de las pruebas unitarias, del code review, de los code conventions, todo en un ambiente controlado y lejos de la presión del proyecto.

En mi experiencia los desarrolladores aprenden mucho más con los prototipos y pueden contruir hasta 3 prototipos antes de incorporarse plenamente al proyecto, lo que permite enseñarles todas las prácticas en 1 o 2 semanas dependiendo de la complejidad de los prototipos, y haciendo que se familiaricen con el control de versiones, con Jenkins, etc.

Además que parender TDD no se peude aprender en un día, o por lo menos esa ha sido mi experiencia.

Hola Guillermo,

Lo que planteaba Pamela con respecto al deployment a producción el primer día, hace referencia que dentro del proyecto se genere una planilla con los integrantes del grupo y que esta se encuentre en ambiente productivo, la idea es que la persona el primer día haga su deployment a producción para tener contexto de que significa, punto aparte es que no todas las empresas tienen automatizado hasta ambiente productivo, por ejemplo de uno de los lugares donde trabajo la automatización solo existe hasta ambiente beta (Deployment automático, PMD, instalación componentes, etc…).
Saludos,
Roberto Mejias.