He recordado escribir este post por que Ms NoBody se pasa muchas tardes trabajando en modo pair programming. Y porque comparto tiempo, alegrías, penas y esperanza, con unos cuantos equipos en los que, en estos meses, varios Mr. NoBody han visto (en modo auto-organización + retrospectiva, bien por ellos) que el pair programming sería una buena práctica para mejorar la calidad del código y para formar a nuevos miembros del equipo.
El pair programming, dos programadores que trabajan juntos en un solo ordenador, es una práctica muy muy antigua (en el blog hay un post de hace 7 años sobre el tema, ¿Beneficios del pair programming? ¿Dos programadores en un solo ordenador es perder medio equipo?), muy popularizada por eXtream Programming.
Y también es una de las prácticas más polémicas, esa que a los «jefes» nunca les termina de encajar… «¿dos personas por ordenador? ¿eso es la mitad de trabajo?» (el efecto mítico hombre-mes, ya sabes).
Pero, de entre los muchos temas que el pair programing daría para hablar, el post de hoy es una reflexión de… ¿cuándo hacer uso del pair programming? ¿siempre? ¿para todo?
Más allá de las experiencias que tengamos cada uno, he estado revisando también que se dice por ahí, que se ha escrito, que se ha investigado, que, típicamente, se recomienda, etc. Con la idea de hacer un post lo más objetivo posible. Y te dejo algunas conclusiones sobre las que hay bastante consenso…
- Los experimentos indican que, al usar pair programming, no se muestran grandes mejoras si se trabaja en tareas simples. Esto, que puede ser obvio, o no (hazme caso que no lo es), implicaría algo (que también puede parecer obvio), como que no es recomendable hacer pair programming el 100% del tiempo.
- Los experimentos indican que, usar pair programming, muestra grandes mejoras si se trabaja en una pareja con, aproximadamente, el mismo nivel de experiencia. Ciertamente, hay un uso del pair que es la formación, que alguien nuevo aprenda de alguien senior, pero el beneficio esperado aquí no es velocidad, calidad, etc., sino… formar a otra persona. Por ello, aunque parezca obvio, el pair programming por formación podría bajar la velocidad y, por ello, debería no exceder más allá de lo necesario.
- Los experimentos indican que, usar pair programming, muestra grandes mejoras si los roles rotan regularmente, porque rotar regularmente ayuda a mantener un mayor nivel de compromiso, a transferir conocimiento, etc.
Sería muy interesante que compartieras, en un comentario a este post, tus experiencias sobre cuándo, cuánto, pair programming.
Si quieres meterte más en el tema, hay un montón de referencias, pero para que no te pierdas, yo te recomiendo la de Laurie Williams y la de Nosek.
- Diario: cómo Javier Garzás evita quedarse obsoleto estudiando a un X10 con IA-Esteroides - 7 noviembre, 2024
- Si creas Historias de Usuario con IA ¿A quién pertenecen? ¿A ti o la IA? El mono Naruto te lo explica - 31 octubre, 2024
- HistorIAs de usuario y como a Maximiliano lo ENGAÑABAN con la IA y como una viejuna historia del 1500 le salvó - 24 octubre, 2024
La técnica de que parejas de personas trabajen juntas creo que no sólo aplica a la programación, sino a cualquier actividad que implique una actuación que surja tras un proceso cognitivo (pensar y decidir). En uno de mis equipos de trabajo, hace unos 15 años, tuve a dos hermanas que trabajaban en temas de obtención de datos para pruebas y siempre trabajaban juntas. Yo al principio no lo entendía, pero cuando lo analice un poco más en detalle, pude comprobar que eran súper efectivas en lo que hacían. Se complementaban muy bien, porque una tenía un perfil más técnico y la otra más funcional, pero siempre lo hacían juntas y era muy curioso verlo. Y llamaba la atención por los temas que cuentas en el post, de hecho mi jefe entonces nunca lo entendió y me pidió que las separara, pero afortunadamente no lo hice y creo que acerté. Pero lo más curioso de todo es que cuando les pregunté cómo empezaron a trabajar así (yo ya había leído bastante de XP y vi cierto paralelismo con el «Pair Programming»), me dijeron que se les había ocurrido a ellas después de mucho tiempo trabajando juntas en proyectos.
Gracias Mariano, muy interesante la experiencia
En mi último trabajo hemos estado aplicando esta técnica y en lo personal no me gustaría pasar por lo mismo. Las continuas rotaciones son un dolor de cabeza, nunca terminas nada nunca sabes nada, es una desgracia. Dependes del nivel de conocimiento de tu compañero a la vez del carácter, personas dominantes, personas que no escuchan, con ego subido, etc. Todas las posibles combinaciones de la psique del ser humano. La teoría muy bonita la realidad tienes que encontrar a tu alma gemela, si es que existe.
En el único caso que yo lo aplicaría sería en el caso de la formación de nuevos componentes en el equipo.
La productividad ni mencionarla, tiende a cero.
Mi primera pregunta para mi próximo trabajo ¿hacéis pairing?, ¡¡no gracias!!
En mi experiencia, en los escenarios donde el desarrollo va «rodado» es perder prácticamente la mitad de la capacidad, sin embargo en los escenarios de alta incertidumbre tecnológica es una ventaja, donde el equipo suele obtener un resultado superior a la suma de las partes.
Yo solo puedo hablar de dos casos que conozco:
1.Para formar. Ahora en remote full me parece maravilloso. Compartir pantalla, ceder el control a la persona que está aprendiendo… Nos hace avanzar más rápido.
2.Para resolver incidencias que se nos atascan. Porque 4 ojos ven más que 2 y 2 mentes piensan más que 1. Y al final la incidencia se resuelve más rápido, que es el objetivo.