subscripción
Cuaderno de software
Pair programming
Diciembre 31st, 2011 - [Enlace local]
¿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:
- código poco expresivo difícil de entender
- diseño no simple (complicado) y difícil de entender
- desconocimiento del dominio (esto lo hizo otro y no sé de qué va)
- cambiar cosas y tener que volver a probarlo todo a manubrio (o no hacerlo y provocar nuevos fallos)
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 reglas XP, 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:
- dos teclados y dos ratones (¡incluso dos pantallas!), dos sillas y la pantalla en medio. Hay que estar cómodo.
- máxima intensidad: pomodoros, y un objetivo (troceado en un pequeño log de la sesión de pairing)
- 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.
- 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:
- cuando hagas un walking skeleton
- cuando diseñes unas CRC Cards
- cuando estés refactorizando
Algunas malas costumbres:
- acceso poco equitativo a teclado o pantalla / dominio de una persona del teclado
- matrimonios: parejas que nunca cambian
- uno trabaja el otro descansa
- dos ordenadores
- cada uno hace “su propio trabajo”
- los debates duran más de diez minutos sin escribir código nuevo
Algunos buenos hábitos:
- descansar
- ser humilde y receptivo
- comunicarte y escuchar
- defender tu visión y saber ceder
Un par de links:
- Una crítica bien argumentada contra el pair programming
- Pair programming remoto con saros
- Es curioso: lo primero que se comparte al hacer pair programming con atajos de teclado…
