Hace ya unos meses tuvimos el placer que tener a Teresa Oliver compartiendo un día con Frogtek. Nos visitó, le contamos cómo trabajamos, qué herramientas nos gustan, cómo recogemos las métricas, qué hacemos con ellas... y luego por la tarde ella lideró una retrospectiva y nos dio ideas sobre cómo hacerlas en el futuro.

Cuando revisábamos nuestras métricas Teresa se mostró bastante interesada en conocer los datos que tenemos sobre historias de usuario (USs) programadas en pair con la idea, imagino, de validar si se puede defender el argumento de que hacer hacer pair-programming es más rápido. Validar algo así con datos empíricos sería algo bastante radical dado que podría servir para cambiar la mentalidad de muchos "managers" usando el argumento más simple y, por qué no decirlo, simplista "si pones a dos ingenieros a trabajar en la misma tarea la acaban en menos de la mitad de tiempo".

Yo no tenía la respuesta a la pregunta de Teresa pero sí tenía los datos en bruto para hacer una primera aproximación, así que me apunté la idea y hoy, más vale tarde que nunca, he hecho un pequeño, breve y simple análisis.

Tomando las historias de usuario implementadas en Frogtek en los últimos 20 meses y eliminando los bugs, es decir, sólo tareas de añadir o cambiar funcionalidad, tenemos:

  • El tamaño medio de las USs hechas en solitario: 0.38 puntos.
  • El tamaño medio de las USs hechas en pair: 0.75 puntos.

Primera conclusión, lógica por otro lado, el pair programming se usa especialmente cuando las tareas son complicadas, largas o arriesgadas.

  • Días brutos desde que se empieza el desarrollo, hasta que se termina, cuando se hace en solitario:  11.5 días, es decir 30 días por punto.
  • Días brutos desde que se empieza el desarrollo, hasta que se termina, cuando se hace en pair: 24 días, es decir 32 días por punto.

¡Oooohhhhh!... El gozo de nuestro "manager" en un pozo. Hacer pair programming no acelera el desarrollo... de las USs (ni siquiera considerando a los dos programadores, pair programming con tres es ya vicio, como una única criatura bicefálica mitológica... aunque esto bien puede deberse a que las tareas que se acometen en pair en Frogtek son siempre las más complicadas y habitualmente se infraestiman), otra cosa muy distinta es si hacer pair programming, en casos justificados, puede acelerar la velocidad del equipo en el medio plazo. Desgraciadamente ese es un análisis mucho más complicado de hacer y en Frogtek no tenemos los datos que validen nuestra opinión que es que sí, que hacer pair-programming acelera la velocidad del equipo ya que:

  • Dota de consistencia al trabajo del equipo.
  • Se crea código de mayor calidad que contendrá menos bugs.
  • Sirve para trasmitir conocimientos y reducir el bus-factor.
  • [inserte aquí su razón]

Todos estos aspectos son difíciles de medir de forma cuantitativa para convencer a un "manager", en cualquier caso ojalá sólo fuera este factor el que complica el análisis de la velocidad de un equipo de desarrollo. Y si no que se lo pregunten a Michael Dubakov... que por cierto ¡no mete el pair-programming en su modelo! (WTF)

 

Conclusión: seguimos teniendo que creernos que el pair programming (en su justa medida) es más rápido... a la larga. Al menos hasta que alguien nos dé mejores datos que los nuestros y un modelo para aplicarlos.

Bienaventurados los que creen, porque ellos irán más rápido.

Libro de las bienaventuranzas del software.