Agile y la verdad contundente sobre la programación en parejas

Agile ha integrado de las técnicas de Programación Extrema (XP) las tareas de codificación en pareja. Todavía recuerdo cuando por allá por el 2004 en Londres el lider de equipo me mostró la forma en las que se trabajaba en pares… lo primero que pensé fué que no iba a funcionar y que era una empresa de locos de atar.

¿Cómo funciona?
Básicamente cada grupo (y no la empresa) define sus reglas, las que deberán ser llevadas adelante a rajatabla hasta que el equipo realice alguna modificación al  marco de trabajo original. Algunas de los mandatos que he visto para trabajo en parejas en los últimos años son los siguientes:

1. Llevar adelante solamente las tareas de mas de N puntos de esfuerzo (u horas si se emplean las mismas).

2. Las tareas o historias específicas, por ejemplo de base de datos u otro sector crítico.

3. Cada 2 historias, una debe ser llefada adelante en pareja.

4. Las tares que involucran tecnologías o codificación de la cual no todos los miembros están al tanto.

5. Todas las historias, sin importar la carga horaria.

6. Se marcan de antemano las historias que deben ser llevadas adelante en pares.

7. Con juegos (¡mi predilecto!), por ejemplo el que pierde el partido de futbolín o no es capaz de responder la capital de un país debe trabajar de a dos.

Image

Esto por supuesto son algunos ejemplos que he vivido pero hay muchos más; los equipos pueden ser creativos, siempre y cuando esto funcione para ellos, aumente la calidad del código y disminuya el riesgo para la empresa

“El trabajo en parejas no puede ser mandatorio desde fuera del equipo pero tiene que ser comprendido y llevado adelante como algo importante para el crecimiento del equipo y organización “

Si el equipo no desea realizar el trabajo en pares, debería poder demostrar que tiene una opción fiable y superior que permita esparcir conocimiento y aumentar la calidad del código.

La idea entonces detrás del trabajo en equipo es hacer concer a todos los miembros las tecnologías y código, así como también disminuir el riesgo para el caso de que solamente parte del grupo se encuentre disponible. Recuerdo un invierno en Londres donde 4 de los 6 miembros se encontraban enfermos, elevando solamente a 2 el número de programadores disponibles.

Los problemas de trabajo en equipo
Cuando se sugiere a las personas ésta forma de trabajo, es posible que no comprendan su significado o quieran (en forma explícita o implícita) trabajar en pareja con ciertos miembros del equipo. En este caso se pueden dar 6 situaciones claras:

1. Que esté acostumbrado a trabajar en solitario y piense que de esta forma se obtedrá el resultado más veloz y de mejor calidad.

2. Que no desee trabajar por no tener una buena relación con su par.

3. Que no se sienta cómodo  trabajando con alguien que en el pasado fue su superior o tiene más experiencia (o al revés)

4. Que no desee trabajar con alguien que no conoce o solamente tiene contacto esporádico

5. Que no desee realizar la tarea en conjunto con alguien que no se encuentra físicamente en el mismo lugar; por un lado por no contar con las herramientas necesarias para el manejo remoto o exista una diferencia de cultura/idioma.

6. Que piense que se bajará el rendimiento y no se llegarán a los objetivos pautados para el ciclo.

Una cosa que he notado en mi día a día es que en Latino América y España muchas personas tienden a tomar  decisiones basadas en la primer experiencia de contacto. Por ejemplo ante una codificación casual en parejas, las personas puede sentirse incómodsa ante la primer impresión, los hábitos o la forma de hablar/mirar de su par. Esto puede ser fácilmente remediable si se establecen sesiones informales de cohesión de equipos (Team Building) antes de que se comience con el ciclo de trabajo. En muchas ocasiones basta con salir por algunos tragos y hacer que los integrantes socialicen y se conozcan.
También existen varios juegos que pueden ser efectuados al conformar al equipo, los que evidentemente mejoran la comunicación y relación a futuro.

“Siempre que sea posible, evita que los miembros que codifican en pares tengan su primer contacto durante éste proceso”

Lo más típico es que exístan temores de que trabajar en pares pueda  disminuir el rendimiento y hacer que no se puedan cumplir las metas. Esto es un punto importante y hablaré más adelante sobre las investigaciones científicas al respecto y sus resultados.

“Si quieres que la codificación en pares sea efectiva y duradera, tienes que asegurarte que el equipo disfrute el día a día, de forma similar a que fuese un gran juego”

Codificación en pares y pre-conceptos I
Cuando se habla de codificación en pares, se entiende la existencia de 2 roles, uno llamado el codificador y otro el navegador. El primero es quien tiene siempre el teclado o ratón, mientras que el segundo es quien verifica o sugiere ideas. Ambos roles pueden ser intercambiados cada ciertos minutos y debería ser así para que se considere una tarea exitosa.
Originalmente la bibliografía indicaba que el codificador y el navegador trabajaban en diferentes niveles de abstracción; el navegador actuaba con un pensamiento más estratégico revisando, prestando atención a los defectos y en cierta forma marcando el rumbo del codificador, mientras que éste último solamente escribía el código (Dick A.J., Proceedings of XP; Jenser R., A Pair programming Experience). Trabajos más recientes indican que esto no es así y que ambas personas rotan su trabajo sin diferencias en los niveles de abstracción.

Trabajo en parejas exitoso
De acuerdo a un estudio realizado por L. Plonka (2011), para que el trabajo en pares se considere sano, cada persona debería codificar entre un 40 a 60% de su tiempo y la media de rotación debería ser de 10 a 15 veces por hora. Este porcentaje a su vez se ve incrementado en desarrolladores con mas experiencia.

“La codificación en pares debería ser de entre 40 y 60% del tiempo de cada individio.”

A su vez, se debe asegurar que todos los equipos cuenten con las mismas herramientas y similar capacidad de computador. Para el caso de que uno de los desarrolladores se encuentre remoto, herramientas tales como Skype y escritorio remoto deberían estar disponibles.

Codificación en pares y pre-conceptos II
Los equipos al comenzar inicialmente con Agile tienen miedo de no cumplir con las historias aceptadas para el ciclo debido a la “pérdida de tiempo” del trabajo en equipo. Este temor es normal y te brindaré una investigación científica al respecto para que puedas tenerla en mente. En un estudio realizado por Alberto Sillitti y L. Plonka (2011) se vió que cuando el desarrollador trabaja solo, éste ocupa únicamente una media de 33.3% codificando y 67.7% pensando sobre las diferentes opciones o buscando una solución en Internet  (esto último sobre todo en desarrolladores menos experimentados).

“Un desarrollador codifica solamente 33% de su tiempo cuando lo hace solo”

Por su parte, cuando se trabajan en pares, el tiempo de codificación se ve aumentado a casi el doble y de acuerdo a un estudio de Alberto Sillitti (2011), la calidad del código se ve aumentada. Un ejemplo interesante es que los programadores novatos trabajando en pareja pueden obtener niveles similares de calidad a los mas experimentados (Senior).

La siguiente tabla (Alberto Sillitti, 2012) muestra una comparación de tiempos de codificación:

Image

Tiempos de no-codificación
Los tiempos de espera han sido también estudiados y es interesante ver que pasa con el tercio restante:

1. Tiempos de espera
El desarrollador deberá esperar por el computador a que termine con un proceso (compilación, ejecución de pruebas, etc), esperar a que se integren los cambios, etc

2. Discusiones o explicaciones
Se discuten o analizan las diferentes opciones, se ven las líneas de código y se ve cual es la mejor opción.

3. Utilización de medios tradicionales
Los desarrolladores prefieren rever la estructura de código en una pizarra, dibujar la secuencia en un trozo de papel para comprender mejor la tarea y las posibles opciones.

4. Búsqueda o consejo de alguien más
Dialogar con una tercera persona que tenga más conocimiento o diferente punto de vista para ver como solucionar el problema.

5. Interrupciones externas
Los desarrolladores son interrumpidos por llamadas telefónicas, otros desarrolladores con consultas, etc

Es decir que cuando se trabaja en pares, el tiempo de escritura se incrementa al doble, así como también la calidad del código. La codificación en parejas debería ser adoptada por todas las empresas de software y serciorarse que se realiza de forma divertida e interesante.

Si quieres recibir mis novedades y artículos haz clic en la pestaña SEGUIR de abajo a la derecha; también te podría interesar alguno de mis otros artículos…

10 reglas de oro para medir un proyecto Agile

Descubriendo los problemas de equipos Agile

Implementar Ágil en paises hispanoparlantes vs. anglosajones

Resultados de 7ma. encuesta anual del estado de Ágil

Psicología profunda de las retrospectivas Ágil

6 problemas típicos en retrospectivas Ágil

¿Gastar en tecnología o metodologías de gestión de proyecto?

¿Cuándo utilizo Ágil? La respuesta que estabas esperando…

¿Qué hacemos con los recursos humanos en Ágil?

Resistencia institucional y cambio hacia Agile (Parte 1)

Resistencia institucional y cambio hacia Agile (Parte 2)

Lo que no se dice de Ágil

Las 15 preguntas antes de implementar Ágil/Scrum en la empresa

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s