Ya hace algún tiempo que la programación de a pares se convirtió en una realidad de mi día a día, confieso que en mis primeros contactos con Extreme Programming (XP) esa era la práctica que menos me gustaba, pero luego de involucrarme más con las prácticas ágiles comencé a darme cuenta de sus beneficios, e incluso empezacé a propagar la idea, pero ahora, que sentí más estrechamente como realmente funciona y me gustaría compartir un poco de lo vengo aprendiendo.

¿Qué es la programación en parejas?

La programación en pareja es una técnica que sugiere que todo el código producido en un proyecto de desarrollo de software sea implementado por dos personas juntas, delante de la misma computadora, las personas se turnan en el teclado[1]. A la persona que está con las manos en el teclado se lo llama conductor y a la otra navegador.

¿Por qué programar de a pares?

"Unirse es un buen comienzo, mantener la unión es un progreso y trabajar juntos es la victoria". (Henry Ford)

Centrarse en el trabajo

Tenemos el mundo entero de información y los recursos para llegar a unos pocos clics. Internet, el correo electrónico, lector de feeds, son la tentación todo el tiempo para entretenernos, y perder el foco de nuestro principal objetivo: escribir código. La programación de a pares nos ayuda a mantener el foco, después de todo, tenemos a alguien sentado junto a nosotros y está interesado en ver el problema resuelto, por lo tanto, con seguridad, aunque estemos tentados igualmente, trataremos de evitar hacer otra cosa que centrar nuestras energías en resolver el problema. Eso no significa que está prohibido consultar algo en Internet, o leer mensajes de correo electrónico, por ejemplo, siempre tenemos algunas máquinas disponibles para ese tipo de cosas, sin embargo, puedo asegurar que la frecuencia de esa actividad es mucho menor cuando trabajo en parejas, y no son las únicas distracciones son reducidos, de acuerdo con Laurie Williams [3], las personas que trabajan en pareja son menos interrumpidas por otros qie cuando se trabaja solo.

Enseñar y Aprender

"El aprendizaje es la única cosa que la mente se cansa nunca, nunca tiene miedo, y nunca se arrepiente." (Leonardo da Vinci)

Todos somos diferentes, pensamos de forma diferente y sabemos cosas diferentes, programando en parejas esas diferencias pueden ser complementadas de una manera positiva llevando mas calidad al trabajo y mucho aprendizaje a los involucrados, no sólo conocimientos técnicos, sino también mucho conocimiento sobre el dominio del negocio son intercambiados todo el tiempo.

Destruyendo las islas del conocimiento

"Uhmmm ..., este problema es sólo con ese tipo, él es quien desarrollo y ha mantenido eso previamente, nointentes porque nadie mas va a conseguir resolver eso."

¿Quién nunca oyó algo así? Yo sí, y con frecuencia. Es común, especialmente en contextos en los que no se aplican metodologías ágiles, existen islas de conocimiento, estas islas solo representan el conocimiento retenido por las personas, que a menudo por falta de oportunidades, y otras por pensar que con esto se convertiran en insuustituibles, algo que hoy podemos decir que es tonto.

Las islas de conocimientos pueden convertirse en un gran problema, porque el mantenimiento del software depende en gran medida de la persona que conserva el conocimiento, y esa persona podrá en cualquier momento salir de la empresa, permanecer de vacaciones, viajar, etc ... Mas y cuando ocurre un problema crítico y la persona no está presente? El gran problema es que todo está en función de la isla.

La programación en parejas fomenta y estimula el intercambio de conocimientos, hace que todo el equipo comparta el código y sepa un poco de todo lo que se ha desarrollado, por lo tanto, todo el equipo es capaz de resolver cualquier problema en cualquier momento, si un miembro de equipo está ausente, probablemente no habrá poblemas por eso.

Más disciplina = Más calidad = Menos errores

La programación en pareja aumenta la calidad del software sin que ello repercuta significativamente en el plazo [2]. A pesar de estar en contra sentido que dos personas que trabajan en una sola computadora puedan producir más valor que trabajando por separado, sin duda es fácil creer que van a entregar un trabajo de mucho mejor calidad, y esta calidad adicional, por sí sola, traerá grandes beneficios posteriores.

Laurie Williams, de la Universidad de Utah en Salt Lake City puso de manifiesto que la programación es parejas es, en promedio, sólo el 15% más lento que la programación individual, pero produce 15% menos de errores [5]. Considerando que la prueba y depuración en la mayoría de veces es más costosa que la programación inicial, este es un resultado como mínimo significativo.

Según Vinícus Teles, "la persona que está dirigiendo el teclado (conductor) tiene un campo de observación diferente al de su pareja. Quien digita normalmente está observando sobre todo la línea que está editando y sus adyacencias. El navegador, a su vez, tiene una visión más amplia y no sólo mira la línea que se está editando, sino el resto del código que aparece en la pantalla. De esta manera, se termina con una visión complementaria que, a menudo, pone de manifiesto los problemas que el conductor no percibe con la misma rapidez [1], por lo tanto, el código se está revisando todo el tiempo, sin contar que programar en pareja impide caiamos en la tentación de no escribir pruebas unitarias o dejar refactorings de lado [4].

Consejos

Ping-pong de programación (P3)

Programación de Ping-pong [12] es una técnica que une programación en parejas y TDD, tornando la programación en parejas más divertida [13], dinámica e interactiva, y consta de los siguientes pasos:

  1. El programador A escribe un nuevo test y lo deja fallando.
  2. El programador B implementa el código necesario para hacer pasar el test.
  3. El programador B escribe el siguiente test.
  4. El programador A implementa el código necesario para hacer que pase el test.
  5. El proceso se repite.

Pausas

Pare! Tome un café. Coma algo. Converse con otras personas ademas que con su par [7]. Todo esto será bueno para que descanse un poco, se distraiga y se prepare para regresar más dispuesto a continuar la tarea.

Cuidado con las largas discusiones

Establezca un time-box para los debates. Es común que dos desarrolladores no acuerden al intentar decidir la mejor manera de implementar algo, cuando esto sucede, procure oír las razones de la otra persona y presentar sus argumentos, tratando de llegar a un término medio, en caso de que no sea posible, llame a una tercera persona para que dé su opinión. No se resista en ceder cuando se da cuenta de que el otro puede tener razón, acuérdense de que ud. está aprendiendo y enseñando todo el tiempo, no hay ningún problema en estar errado de vez en cuando.

No se engañe!

Mito: Sin programación en parejas, no hay Agilidad

Martin Fowler, uno de los más respetados en el mundo del desarrollo de software en 2006 escribió un artículo levantando algunos de los principales errores en la programación en parejas. Fowler explica en su artículo que "no es necesario programar en parejas para estar
prácticando la agilidad" [11], ni siquiera para decir que usted aplica Extreme Programming está obligado a programar en parejas, lo máximo que se puede decir es si alguien quiere aprender XP debería tratar de programar en parejas y ver si funciona bien en su caso en particular [11]. La programación en parejas no está mencionada en el manifiesto ágil, sin embargo, es una práctica muy recomendable para lograr los principios ágiles.

Mito: La productividad se reducirá a la mitad

Otro error muy común es pensar que la productividad de los desarrolladores se reducirá a la mitad, como se ha discutido anteriormente, en la mayoría de los casos esta afirmación es falsa.

Mito: Estoy seguro de que no me va a gustar programar en parejas

Según Fowler, muchas personas se sorprenden y comienzan a disfrutar de la programación en parejas, en particular después de intentar, por lo que pruebe antes de decir no de gusto!

Conclusión

Concluyo con una cita de Mary y Tom Poppendieck en el libro "Implementing Lean Software Development":

Programación en parejas no es para todos o para todas las situaciones, sin embargo, la programación en parejas crea sinergia:

Dos personas van a entregarfrequentemente un código más integrado, probado y sin defectos, trabajando juntas [...]. La programación en pareja es una de las mejores maneras de atigir los beneficios de las revisiones de código [...].

Referencias

[1] Improvit - Programação em Par
[2] Extreme Programming Rules - Pair Programming
[3] Williams, Laurie (2003). Pair Programming Illuminated, Addison-Wesley
[4] Beck, Kent (2000). Extreme Programming Explained, Addison-Wesley
[5] Cunningham & Cunningham - PairProgramming
[6] Mark Needham - Pair Programming: What works for me
[7] Brian Guthrie - The Way I Pair
[8] thekua.com@work - How I like to pair
[9] InfoQ - Pair Programming Debate
[10] InfoQ - Common misconceptions about paired programming
[11] Martin Fowler - Pair Programming Misconceptions
[12] Pair Programming Ping Pong Pattern
[13] Ping Pong Pairing: Even More Fun!
[14] Poppendieck, Tom and Mary (2007). Implementing Lean Software Development, Addison-Wesley

Traducción libre de Programação em Par

Seguinos en Facebook.

Publicá tus artículos.

Publicar Convertite en redactor para Dos Ideas y compartí tus conocimientos a una comunidad que sigue creciendo!
Quiero publicar

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