Prácticas de XP en tiempos de remoto

En Codurance el trabajo remoto ya forma parte de quiénes somos. La pandemia, como en muchas otras empresas, presentó retos y oportunidades, lo cual nos llevó a replantearnos  nuestro modelo de trabajo. Fue ahí cuando el remoto cobró sentido y, aunque ya lo utilizábamos en nuestra dinámica con clientes, se instaló como una realidad organizacional que nos permite, entre sus múltiples beneficios, captar talento superando los límites geográficos. 

Para nuestro equipo también supuso un aprendizaje y adaptación. Por eso, y tras un periodo de tiempo trabajando de esta manera, quisimos ofrecer un circuito en el que, a través de nuestra experiencia, demos luz a algunas de las prácticas más comunes de Extreme Programming y a los beneficios y desafíos de aplicarlas en remoto.

Este circuito estuvo a cargo de Javier Chacana, Javier Martínez y Matheus Marabesi, Software Craftspersons en Codurance Spain. 

Pair Programming en remoto

El Pair Porgramming es una práctica que, como su nombre lo dice, consiste en programar por pares. Es un procedimiento de colaboración mutua constante que promueve el aprendizaje y un desarrollo más ágil al tener una retroalimentación inmediata. El miedo o las dudas que se pueden generar sobre el valor positivo de esta metodología, suelen girar en torno a la falta de conocimiento sobre sus verdaderos beneficios. Por ello, exponemos algunas de sus ventajas.

Aspectos positivos de pairear:

• Permite clarificar ideas de inmediato 
• Apoyo mutuo por mantener el foco en la tarea que se busca cumplir. 
• Tomar la iniciativa y continuar con el desarrollo cuando uno de los dos está bloqueado.
• Retroalimentación constante
• Compartir la responsabilidad

En el Pair Pogramming los developers cumplen dos roles: navigator y driver. No son fijos, se hace una rotación entre ellos lo cual permite un dinámica más fluida. El driver se encarga de generar el código mientras que el navigator revisa el trabajo que se está generando para pulir posibles errores y hacer consideraciones estratégicas sobre el diseño.

Retos de pairear en remoto y su posible solución

Distracción

En remoto tiende a haber mayor facilidad para perder el foco y distraerse por distintos motivos, ya sea por las notificaciones que llegan a la pantalla o las propias situaciones inadvertidas de estar en casa.

Consejo
Ser conscientes de estas exigencias y desviaciones, saber que pueden suceder y tomar acciones preventivas como silenciar notificaciones durante la sesión, cerrar pestañas innecesarias y estar en un sitio tranquilo. La comunicación, como en muchas otras ocasiones, es la clave. Hay días en los que estás más concentrado y otros en los que cuesta más, por eso pairear es de dos, hay que expresarlo y buscar ese soporte en el otro. 

Confusión 

En presencial la dinámica del cambio de roles entre el driver y el navigator es más clara y visual ya que están sentados uno al lado del otro y trabajan con un solo teclado. En remoto esto presenta un nuevo reto ya que cada uno está con su propio teclado. Para superarlo, uno de los tips fundamentales es establecer tiempos de rotación. 

• Reloj de ajedrez - acordar un tiempo determinado para el cambio de roles.
  
• Ping pong - A escribe un test, B lo revisa y luego B escribe el test y A lo revisa, y así sucesivamente. 
  
• Pomodoro - marcar un tiempo en el que se mantienen los roles, luego hacer un pequeño break y se cambiarlos. Después de 4 pomodoros tomar un descanso un poco más largo. 

Recomendaciones finales

Para pairear en remoto es importante escoger un set up y unas plataformas de comunicación que se ajusten a los gustos y la comodidad de las personas involucradas. Asimismo, contar con el equipo necesario, como un buen micrófono, ayuda a eliminar el esfuerzo adicional que supone tratar de entender a través de la pantalla. Además, debido a la carga cognitiva, es aconsejable a veces quitar la cámara para aliviar la presión del efecto espejo.

Recomendamos no buscar una estructura muy estricta. Debe tener forma, sí, y debe haber un propósito y una buena comunicación, pero también debe haber espacio para la individualidad para encontrar la mejor manera de adaptarla a los gustos personales.

El remoto pone un punto de dificultad añadido por distintos motivos, como el síndrome de fatiga por la pantalla, la falta de acercamiento físico etc. Por ello, es fundamental generar acuerdos desde el principio para que haya una base cómoda de la que partir y compensar estos inconvenientes. 

Test Driven Development

El Test Driven Development es una práctica de desarrollo de software que consiste en plantear una hipótesis y luego corroborar esa hipótesis con el código que estamos escribiendo, que es el mínimo posible. 

Las 3 leyes del TDD

• No puedes escribir código de producción a menos que sea para hacer un test fallido.
• No puedes escribir más allá de un único test unitario, con el suficiente código para hacerlo fallar (error de compilación es fallo).
• Solo puedes escribir código de producción suficiente para hacer pasar el único test fallido.

Beneficios que aporta el TDD

• Intenta disminuir el feedback loop de lo que se está haciendo.
• Aumentar la confianza en el código
• Genera cobertura contra regresiones (red de seguridad)
• Ayuda a desarrollar de una manera más estructurada para alcanzar un código de producción que podamos utilizar con confianza. 
• Conduce a un buen diseño, siempre y cuando conozcas cómo luce un buen diseño. Quizás te va a ayudar a tener un código testable pero no va a llevarte automáticamente a un código bien diseñado. 
• Side effect: Aumenta técnicamente el nivel del equipo y mejora la retención de talento. 

Formas de implantar TDD en un equipo

Si practicas TDD solo, vas a tener únicamente el feedback de tus tests, por lo tanto no sabes si lo que estas generando luce bien o solo estás cumpliendo con tu hipótesis. Necesitas retroalimentación de otra persona para sacarle el máximo provecho. Además, con Pair Programming puedes romper el síndrome del impostor y aprender más junto al otro.

Los estilos o escenarios que se pueden dar de pair programming según los conocimientos del driver y navigator: 

TDD en remoto: recomendaciones

En remoto, uno de los mayores desafíos es la distracción, estamos más preparados para estar en físico, pero debemos intentar integrarnos. Hay una carga cognitiva importante y por ello la rotación es clave, porque tener el control del teclado ayuda a mantener el foco. La idea no es que la estructura sea perfecta, sino apoyarse mutuamente para mantener la concentración. 

Establecer un política de rotación con anterioridad

• No estructurada (ad hoc). Según la experiencia y tiempo paireando juntos puede resultar natural. Cuando el otro experimenta un bloqueo el otro entra para ayudarle y se cambian según la necesidad o gusto entre ellos. 
• Timer. Establecer un tiempo específico
• Ping pong. Las reglas de ping pong para tdd dicen que la rotación ocurre en rojo. 

Establecer el medio por el cual se harán con el control del código

• Git
• Solo control remoto de una computadora
• Plugins o herramientas tipo Code with me

Te dejamos un link a la sesión completa por si quieres repasar conceptos y revisar el ejercicio práctico que realizamos durante el encuentro.

Coding Standards, Collective Ownership y Refactoring

Los codings standard son unas bases generales o acuerdos dentro del equipo que facilitan la tarea del desarrollo y un control del código unificado. Este listado de reglas, también conocido como code conventions, permite que el código resultante luzca uniforme sin importar quién lo escribió.

Entre sus beneficios, unificar el código ayuda a eliminar la carga cognitiva de la lectura de código. Si existe una base unificada, cualquier desarrollador que lea ese código se sentirá más familiarizado y podrá desenvolverse con mayor libertad. Creemos que, con mayor razón en remoto, es necesario mantener estándares de código.  

Razones para adoptar Coding standards:

• Mejorar la lectura del código
• Minimizar costes de manutención
• Mejorar la productividad de los equipos
• Aumentar la velocidad de desarrollo

Hoy en día tenemos algunas herramientas que nos permiten formalizar y forzar la adopción de estos estándares.

Algunas formas de documentar y automatizar las convenciones

• Uso de linters y prettiers
• EditorConfig. Una herramienta muy buena para equipos multidisciplinarios y multiplataforma que trabajan con el editor de texto que sea, simplemente hace una estandarización a través de un archivo donde se declaran los acuerdos
• Githooks para forzar verificaciones
• Fijar versiones de dependencias y runtime
• Usar analizadores estáticos de código

Collective Code Ownership: ¿Todos hacen todo?

• No, pero todos son responsables por todo el código
• Es una política organizacional y al mismo tiempo un sentimiento
• Pair programming con rotación aporta a mejorar el ownership 
• Mejora la distribución de conocimiento
• Mejora la calidad y reduce el re-trabajo: mejora la productividad
• No se trata de que todos hagan de todo, sino que puedan hacer de todo.

El ownership se puede relacionar con el QA, no como una etapa sino como algo holístico y parte de esa responsabilidad propia. Todas estas prácticas ayudan a integrar la calidad desde el principio. 

¿Pull Request en remoto?

En Codurance preferimos el Trunk Base development que pull request, aunque en entornos altamente regulados o equipos que viven en franjas horarias muy distintas el pull request permite un nivel de asincronía importante. En este aspecto un beneficio que aporta el remoto es la posibilidad de la asincronía. 

Refactoring y deuda técnica

El refactoring es una de las prácticas core originales de XP y consiste en mejorar la estructura interna del código fuente de una programa, preservando su comportamiento externo. Refactoring es algo que debería de ocurrir de manera constante, no es reescribir código o corregir bugs.

Si estás haciendo refactoring quiere decir que de alguna manera estás pagando la deuda técnica. La deuda técnica puede ser, por ejemplo, por falta de conocimiento al no saber cómo resolver un problema, o a nivel de diseño al intentar mejorar tu time to market. También existe la deuda de código, adquirida por malos hábitos. Esta deuda se puede generar de manera consciente o inconsciente y se va “pagando” al refactorizar.

Para afrontarla haz un seguimiento para identificarla y refactoriza constantemente. En remoto, puede ayudar tener sesiones donde se visibilice esta deuda y se determinen quality gates (acciones, code conventions y test) que ayuden a saldarla.

Súmate a nuestra comunidad

Si quieres mantenerte al día de todo lo que hacemos: eventos, podcast, blogpost, casos de éxito, workshops, katas, etc. Suscríbete a nuestra newsletter y te haremos llegar contenidos para inspirarte. Además, te invitamos a ser parte de nuestra comunidad y sumarte a nuestro Meetup dónde periódicamente nos encontramos para compartir conocimientos.