← Ir a portada

Pair programming

¿Dos personas en un mismo ordenador? ¿Pero eso no les hará ir más lento? ¿Pero eso no hace el desarrollo el doble de caro? A veces podemos responder a esto hablando de que programar en pareja es divertido o que es una buena forma compartir conocimiento, cosa que es cierta pero… ¿hace más caro el desarrollo o no?

Efectivamente, NO lo hace más caro. Porque teclear no es el cuello de botella. ¿Cuál es el cuello de botella? ¿Qué es lo que me ralentiza a la hora de desarrollar una nueva funcionalidad para cierta base de código?

De dónde viene la lentitud a la hora de desarrollar software:

Son éstas cosas las que hacen que, cuando quiero cambiar algo para añadir una nueva funcionalidad a mi aplicación cada vez me cueste más. Al principio voy rápido porque hay poco código y con un diseño cualquiera me vale. Pero cada vez me cuesta más añadir nuevas funcionalidades porque, además, no sé loque estoy rompiendo.

El pairing, combinado con otras técnicas como TDD y el resto de , ayuda a defender el diseño simple de la aplicación durante todo su desarrollo.

Pero para que el pair programming resulte realmente eficaz hay que estar muy atento a cómo se utiliza. Sino, puede resultar realmente caro:

  1. dos teclados y dos ratones (¡incluso dos pantallas!), dos sillas y la pantalla en medio. Hay que estar cómodo.
  2. máxima intensidad: pomodoros, y un objetivo (troceado en un pequeño log de la sesión de pairing)
  3. máxima concentración: el que no escribe debe mantener la atención muy activa, por ejemplo llevando el log y aportando ideas todo el rato. Sino: ping pong.
  4. si un problema que nadie sabe resolver interrumpe la dinámica –> es mejor DEJAR DE PAIREAR y buscar la solución.
Hay que aprender a cuando hacer pairing y cuando no. Por ejemplo, nunca diseñes sólo:
El pairing no sólo preocupará a gerencia por su coste, sino que preocupará a algunos compañeros de trabajo. Porque el pairing es incompatible con “la zona” o “el flow”. Ese estado mental de ensimismamiento donde nos sentimos hiperconcentrados y productivos. No soy muy fan del flow, pero sí reconozco que hace falta momentos en los que trabajar sólo y aislado de manera muy concentrada. Lo que no puede ser es que esa sea la única manera en la que se sepa trabajar…

Algunas malas costumbres:

  1. acceso poco equitativo a teclado o pantalla / dominio de una persona del teclado
  2. matrimonios: parejas que nunca cambian
  3. uno trabaja el otro descansa
  4. dos ordenadores
  5. cada uno hace “su propio trabajo”
  6. los debates duran más de diez minutos sin escribir código nuevo

Algunos buenos hábitos:

  1. descansar
  2. ser humilde y receptivo
  3. comunicarte y escuchar
  4. defender tu visión y saber ceder

Un par de links:

Apuntes relacionados:

2 Respuestas a “Pair programming”

  1. Alberto dice:

    Esto es una cosa que siempre me he preguntada. He tenido la suerte de trabajar en una pequeño proyecto con un compañero y la verdad me aporto mucho y agilizo casi todo. Feliz año

  2. […] es el valor de un refactor de código? ¿Cuál su coste? ¿y del pair programming? Se puede hacer un análisis coste-versus-valor de casi cualquier práctica de […]

Deja un comentario