Di una charla sobre cómo trabajamos con XP
Tags: xp, softwaredevelopment, coding, node
Published: 2024-03-17 10:10:21

Cuando empecé a dar charlas supe que no tenía que ser la más experta del tema ni la que más sabe de la conferencia sobre eso, pero que si hablo de mi experiencia, añado un punto de vista único y eso lo hace valioso y, además, a la gente le gusta.

Y además, cuando estoy dando una charla siempre pienso que todo el mundo sabe más que yo, que sabe **todo** lo que estoy nombrando. Eso me hace tener la sensación de que sería repetir algo que ya saben y que se aburrirían.
No solo estoy poniendo a todo el mundo por encima de mí en cuanto a conocimientos, es decir, poniéndome a mí siempre por debajo (que eso ya lo trabajo con mi psicóloga, tranquis), sino que doy por hecho que se sabe y se entiende todo y eso está mal.

Hace no tanto tuve MUCHÍSIMA ansiedad mientras estaba preparando una charla porque pensaba que no tenía sentido, que no iba a aportar nada nuevo, que era demasiado básica. Incluso estuve a punto de cancelarla (solo que la ansiedad de quedar mal era mayor 🙃)

En esta charla contaba un poco las diferencias que yo he notado cuando trabajaba de front y ahora de back, así como la manera en la que trabajamos en mi equipo desarrollando producto y algunas prácticas que llevamos a cabo. El **objetivo** era que si les gustaba o llamaba la atención alguna de estas prácticas, pudiesen **adoptarlas y adaptarlas** a su equipo o, si buscan un cambio laboral, quizás buscar una empresa que trabaje de manera similar. O si no les gustaba nada de eso, pues precisamente ir en dirección contraria.

Voy a aprovechar entonces de contarles muy resumidamente una parte de la charla sobre cómo trabajamos, nuestro mindset y las prácticas que llevamos a cabo y luego contarles la sensación que tuve con respecto a los comentarios que recibí.

Las prácticas de Extreme Programming que aplicamos tienen como objetivo desarrollar software en **ciclos cortos**. Hacemos entrega contínua y también el aprendizaje es contínuo ya que al entregar, obtienes** feedback** de la usuaria **inmediatamente** para saber si tu producto se está comportando como lo esperas y, si es necesario, iterar o mejorar, así como ir midiendo.
Para poder obtener ese feedback de manera inmediata:

El código que desarrollamos es de **calidad** porque está testeado. Sí, los bugs también los puedes meter si tienes **tests**, porque al fin y al cabo los tests los haces tú, humana que se puede equivocar; pero las probabilidades son bastante menores a si no los tienes.
En nuestro caso hacemos **Test Driven Development (TDD)**, donde escribimos primero un test, pasa en rojo porque aún no está hecha su implementación y desarrollamos la implementación con el **mínimo código necesario** para pasar el test en verde. Una vez que el test está en verde, hacemos commit y push, por lo que son commits muy pequeñitos, uno tras otro. De ser necesario un **refactor**, lo hacemos con el test en verde para tener la seguridad de que, si rompemos algo, el test nos va a avisar. El TDD nos permite tener un código fácilmente modificable que nos facilite cuando necesitemos iterar. También hay que decir que es una herramienta más, la idea es tener tu código testeado, sea con TDD o sin él. A mí me encanta y me encantaría trabajar siempre así, pero es verdad que su curva de aprendizaje no es trivial y más cuando ya has trabajado algún tiempo antes sin él (y sin testing).

Usamos **Trunk Based Development (TBD)**, donde desarrollamos en la rama principal y los commits se pushean directamente a master/main para poder entrar en ese ciclo corto y obtener ese feedback rápido que tanto nombro. (Aquí la gente se llevó las manos a la cabeza, se escuchan murmullos y veo caras en shock)
Si estamos desarrollando una nueva funcionalidad y aún no queremos ponerla en producción, o por ejemplo hacemos un experimento que queremos sacar- medir-cerrar-iterar; usamos las **Feature Flags** para poder ir desplegando pero aún sin hacer release. En nuestro caso es una variable de entorno que ponemos a true/false cuando queremos que llegue a producción, o no.

Trabajamos en **Pair y mob programming**, de manera que el código no es responsabilidad de una sola persona y se puedan esparcir conocimientos de manera más orgánica. Aparte del beneficio del aprendizaje en conjunto.

Para asegurarnos que las decisiones que hemos tomado están aportando valor a la usuaria y que nuestro producto se está comportando como esperamos,  tenemos las métricas y los logs como herramientas de **observabilidad y trazabilidad**.
Las **métricas** las revisamos diariamente todo el equipo (vamos rotando) en un tablero de Quicksight que es un servicio de AWS. Aquí vemos la evolución de, los clicks, leads y el Conversion Rate diariamente, comparándolo con el mismo día de la semana anterior y el mes anterior y así, además, podemos conocer sobre estacionalidad y saber que, por ejemplo, en enero suele haber un pico de gente buscando pisos, o que ayer cayeron los clicks porque era festivo en Colombia. 
Y los **logs** los ponemos con el objetivo de que, al explorarlos, nos den información de lo que está pasando en nuestra aplicación en ese momento. Los guardamos en una “base de datos de logs”, en nuestro caso Cloudwatch, otro servicio de AWS.

Todas estas prácticas las nombré en la charla porque las usamos y son nuevas para mí desde que entré en este equipo, nunca había trabajado así antes cuando trabajaba en consultoras. Otra gran diferencia es la manera de trabajar que tenemos en el equipo, donde **formamos parte de la definición del producto**. Esto hace que estés más involucrada en lo que estás desarrollando, conocer el por qué, investigar, buscar entre todo el equipo soluciones juntas.
No todas las tareas que hacemos son de programar (que les digo, son mis favoritas) porque resolvemos problemas junto con Product Manager, leemos datos, los interpretamos, iteramos en base a ellos, definimos next steps y también hacemos **Spikes** para leer e investigar sobre el problema antes de meternos en ello y así poder respondernos preguntas, aprender y bajar el riesgo de error.

Las tareas las afrontamos **“todas a una”**. Intentamos detectar lo prioritario y vamos todas a eso simultáneamente, sea en mob porque lo requiere la tarea o hacemos split y trabajamos 2 parejas, o una pareja y un trío, depende. Esto nos ayuda a tener contexto de lo que se está trabajando y hacer una entrega más rápida para nuestro amigo: el **feedback de la usuaria**.
Si no es posible o las circunstancias no lo permiten y trabajamos cada pareja en una tarea distinta, luego hacemos catch up para poder traspasar conocimientos.

Discutimos sobre **concerns** y hacemos tareas que cuidan nuestro código y que puede que no entreguen directamente valor, pero son igual de importantes y evitamos acumular tanta deuda técnica.

Esto, les repito, ha sido una parte muy resumida de la charla y ahora quiero contarles algunas preguntas y comentarios que recibí, pero primero tienen que imaginarse la situación:

_Una mujer con una camiseta de Opeth dando una charla en una universidad a un montón de ingenieros egresados y estudiantes, contándoles que es enfermera y psicopedagoga y que lo que hizo fue un bootcamp y que además hace push a master_😂

La sensación que tuve en general después de las preguntas y comentarios que recibí era de incredulidad. Yo sentí que la gente pensaba que yo estaba metiendo la coba, o sea que me estaba inventado todo porque simplemente no les parece viable.

Me preguntaron que cuánto tiempo al día dedicamos en hacer tests y si no nos hemos puesto a pensar en todo ese tiempo que podríamos invertir en * desarrollar *. Porque desarrollar != tests, claro.
Me dijeron que en lo que “nuestro jefe” se entera que estamos trabajando juntas en parejas o más, se nos va a acabar el chollo.
Que vino agile, luego scrum y ahora vine yo a decir “sujétame el cubata”, con tono jocoso burlón, claro.
Que es irresponsable hacer TBD y no probar en entornos de desarrollo previamente.
Que si gano más ahora en backend que en frontend, LOL la pregunta.
Que cómo es que subimos código sin code reviews.
Que por qué no hago el grado superior “y no me digas que es por tu niño porque ya está mayor” (solo lo puede saber si me sigue en twitter jajaja), le digo que no tengo tiempo para eso y me dice -mientras señala a un grupo- que toda esta gente está estudiando mientras trabaja y le tuve que decir hola, señor, hice dos carreras ya trabajando a la par, una de ellas trabajando y embarazada; déjeme en paz.
Etc.

Saco varias conclusiones:

- Me encontré con la sorpresa de que de verdad no conocían muchas cosas (porque hola, “todo el mundo siempre sabe más que yo”). Y no me lo esperaba y me costó entender por qué ciertas preguntas y comentarios. Me llevo el aprendizaje de no dar nunca nada por hecho. Y darme un poquito de fe.
- Me quedo con la sensación de que nadie da un duro por lo que conté y eso, quieras o no, lo siento un poquito como un fracaso. Aunque espero que al menos a alguna persona le haya servido.
- Que tanta ansiedad y malestar las 3 semanas antes, para que al final sí fuese algo nuevo para el público… aunque me hubiese gustado más sensación de “wow qué guay” que de “pff, estás loca”.
- Me pregunto si hubiese sido un hombre, hubiese sido más wow que pff

Una cosa importante, yo estoy muy agradecida con haber dado estas charlas y las organizaciones no tienen nada que ver con lo que luego me digan o pregunten. Ni todo el público ha sido así <3 pero hay unos que resuenan.

Si les llama la atención saber más de cómo trabajamos, hay otras cosas interesantes que se las puedo contar luego =)

Ari