¿Cómo es trabajar en un entorno realmente ágil?

Como algunos ya sabréis, desde hace casi un mes estoy trabajando en una nueva empresa dentro de un equipo donde existe una cultura que no había tenido el placer de vivir en ningún otro sitio. Y digo el placer porque como os ire contando nunca he tenido una sensación tan positiva desde que me dedico a esto del software.

Mucha gente se preguntara, porque uso la coletilla de realmente cuando hablo de ágil. La respuesta es sencilla: durante mucho tiempo (por pura ignorancia) creí que estaba trabajando de forma ágil cuando no era asi:

Creía que hacia TBD cuando solo habiamos borrado la rama develop.
Creía que trabajamos con CI/CD pero luego lo desplegábamos una vez al mes.
Hacía pairing de pascuas en ramos.
Hacer tests era opcional, desafortunadamente escaso y muy ocasional.

Tampoco quiero decir que no fuera ágil pero claro las comparaciones son odiosas…

¿Entonces, cómo es trabajar en un equipo que aplica XP?

A continuación os voy contar lo que para mi han sido los principales cambios en mi dia a dia trabajando en un entorno realmente ágil donde se favorece el cambio, la exploración, el refactor y la comunicación de una manera muy fuerte.

Pair Programming

Acostumbrado a trabajar en solitario durante días, incluso semanas, para después pasarle el melón a otro compañero en forma de Pull Request he pasado a estar continuamente acompañado y arropado por el resto del equipo en todo momento. Y no solo hablo de código, todo se hace en grupo (diseñar, refinar, crear tareas,…)

Egoístamente estando en periodo de onboarding es una pasada estar acompañado, ver cómo piensa y trabaja el resto del equipo, no sentirse solo y no tener miedo a no saber hacer algo.

Si algo me ha quedado claro es que esta práctica favorece mucho la comunicación, en cuestión de días hay una afinidad en el equipo brutal, y la transferencia de conocimiento se produce en tiempo real.

Trunk Based Development (TBD)

Adiós a las ramas. Solo existe main y todo el equipo trabaja sobre ella haciendo cambios de manera muy frecuente (en el rango de minutos, nunca de horas).

Esta práctica que a priori puede parecer tener poca historia es un de los cambios que más han gustado. Con esta forma de trabajar todo se simplifica:

Nada de mantener infinitas ramas.
Probabilidad casi nula de tener conflictos (algo que yo personalmente odio y me agobia mucho).

También quiero dejar claro que aplicar TBD me parece de lo más complejo a lo que se puede enfrentar un equipo de cara a aplicar XP.

Recalcar que para poder aplicar TBD de forma segura y con confianza hace falta una serie de pasos previos como puede ser tratar a los tests como ciudadanos de primera clase o favorecer las dinámicas como el pair/ensemble.

Entrega Continua (CI/CD)

Acostumbrado a desplegar una vez a la semana (incluso una vez al mes), cuando empecé a trabajar en el equipo y vi que con cada push a main se generaba un despliegue a producción (con una media de 15-20 pushes diarios) mi primera reacción fue de no dar crédito.

"¿Me quereis decir que vamos a estar desplegando continuamente todo el dia?".
Sí, así es.

Esto que a priori yo lo veo como algo super positivo es importante señalar una vez más que para poder aplicarlo el equipo tiene una red de seguridad muy importante en forma de tests junto con la práctica de aplicar cambios muy pequeños como os contare luego, sino como ya podéis estar pensando sería un auténtico caos.

Slicing (Baby Steps)

Llegamos a la parte que para mi es la más difícil de dominar y donde quiero poner el foco para ser lo lo mejor posible a corto plazo.

Antes hablaba de que en el equipo se hacen pushes a main de forma muy continuada y esto se debe a un trabajo previo enorme donde una tarea se parte en muchas micro-tareas mucho más pequeñas que permiten que la entrega de valor sea mucho más rápida y por tanto el feedback de vuelta llegue super rápido.

Para poder hacer una media de 15 despliegues diarios es necesario trabajar con iteraciones cortas y sin una análisis y refinamiento previo de las tareas esto es imposible.

Conclusiones

Ya para acabar solo quiero decir que me siento muy afortunado de la suerte que tengo de poder trabajar en un entorno donde se favorece la ayuda, el no sentirse solo y donde hacer las cosas bien son es un MUST no algo negociable.

Pero también soy consciente de los difícil que es llegar a este punto en un equipo, en la gran madurez que se necesita para poder aplicar todas estas técnicas de forma eficiente generando mucho valor, sin prisas pero a una gran velocidad.

Es por ello que en el futuro siempre buscaré estar en sitios donde este tipo de la cultura es la norma y no la excepción. No tengo nada en contra de las reviews pero si creo que hay alternativas mejores como el pair del que os he hablado.