Créditos de la fotografía: Christina Morillo en Pexels
A colación de mi anterior entrada sobre el conocimiento, os voy a contar que he aprendido sobre la programación colaborativa.
Cuando en una coreografía, un bailarín se cae, la coreografía continua. Cuando en un partido de futbol expulsan a un jugador. ¿Qué hacen los demás? Pues adaptarse a la nueva situación para que el espectáculo continúe.
Así es como debe funcionar un equipo, cuando un miembro no está, el equipo cubre el espacio hasta que vuelva.
Si tu equipo de desarrollo no funciona de esta forma, ¿Qué puedo hacer para que funcione así?, pues colaborando, trabajando juntos para que el conocimiento de todo el sistema se extendienda.
Cuando Jose María se ponga malo, que pueda ser reemplazado por el equipo hasta que se recupere.
De aquí viene que cuatro ojos ven más que dos. Cuando dos personas desarrollan juntas, suele llamarse pair programming, con tres o más programación colaborativa.
Esa forma de enfocar, el conocimiento, es que dos o más personas se junten al mismo tiempo para hacer juntos una funcionalidad o reparar un bug. Y la pandemia a muchos nos a llevado a utilizar herramientas como Microsoft Teams, Zoom, compartir codigo via Visual Studio, etc.
Esta forma de trabajo el algo que no se debe hacer 100% de la jornada o el 100% del bug o la funcionalidad. Se deben hacer entre máximo un 80%. Ya que por ejemplo puedes investigar el bug de forma independiente cada uno y luego juntarse para resolverlo con dos enfoques diferente que han de consensuar.
Par mí el tiempo lógico es máximo 2 horas y parar durante un tiempo para volver a retomarlo. Puedes usar la técnica de Pomodoro, así el trabajo también se reparte un poco de forma ordenada y el equipo maneja los mismos tiempos.
Como todo en esta vida, existen excepciones en las que estarás el 100% y más de 2 horas. Aunque lo habitual es no hacerlo. Por tanto, centremos el tiro en la anterior forma de trabajar.
Lo ideal para mi es coger tareas con responsabilidad individual y luego, invitar a colaboradores a finalizarla.
La tarea aunque la tengas asignada tu y realizaras un 80% de ella, no es responsabilidad tuya al 100% el resultado, es de la pareja/grupo, todos somos responsables. Indirectamente implicas a tu colaborador. Pero la experiencia me dice que el responsable en mayor medida debe seguir siéndolo, habrá situaciones de conflicto que habrá que sentenciar imperativamente. es decir, era tu tarea asignada y en esas situaciones que nos desvían, tu tienes la decisión cuando falla la democracia.
La programación colaborativa se convierte en una revisión en vivo y siempre ofrece la mejor solución, ya que no implica una sola mente para resolver el problema. A veces, por esto mismo, convierten a la programación colaborativa en una experiencia extenuante: respeta los descansos y que no sea la practica habitual diaria, es lo que me dicta la esperiencia.
Y aquí vamos, a un supuesto hándicap, seguro que alguien se preocupa en el dinero y en los recursos ineficientes, con trabajadores ocupándose de tareas independientes serán más productivos y sacaremos más funcionalidades. Esto no es cierto, refuerza al equipo (nadie se vuelve indispensable para una tarea) y os aseguro que trabajando colaborativamente he visto sacar más funcionalidad que de forma individual.
Existe un estudio, Strengthening the Case for Pair Programming, que en resumen nos da un 15% menos de productividad en colaboración, 15% menos de errores y codigo más sencillo. Yo he podido ver esto mismo en la vida real con este resultado: menos bug y codigo más simple, por tanto, incide directamente en el mantenimiento.
La productividad depende el nivel de la persona y la formación del equipo (proporción Senior/Junior). Los juniors ven acelerado su movimiento a senior, esto puede ser una buena compensación para la empresa, sin entrar en factores de retención.
Cuidado con las colaboraciones 100% seniors puede ser contraproducente y las colaboraciones 100% juniors, aquí la cosa se dispersa si no existe un senior vigilando.
Y que se pongan 2 o más personas a programar, una de ellas escribiendo código con un «mira como lo hago» no es pair programing ni colaboración, si no te dejan intervenir o te dejan el código para que lo revises más adelante, desde mi humilde esperiencia, es una simple forma de compartir conocimiento y poco enriquecedora.
Se que muchas personas no están cómodas trabajando en colaboración o que no se lleven bien entre ellas. No forcemos las cosas, pero evitemos los silos que provoca no colaborar.
No pienses que esto de primeras funcionará, se tiene que practicar y buscar tecnicas, pero una vez adquirida esta habilidad es un beneficio que va desde la persona hasta la organización.
