Desde hace tiempo vengo oyendo hablar sobre el pair programming, sus ventajas y sus implicaciones, pero simplemente no me parecía que esto fuera muy productivo ni que fuera a ayudar tanto de todos modos. A simple vista pair programming se trata de que dos programadores se sienten frente a un monitor continuamente colaborando con un diseño, un algoritmo o cualquier código o prueba.
Cual es el punto? yo he hecho eso muchas veces…
Yo nunca había hecho pair programming teniendo en cuenta que pair programming es un estilo y que es una metodología, y que sobre todo teniendo en cuenta que dos programadores al mismo tiempo no es una redundancia, sino una ruta directa a mayor eficiencia y mejor calidad.
Algunas partes de la metodología
- Comiencen con una tarea bien definida. Cuando los dos se sienten deben tener una tarea correctamente detallada y deben tener la seguridad de que van a poder terminarla en una hora o dos
- Compartan todo. Todo se trata de que los dos programadores funcionen como una sola mente, mientras uno está en el teclado, el otro está revisando todo y dando retroalimentación. Es importante que se intercambien el turno de escribir y revisar para que uno de los dos no se sienta poco importante o fuera del juego.
- Hablen todo lo que sea necesario. Una buena señal es que los dos implicados esten hablando todo el tiempo. Diciendo lo que van a hacer, pidiendo una idea de una inplementación, preguntando la mejor manera de hacer algo, dando soluciones alternativas, etc.
Algunas de las cosas mas comunes que se dicen cuando se esta haciendo pair programming son: Que tu crees de esto? que sigue? confía en mi (cuando una linea de código habla mas que 100 palabras) - No se cojan las cosas muy a pecho. Cuando una persona tiene el ego muy alto tiende a no aceptar criticas de los demas. También el ego excesivo puede atribuirle una actitud defensiva ante las criticas al programador, o puede pensar que los que se le dice es personal y en su contra.
- Suelten el escepticismo. Desarrollen una expectativa de exito. Si uno no espera beneficiarse o disfrutar el proceso es muy difícil que las cosas funcionen correctamente.
- Tomense un momento para celebrar. A medida que se vayan completando las tareas hay que felicitarse, por ejemplo, se resolvio ese problema con la base de datos, chocala!
Conoces algunas otras sugerencias para ayudarnos a hacer mejor pair programming?
Entradas Relacionadas:





Tengo que decir(Por experiencia) que la programacion en pares es lo mejor, ya que entre los dos crecen mas rapido y la complejidad se disminuye sustancialemente.
Unos de los puntos a la hora de programar en pares, es que uno desarrolla la forma a la hora de programar tan sutil a la lectura de cualquier programador que va a ver el codigo por primera vez.
Tambien unas de las ventajas de programar en pares es que a la hora de desarrollar junto llega a entender que el codigo que tira uno es identico a la forma de tirar el otro y hasta podria confundir quien fue que hizo x clase. (Esto quiere decir que es como ser una gente con 4 manos.)
… O con dos mentes?
Lo sorprendente es que no hayan más managers y jefes de proyectos que crean en este tipo de formas de trabajo.
Desde mi perspectiva, la programación de a pares es la práctica más importante y dificil de XP. No tanto por los beneficios técnicos que genera, sino por el cambio cultural de fondo al que apunta: la programación de a pares es la base central de una cultura colaborativa, donde las personas se sientan libres de compartir lo que conocen y preguntar lo que quieran aprender.
Muy buen artículo, breve y preciso. Muchsa gracias por compartir!
Hola Leito, gracias por venir y gracias por el enlace
Es como dices acerca de compartir conocimientos y la cultura colaborativa. Al mismo tiempo que se logran objetivos desde el punto de vista revisado de dos programadores, Ambos programadores comparten conocimientos y costumbres entre si, que al final fortalecen las costumbres y practicas del equipo.
hay que recalcar también el test-driven develpment, base de esta sentada en pares…
Genial lo del pair programming.. pero… ¿cómo aplicarlo en un entorno de trabajo donde la separación de puestos no existe? En muchas oficinas las instalaciones son diáfanas.
¿Cómo mantener a dos desarrolladores hablando constantemente sin molestar e interrumpir la concentración del resto del equipo de trabajo?
¿Dejamos que los decibelios suban con varios grupos de desarrolladores en pair programming?
Un escéptico intentando reciclarse….
Hola Juan,
Para adoptar pair programming o cualquier metodología de desarrollo ágil, el compromiso debe tomarlo la compañía en cuestión y deben estar de acuerdo con que este tipo de cosas van a estar sucediendo.
No en todos los ambientes de trabajo se puede hacer pair programming.