Una de las ventajas que poseen los equipos ágiles es que llevar a los miembros nuevos a producir bien, puede ocurrir de una forma más natural y eficiente que cuando las personas están trabajando en un mundo rígido estilo cascada. Esto es especialmente cierto si el equipo está co-localizado, con comunicación frecuente y eficiente, trabajando en pequeños incrementos de historias, y especialmente cuando se utiliza programación de a pares.
En un reciente artículo, Anand Vishwanath concuerda con esto, declarando que para la mayoría de los proyectos medianos y pequeños, los nuevos miembros pueden integrarse a un equipo ágil, sin mucha ceremonia, mas allá que para los grandes proyectos se requiera algo más. Sugiere que para los grandes proyectos usar una simulación en "menor escala" puede ser el mejor enfoque para introducir un novato en el equipo. En pocas palabras, "mantener un grupo de 4 a 6 novatos en el lote de integración" y hacer que ellos ejecuten algunas mini-iteraciones durante 1 a 2 semanas con la ayuda de los mentores más experimentados.
Vishwanath dice que el componente más importante del proceso de integración es la presencia de mentores en condiciones de orientar a los recién llegados durante la simulación. Él dice que entre los mentores deben estar:
- Un Mentor Desarrollador, un desarrollador que es "experto" capaz de ayudar a los principiantes a entender la base del código y el dominio del proyecto. Esta persona trabajará a tiempo completo en la simulación, haciendo par con los novatos y conduciendo debates de aprendizaje.
- Un Mentor Analista de Negocios, trabajando a tiempo parcial en la simulación para actuar como el cliente para desarrolladores, así como conducir analistas principiantes si es que existen.
- Un Mentor Analista de Calidad, también trabajando a tiempo parcial para ayudar en las actividades relacionadas con el aprendizaje y la relación con la calidad del software.
Vishwanath explica cómo esa simulación funcionará como una iteración actual (o incluso más de una), incluyendo una reunión de planificación de la iteración, demostración del fin de una iteración y retrospectiva y cualquier otra etapa que su proyecto aplique y sea posible.
Vishwanath indica que hay que presentarle al grupo una variedad de historias en la iteración simulada. Por ejemplo, sugiere incluir algunas historias funcionales simples y también guardar espacio para almacenar algunas "historias de refactorización", que son de totalmente técnicas por su naturaleza para dar a los novatos una buena oportunidad de interiorizarse en el código y en la arquitectura del proyecto.
Vishwanath también da algunos consejos sobre como recolectar los artefactos de la simulación que pueden utilizados en futuras simulaciones. Por ejemplo, señala que se pueden grabar vídeos de las sesiones de simulación, así como aprendizajes destacados en las retrospectivas.
Si este resumen te parece interesante, podes ojear el artículo de Vishwanath. ¿Te parece un buen enfoque? Conociendo tu ambiente, ¿lo podrías hacer? ¿Tenes algo parecido? En caso afirmativo, ¿cuál es el resultado?