Programación de a pares: consejos útiles

estrellaEn el primer artículo de esta serie vimos una introducción a la Programación de a Pares, una de las prácticas más conocidas (¡y difíciles!) de Extreme Programming. En el segundo artículo exploramos más en detalle los roles de conductor y navegante, y la relación entre ambos.

En esta continuación, James Shore nos resume un interesante listado de consejos y desafíos que deberemos superar para implementar con éxito esta práctica de desarrollo de software.

Consejos generales

  • Hacer programación de a pares en cualquier cosa que necesitemos mantener.
  • Permitir que las parejas se formen de manera fluida, en vez de asignar compañeros.
  • Cambiar de compañero cuando se necesite una nueva perspectiva.
  • Evitar estar con la misma pareja por más de 1 día seguido.
  • Sentarse de manera cómoda, lado a lado.
  • Producir código a través de la conversación. Colaborar, no criticar.
  • Cambiar los roles de conductor y navegante con frecuencia.

Puesto de trabajo

Para disfrutar la programación de a pares es esencial contar con puestos de trabajo apropiados. Necesitaremos suficiente espacio para que dos personas puedan sentarse cómodas, lado a lado. Los cubículos clásicos, con la computadora ubicada en una esquina, no sirven. Son incómodos y obligan a que una persona se siente detrás de la otra, lo que agrega una barrera física y psicológica que se interpone en la colaboración.

No se necesitan muebles complejos o costosos para crear buenos puestos de trabajo; los mejores son simples mesas planas que se encuentran en cualquier lugar de amoblamiento para oficinas. Deberían tener al menos 1,8 metros de largo, de manera que dos personas puedan sentarse lado a lado con comodidad, y de al menos 1,2 metros de profundidad. Cada mesa necesita una computadora potente para trabajar. A muchos les gusta enchufar dos teclados y dos ratones, para que cada persona tenga el suyo.

Se debe invertir en monitores grandes para que ambas personas puedan ver claramente.

Desafíos

Vale la pena recordarlo: la programación de a pares no es divertida si no están cómodos. Cuando se sientan en pareja, ajusten su posición y el equipamiento para que puedan sentarse con comodidad. Despejen el escritorio, y hagan lugar para sus piernas, pies, rodillas.

Comodidad

Algunas personas necesitan mucho espacio personal. Otras prefieren estar más cerca. Cuando comiencen con su pareja, discutan el espacio personal que necesitan con su compañero.

De manera similar, y aunque es obvio que la higiene personal es crítica, debemos recordar que algunas comidas con sabores fuertes pueden producir mal aliento, como el café, ajo, cebollas y otras comidas especiadas. Decidan como equipo, antes de que surja el tema, cómo notificar a las personas de manera respetuosa sobre estos hábitos.

Habilidades dispares

Trabajar en parejas significa colaborar entre los pares; a veces un desarrollador senior se encuentra en pareja con un junior. En vez de tratar la ocasión como situciones de estudiante/maestro, podemos re-establecer el balance creando oportunidades para que ambos participantes aprendan. Por ejemplo, si vamos a estar junto a un desarrollador junior, le podemos pedir que investigue algún tema que nadie más sepa, como el funcioamiento interno de alguna librería que el equipo use. Todos pueden tener la oportunidad de ser expertos.

Estilos de comunicación

[inset side="right" title="Consejo"]El Desarrollo Guiado por Pruebas (TDD) es un buen aliado para las parejas ping-pong.[/inset]

A los nuevos conductores a menudo les resulta dificil involucrar a sus compañeros; pueden acaparar el teclado y cerrar toda comunicación. Para lograr buena comunicación y cambiar de roles cuando se trabaja de a pares, pueden considerar las parejas ping-pong. En este ejercicio, una persona escribe una prueba. La otra persona la hace pasar, y escribe una nueva prueba. Luego la primer persona la hace pasar y repite el proceso escribiendo una nueva prueba.

La otra cara de "poca comunicación" es "demasiada comunicación" - o mejor dicho, demasiada comunicación inútil. Es valiosa la crítica honesta del código y del diseño, pero al principio puede ser difícil de apreciar. Las personas tienen distintos grados de tolerancia, por lo cual debemos prestar atención a cómo nuestro compañero recibe los comentarios. Podemos intentar cambiar las declaraciones (como "ese método es muy largo") en preguntas o sugerencias ("¿podríamos hacer que este método sea más chico? o "¿deberíamos extraer ese código a un método nuevo?"). Debemos adoptar una actitud colaborativa para resolver problemas.

Traducido de The art of agile development: Pair Programming, por James Shore.
Compartir
  • No se han encontrado comentarios

Deja tus comentarios

Post comment as a guest

0

El nuevo Dos Ideas.

Nuevo logo, nuevo buscador, nueva portada, podcast mensual... ¡y muchas novedades más!

Más novedades en Dos Ideas

Los Comentarios.

manny
muy interesante todo los que se escribió aquí.
Alejandro Cortes
"Si hubiera que definir la arquitectura en pocas palabras, se diría que es la ponderadora creación d...
alex
hey no me dieron el resultado que esperaba xD
JSP
Hola, soy nuevo en esto de java y no consigo hacer funcionar los ejemplos. ¿Podrías poner el código...
silvia
Muy bueno Gracias por compartirlo! exelente!

Inspiración.

"Si tú tienes una manzana y yo tengo una manzana e intercambiamos las manzanas, entonces tanto tú como yo seguiremos teniendo una manzana cada uno. Pero si tú tienes una idea y yo tengo una idea, e intercambiamos las ideas, entonces ambos tendremos dos ideas"

Bernard Shaw