agile - metodologia - pair programming online
¿Cómo lidiar con problemas de programación de pares? (9)
¿Con qué están teniendo problemas exactamente? ¿No se llevan bien, no se comprenden? ¿Están en diferentes niveles de experiencia en programación?
Puede ser útil si tiene un miembro del equipo que puede actuar como un "mediador". Alguien que ha realizado con éxito la programación de pares en el pasado y puede ayudar a los dos durante sus primeras veces juntos.
Algunos miembros del equipo tienen problemas para programar juntos. Diferente género, cultura diferente, edad diferente. ¿Cómo lidiar con esos problemas? - No los emparejes, o - Emparéjalos juntos y déjalos llegar a un "centro dorado"
¿Qué hay de rotar los pares cada semana o cada sprint para que si hay problemas entre un par de ellos no sientan que tiene que ser así para siempre? Creo que si hay un marco de tiempo específico en el que tienes que trabajar con alguien con el que no te llevas, es más fácil "chuparlo" y con suerte no perderás grandes personas de esa manera.
Si después de algunas rotaciones observa que un individuo específico que nadie disfruta puede ser apropiado enfocarse en ajustar la forma en que el individuo interactúa con el equipo o si continúa removiéndolos perpetuamente del equipo.
El primer paso para resolver conflictos es reconocer que las personas son diferentes. Incluso la paciencia más suave del programador puede ser probada en la programación de pares, puede ser muy estresante. Algunas personas se retiran cuando se enfrentan a un conflicto, otras se vuelven agresivas.
La mejor manera de abordar la programación de pares, en mi experiencia, es tener una discusión detallada de qué es lo que quiere lograr para la sesión, antes de poner manos a la obra en el código. Esto pondrá a tus dos mentes en la misma pista. Cuando no está de acuerdo con algo, detenga la codificación, discútalo fuera de la computadora, trate de encontrar puntos en común y, lo que es más importante, no descarte ninguna idea que pueda tener su pareja. Tomar descansos; no trabaje durante 2 horas seguidas, trate de levantarse o haga una pausa cada 45 minutos aproximadamente.
La programación de pares se basa en la idea de que la interacción de dos programadores agrega valor. Si esto no es cierto, cambie los pares ... déjelos elegir. ¡La programación debería ser divertida!
Hable acerca de los problemas de emparejamiento como un grupo y asegúrese de que el grupo conozca las diferentes combinaciones que no funcionan. De esta forma, el grupo puede ayudar a garantizar que sus parejas no se eviten entre sí. Si mantienes separado un par disfuncional, siempre será disfuncional.
Haz que el par abra líneas de comunicación; intenta hacer que ambos lados hagan cosas nuevas. Suponiendo que ambas personas son realmente buenos desarrolladores, ambos tienen mucho que aprender el uno del otro. Intenta cambiar su actitud de maestro a alumno.
Vuelva a evaluar sus prácticas de contratación y asegúrese de seleccionar a los empleados orientados al equipo.
En su defecto, mentas de aliento.
-Adán
Yo cuestionaría la pregunta de muloh: ¿con qué tipo de problemas tienen?
En mi experiencia, estos problemas son a menudo (pero no siempre) un signo de problemas subyacentes con la estructura / habilidades / relaciones del equipo que deben abordarse si se quiere sacar el mejor partido de todos los involucrados.
¿Mary no se lleva bien con Fred porque Fred no sabe lo suficiente acerca de cómo el personal sensato trabaja con las bases de datos? ¿Fred no se lleva bien con Jo porque Jo no se baña tan regularmente como deberían? ¿Jo no se lleva bien con Mary porque Mary es una SOB grosera? Si es así, casi puedes garantizar que Fred, Jo y Mary también molesten al resto del equipo de maneras similares.
Solo porque una o dos personas presionan el tema lo suficiente como para evitar el emparejamiento no significa que los problemas desaparezcan. También puede ser molesto para otras personas, pueden tener formas alternativas de afrontamiento. Como buscar un empleo alternativo, por ejemplo :-)
Si el equipo no funciona bien, no es un equipo.
Por curiosidad, ¿cuánto duran tus sesiones de emparejamiento y con qué frecuencia cambias de pareja? Encuentro que a veces es más fácil lidiar con este tipo de cosas si las personas cambian de pareja regularmente, una o dos veces al día. De esa forma, todos pueden compartir los pros y los contras relativos de todos en el equipo, lo que puede ayudar a que todos se concentren en resolver algunos de los inconvenientes.
Otro enfoque es cambiar continuamente sus pares dentro del scrum. Tener un temporizador que se puede configurar durante 1/2/3 horas. Cuando suene la campana, rota tus pares. Esto tiene algunos efectos:
- Dos personas no se quedan estancadas emparejándose juntas durante mucho tiempo
- Sus desarrolladores rotarán a través de sus historias actuales, familiarizándose con cada una y diferentes áreas del código
- Si uno de los olores de su desarrollador, ¡solo tendrá que atravesar un breve período de hedor!
El emparejamiento es una práctica crítica para un equipo ágil. Para empezar, lo mejor es identificar a los desarrolladores que estén dispuestos y sean capaces de trabajar efectivamente en parejas. Una compañía de la que tengo conocimiento hace entrevistas extremas. Es decir, entrevistarán a los candidatos de dos en dos y les darán un problema para resolver. Les interesa si los desarrolladores son capaces de resolver el problema, pero están interesados en sus habilidades de colaboración. Solo se consideran aquellos que pueden funcionar bien con otros.
No es un requisito que todos se pare el uno al otro. Lo que es importante es que sean efectivos. Dado que los pares giran con frecuencia (para cada tarjeta o con más frecuencia), la personalidad es un problema menor. Si alguien no está en pareja, y después de ser entrenado sigue siendo un problema, se le debe pedir que abandone el equipo.