Intercambio de parejas: ¿cuáles son los pros y los contras?

La idea general que propugnan la mayoría de los teóricos de Agile / XP parece ser que los pares deberían intercambiarse regularmente. Por ejemplo, cada programador debe intercambiar pares una vez al día; la mitad de las personas intercambian al comienzo del día, la mitad de las personas intercambian después del almuerzo: debido a factores externos como reuniones, días festivos y similares, la mayoría de las personas tenderán a cambiar sus tiempos de intercambio una o dos veces por semana para que las configuraciones de par se distribuyan bastante uniforme en todo el equipo.

Una razón detrás del intercambio frecuente es que el conocimiento se difunde entre el equipo de manera rápida y uniforme, en lugar de tener habilidades y conocimientos específicos que se concentran en individuos particulares, lo que implica que el trabajo puede continuar sin problemas si las personas están lejos o abandonan la empresa. Otro razonamiento, que es una especie de corolario del dogma que rodea a la programación de pares en sí, es que cada vez que alguien intercambia información sobre usted obtiene una nueva revisión de código por un par de ojos nuevos, por lo que solo puede mejorar la calidad del código.

Ambas afirmaciones suenan razonables; desde el punto de vista de la administración, parece que obtienes un aumento tanto en la estabilidad como en la calidad, y como tal el intercambio frecuente es una teoría estándar en la mayoría de los libros de Agile / XP que he visto.

Entonces, cuando realmente se pone en práctica, ¿qué piensan las personas sobre el intercambio de parejas?

¿El punto de vista de un programador?
¿El punto de vista de un gerente?

¿Qué debería determinar cuándo alguien cambia de / a un par?

agile pair-programming

¿Es esto lo mismo que "Programación de pares"?

— Robert Harvey

@Robert Harvey - Bueno, es un aspecto de la programación de pares. Una vez que un equipo decide que van a programar en parejas (durante una parte de su jornada laboral), deben decidir cómo organizar a los programadores en parejas, es decir, cuándo un programador debe dejar un par (otro debe unirse al mismo tiempo ) Eso es "Intercambio de pares".

+1 para la gran pregunta. Lamentablemente, creo que es bastante difícil encontrar una tienda que haga el emparejamiento de forma regular, y mucho menos tener datos sobre el intercambio de pares. Espero estar equivocado sobre esto y obtenga algunas buenas respuestas, estoy muy interesado en escuchar algunas.

— Jesse McCulloch

Personalmente, me parece que el intercambio de pares distrae mucho. Intentar lidiar con tantas personalidades y niveles de habilidad diferentes en lugares tan cercanos produciría demasiada disonancia cognitiva.

— Robert Harvey

@Jesse McCulloch: trabajo en un lugar que solo empareja programas e intercambia más o menos como dicen los libros que debería hacer un equipo. También he trabajado en un entorno puro solo, por lo que tengo una perspectiva bastante buena sobre el contraste. Sin embargo, me gustaría escuchar las opiniones de otras personas, ya que me gustaría ver si coinciden con las mías sin influir demasiado en ellas.

Respuestas:

La programación en pareja es difícil.

Es difícil porque funciona mejor cuando las 2 personas involucradas tienen un nivel de habilidad cercano y eso puede ser difícil en algunos entornos de trabajo. Puede ser más difícil cuando cambias porque necesitas encontrar a otra persona con el nivel de habilidad adecuado y luego ponerlos al día sobre el problema actual. El beneficio es que más personas están expuestas a cualquier código dado que haya sido emparejado. Esto debería llevar menos veces en que el código no se pueda arreglar porque nadie sabe lo suficiente sobre él. También debe propagar la propiedad del grupo y la capacidad de cualquiera de recoger cualquier trabajo.

He descubierto que incluso en entornos donde se realiza el emparejamiento, el intercambio de pares no vale la pena. Sin embargo, esto puede deberse a que nuestras tareas nunca demoran más de ~ 1.5 días. Encontramos un gran beneficio al desglosar las tareas para que no sea más grande que ~ 1.5 días de trabajo. El intercambio de pares puede tener más sentido en el contexto de tareas más largas.

— dietbuddha
fuente

Personalmente, disfruto emparejarme con personas de todos los niveles. A veces estoy aprendiendo, a veces estoy enseñando, y a veces solo estamos haciendo cosas. Pero el aprendizaje y la enseñanza crean capacidad de equipo a largo plazo, lo que creo que es tan importante como marcar las características.

— William Pietri

Puede pensar que sí, pero el gerente de proyecto que ve que su fecha límite se evapora a medida que su experiencia se acostumbra a capacitar a las personas en su tiempo en lugar de producir código tan rápido como pueda, no estaría de acuerdo. Y esa es la forma en que operan la mayoría de los proyectos, simplemente no hay tiempo para capacitar a las personas para que tengan las habilidades necesarias para hacer el trabajo, por lo que los jóvenes se quedan colgando, solo para tomar la culpa de los excesos presupuestarios.

— Jwenting

@William Pietri: En mi experiencia, el emparejamiento no es un buen formato para la enseñanza. No tengo ningún problema para llevar a alguien y guiarlo a través del código para explicarles lo que está sucediendo. Sin embargo, eso no es programación de pares.

— dietbuddha

@jwenting: Si usted dice que la programación de pares no funcionará bien en tiendas que se centran en plazos de mierda sobre la calidad y la sostenibilidad, no lo discutiría. Mi consejo: trabaja en un lugar que no sea una locura.

— William Pietri

@dietbuddha: ¡Funciona para mí! La forma más rápida de aprender un nuevo idioma, marco o biblioteca es emparejarme con personas que lo conocen bien. Y no conozco una mejor manera de poner al día a un novato que el emparejamiento. Por ejemplo, esta versión de

— William Pietri

Soy tanto programador como gerente. Aquí está mi opinión:

El intercambio regular es genial. Estoy a favor de cambiar de 2 a 4 veces por día, que es casi tan rápido como creo que puedes ir. Para nosotros, eso viene en puntos de ruptura naturales: generalmente almuerzo y media tarde. Cambiar todos los días o dos probablemente esté bien, pero me preocuparía ir mucho más tiempo que eso. (He oído hablar de un lugar que cambia cada seis semanas, lo que creo que es una locura; después de tanto tiempo juntos, estarían listos para apuñalar a un santo).

Como programador, me encanta porque obtengo nuevas perspectivas, puedo ver otras áreas del código y puedo seguir o pasar de algo como prefiera. Recientemente, pasé de la codificación en solitario al emparejamiento, y estoy emocionado: aprendo más, me divierto más y hago más.

Como gerente, creo que es genial porque resuelve muchos problemas de factor de camión y cuello de botella. Por ejemplo, este fin de semana me tomaré un largo fin de semana para la boda de un amigo, y no me preocupa en absoluto: todo lo que he trabajado también ha sido trabajado por otras personas. También creo que realmente ayuda a los miembros del equipo a apreciar las fortalezas y debilidades de los demás, y a fomentar la propiedad del código colectivo.

En cuanto a quién se queda con el trabajo actual, siento que depende principalmente de las personas involucradas. A veces quieres ver algo, y a veces estás listo para un cambio. A veces también intercambiamos para aportar experiencia, o para que alguien pueda aprender algo que le interesa. Intentamos mantener nuestras unidades de trabajo bastante pequeñas (0.5-2.0 pares de días), por lo que no es un gran problema, sin embargo, el intercambio continúa .

— William Pietri
fuente

Para mí, tengo que decir que cambiar solo es bueno cuando a) No disfruto codificar con el tipo con el que estoy codificando, b) No me gusta la historia en la que estoy trabajando (como arreglar una cuerda) viejo error de memoria). De lo contrario, quiero quedarme de principio a fin. Personalmente, creo que el intercambio de pares reduce la calidad del código porque un buen código debe tener una única visión clara, mientras más personas trabajen en una sola parte, más desordenada se vuelve esa visión. En cuanto al intercambio de conocimientos, diría que la mayoría de las personas tiene una idea de lo que está sucediendo, pero nadie realmente entiende nada.

@B Tyler: creo que una base de código es un trabajo intelectual conjunto, por lo que debe tener una visión clara que también sea una visión común. Esa es parte de por qué creo que es importante intercambiar: se necesita mucha interacción y discusión para desarrollar un enfoque compartido sólido.

— William Pietri

Okie, aquí va la respuesta de un autoproclamado programador pragmático ágil / xp. Llevo más de dos años programando en pareja. Si la programación de pares es buena, intercambie pares con frecuencia (idealmente cada dos horas, si no cada medio día). En la ubicación de nuestra oficina, hacemos un punto para intercambiar pares todos los días (generalmente) o cada dos días (en el peor de los casos). Hacer esto en sí mismo podría darnos mucha confianza en la calidad del código que comprometemos y en los aprendizajes o eliminaciones que tenemos con cada rotación de pares (sabemos que la revisión del código es buena, cuanto más mejor y más pronto mejor. Esto es lo que logra la "programación de pares, incluida la práctica de intercambio de pares" ).

¿Por qué no cambiamos pares cada dos / cuatro horas? Bueno, en realidad he estado en equipos que también practican esto. Ciertamente es mucho más fresco y más productivo. Pero aquí está el trato, el intervalo de tiempo de intercambio de pares no debería ser una regla, debería suceder por sí solo; solo entonces el gerente o la empresa pueden ver sus beneficios.

He sido testigo y experimentado esto. Ahora soy su evangelista. No es una teoría. Más bien es completamente pragmático :) Feliz emparejamiento de ping-pong e intercambio de parejas.

— karthiks
fuente

Por desgracia, ahora estoy totalmente convertido en la opinión de que la programación de pares es en general una mala idea; El intercambio frecuente de pares en la programación de pares solo empeora las cosas. Escuché toda la teoría y la probé mucho en la práctica, y creo que es increíblemente ineficiente, mucho más aburrida y frustrante que la programación en solitario y da como resultado un código de menor calidad.