[#ALM] Demostrando con números porqué es conveniente realizar Pair Programming

Buenas,

después del excelente Coding Dojo con la ayuda de Luis Ruiz Pavón que hicimos con los chicos de MadridDotNet, pues me quedó pendiente explicar de manera matemática porque es útil realizar una práctica de Pair Programming en los equipos de desarrollo. Pair Programming o Programación en Pareja define un escenario donde básicamente se programa de a dos. He aquí la definición de la Wikipedia:

La Programación en Pareja (o Pair Programming en inglés) requiere que dos Ingenieros en Software participen en un esfuerzo combinado de desarrollo en un sitio de trabajo. Cada miembro realiza una acción que el otro no está haciendo actualmente: Mientras que uno codifica las pruebas de unidades el otro piensa en la clase que satisfará la prueba, por ejemplo.

La persona que está haciendo la codificación se le da el nombre de controlador mientras que a la persona que está dirigiendo se le llama el navegador. Se sugiere a menudo para que a los dos socios cambien de papeles por lo menos cada media hora o después de que se haga una prueba de unidad.

Esta práctica que es bastante útil, tiene muchos detractores ya que usualmente la gente piensa que en el mundo del desarrollo 4 manos producen más que 2. Cuando en realidad 2 cabezas producen mucho más que una sola. Pero bueno, si alguna vez te has encontrado con un “jefe” detractor de esta filosofía de trabajo, este ejercicio puede ayudarte a demostrar porque una práctica de Pair Programming es realmente útil.

Escenario Ideal

Supongamos que tenemos un equipo de trabajo de 6 personas compuesto por 2 programadores seniors y 4 programadores juniors. En un escenario ideal de trabajo, podemos asumir que diariamente un programador senior rinde una cantidad de 2 Unidades de Trabajo (UT), mientras que un programador Junior rinde 1 UT. Si tenemos una semana de 5 días de trabajo estándar pues al final de la semana tendremos 40 UTs. La siguiente tabla nos  muestra estos números para que queden más claros

Team Día 1 Día 2 Día 3 Día 4 Día 5 Total
SrP 2 2 2 2 2 10
JrP 1 1 1 1 1 5
JrP 1 1 1 1 1 5
SrP 2 2 2 2 2 10
JrP 1 1 1 1 1 5
JrP 1 1 1 1 1 5
            40

 

Escenario Real

Pero claro, si realmente te dedicas al desarrollo de software y eres consciente de lo que hace tu equipo de trabajo sabrás que el primer día tal vez un Sr Programmer pueda rendir al 100% y generar sus 2 UT, pero los días siguientes tendrá que ayudar a los Junior Programmers a que cierren su trabajo. En muchas ocasiones esto significa que su rendimiento personal bajará hasta el piso y se dedicará a trabajar por 2 o por 3 para poder sacar adelante el trabajo. Siendo generoso con el reparto de UTs, este escenario podría quedar como la siguiente tabla.

Team Día 1 Día 2 Día 3 Día 4 Día 5 Total
SrP 2         2
JrP   1   1 1 3
JrP     1   1 2
SrP 2         2
JrP   1   1 1 3
JrP     1   1 2
            14

Antes de pasar al escenario siguiente, y ya que has leído hasta aquí, pregúntate porque es tan frecuente que los programadores se junten entre sí para debatir un tema en particular o para mostrarse porciones de código. Verás que muchas veces están realizando Programación en Parejas sin siquiera saberlo.

 

Escenario de Programación en Pareja

Finalmente veamos que sucedería si juntamos a un SrP y a un JrP; y dejamos que la 3ra pareja de JrP vaya rotando con las anteriores. Pues siendo muy amarrete con los UTs, ya de entrada tenemos casi un 150% más que en el escenario real. Y claro, esto asumiendo que los JrP no pueden rendir más con el paso del tiempo. La siguiente tabla muestra este ejemplo:

Team Día 1 Día 2 Día 3 Día 4 Día 5 Total
SrP           0
JrP 1,5 1,5 1,5 1,5 1,5 7,5
JrP           0
SrP 1,5 1,5 1,5 1,5 1,5 7,5
JrP           0
JrP 1 1 1 1 1 5
            20

 

Pues bien, aquí tienes un ejemplo completamente irreal sobre como el Pair Programming puede ayudarnos a mejorar el rendimiento de nuestros equipos de trabajo. Obviamente que esto que he puesto aquí no es un estudio real ni cierto, ya que en desarrollo de software influyen muchas otras variables; pero tal vez si te juntas con un jefe obtuso puedas comenzar por hacer que reconozca que se trabaja en el escenario 2 y luego explicarle que el escenario 3 es mejor.

Completa la frikada de la semana … Risa

Update: voy a poner un poco de contexto para explicar el porqué de esta entrada y porqué no debes tomarte en serio la misma, es simplemente un ejercicio para demostrar como NO PUEDES bajar a números simples el trabajo de un equipo. Pair Programming es una práctica que aporta muchas ventajas, si las quieres conocer pues tu amigo google o su amigo bing, te pueden ayudar. Sino volveré a recomendar The Agile Samurai, un libro obligatorio para estos días. En este caso en particular he destrozado todas las buenas prácticas de gestión de proyectos para llegar a un número que sea válido para el post, por ejemplo

  • Es imposible medir la capacidad de trabajo de una persona en “unidades de trabajo”, todo el mundo sabe que el trabajo de un desarrollador se mide en base a la cantidad de líneas de código que escribe por día. Si no sabes como hacerlo, este post te puede ayudar a detectar quien trabaja y quien no.
  • Pair Programming no se basa en juntar a un Programador Senior y un Programador Junior, es un poquito más complicado. Yo personalmente recomiendo realizar parejas en base a los años de cada persona. Está científicamente demostrado que cuando la suma de los años de una pareja es un múltiplo exacto de 3 o de 7, el rendimiento se incrementa en un 18%.
  • Pair Programming nos permite ahorrar costes de hardware. Al no necesitar 2 ordenadores, podemos reducir los gastos de IT a la mitad. Otra cosa que recomiendo para ahorrar costes y espacio trabajando con Programación en parejas, es no tener 2 sillas, sino una única silla y una persona colgada como en Mission Imposible. Esto también ayuda ya que si está colgada con una leve inclinación hacia abajo, llegará más sangre a su cabeza y podrá escribir más líneas de código al día.

 

Saludos @ Home

El Bruno

   

Fuentes: http://es.wikipedia.org/wiki/Programaci%C3%B3n_en_pareja

About these ads

2 pensamientos en “[#ALM] Demostrando con números porqué es conveniente realizar Pair Programming

  1. Hola Bruno, antes que nada quiero decirte que a este tipo de esfuerzos, porque pensar y redactar una entrada es un esfuerzo, yo los aprecio mucho y por eso te doy gracias. Ahora, como comencé como atajándome, quiero decirte que la entrada es buena, la intención es mejor aún pero el ejemplo (o escenario) no me ha parecido correcto.

    Empecé a escribir un comentario aquí pero luego de un buen tiempo de escribir y escribir este se volvió tan largo que pensé que lo mejor sería un post en mi blog. Así que, como sos una personas respetada por mi, espero que lo tomes a bien y si sirve para el debate (o no) se verá luego.

    Saludos.

    • Lucas, faltaba más che! que toda apreciación es buena. Creo que aquí la falta (intencionada) de contexto hizo que se perdiera algo en el camino. Te voy a dar mas detalles en tu post, ya que te has tomado tiempo para responder. Muchas gracias :D

Deja un comentario

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s