El experimento de la bitácora diaria no está yendo exactamente como esperaba. La semana que viene seguiré insistiendo, pues en realidad todo va de demostrarme a mí mismo que soy capaz de adquirir un nuevo hábito. En cualquier caso, tenía previsto retomar la serie sobre metáforas y aquí traigo una bastante conocida entre los desarrolladores de software: el tren de “releases”.
Por alguna razón, el término original en inglés (“release train”) no se suele usar traducido completamente al castellano como “tren de entregas”, “tren de lanzamientos” o incluso “tren de versiones”. Parece haber tenido más éxito la versión espánglish: tren de “releases”. Seguramente porque no nos terminamos de poner de acuerdo en cómo traducir el término “release”.
El “software release train” es un modo de planificar la entrega de software según un calendario predeterminado y regular, como si de un “horario de trenes” se tratara. Este calendario es público para todos los equipos que deben contribuir a la entrega y representa un compromiso por su parte, pues el calendario debe ser cumplido. Si usamos la metáfora: “el tren se llevará a los pasajeros que estén listos para viajar”, es decir, se integrará sólo el software que esté listo para ser integrado.
Frameworks de escalado ágil como SAFe han popularizado esta técnica pues, como explica Johanna Rothman, es una manera fácil de ayudar en la transición hacia una metodología ágil. SAFe organiza a los equipos por programas y les pide que integren el resultado de su trabajo cada 3 meses; a esto lo llama ART (Agile Release Train) porque así se posiciona mejor en buscadores. 😉
Bromas aparte, recordemos que el Manifiesto Ágil nos dice:
“Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.”
Pros y contras
A favor tenemos, como ya he contado más arriba, que es una manera de comenzar a entregar más frecuentemente. Esto ayuda a acostumbrarse a tener una cierta cadencia y a enfrentarse al reto de integrar software que debe ser entregado más a menudo que lo que quizás se haya hecho nunca. Esto se multiplica cuando se trata de varios equipos contribuyendo al mismo software.
En contra tenemos que se trata de una planificación rígida que impedirá entregar aquellas funcionalidades que estén listas antes de tiempo, con el consiguiente coste de oportunidad.
Ejemplos
Un ejemplo de tren de releases es la entrega anual de la Eclipse Foundation. También es conocida como “entrega simultánea”, “entrega coordinada” o “tren de releases”. Los diferentes proyectos que forman parte de Eclipse se van integrando hasta la entrega final, siguiendo un proceso descrito aquí y que, si te interesa, te recomiendo eches un vistazo.
Otro ejemplo lo tengo muy cerca. Los equipos que desarrollan las apps de eDreams ODIGEO están utilizando el tren de releases pues partían de bastantes carencias en los procesos de construcción y entrega. El tren de releases les está ayudando a conseguir un ritmo de entregas que antes no tenían. Además, con este proceso hemos podido escalar el desarrollo. Tenemos varios equipos que desarrollan independientemente, aunque comparten la base de código y deben integrarse tanto técnica como funcionalmente. Esto es esencial porque sólo hay un artefacto que se entrega a la correspondiente tienda (ya sea la de Apple o la de Android) para su distribución a los usuarios.
La metáfora
La utilidad de las metáforas es muy palpable en este caso del tren de releases. Incluso para explicar el proceso a seguir usamos el vocabulario y las ideas que emanan de ella: el horario, estar listo para viajar, la salida y la llegada del tren, etc.
A mí me ayuda mucho a pensar en cómo ayudar a mejorar a los equipos. Es fácil visualizar las aglomeraciones de gente en los andenes cuando se va acercando la hora de llegada del tren, es decir, las funcionalidades que se van acumulando en el tablero, en la columna de “Listo para la entrega”. Puedo sentir el bullicio de gente preguntando cuál es el próximo tren, cuánto vale el billete, si hay algún tren que vaya por una vía de alta velocidad, etc. Ponerme en esa situación imaginaria me ayuda a pensar en los problemas desde otra perspectiva, lo cuál suele llevar a mejores soluciones.
Pero no soy sólo yo el que usa la metáfora, pues ésta del tren es muy fácil de entender. Resulta muy llamativo oir a la gente involucrada debatiendo sobre cómo mejorar el proceso hablando de trenes, horarios, maletas, vagones… Voy a poner un par de ejemplos.
No debemos correr para llegar al tren
Cuando se acerca la fecha para cerrar la versión y comenzar la pruebas de integración entre equipos, es típico que algunos equipos se pongan nerviosos y aceleren para conseguir entregar alguna funcionalidad importante o alguna a la que le falta poco para estar acabada. Lógicamente esto suele llevar a introducir errores o a saltarnos partes de nuestro proceso, con lo que indefectiblemente nos encontramos con problemas durante la integración. Si estás haciendo Kanban, como es mi caso últimamente, es fácil ver los cuellos de botella en la columna de QA.
La reflexión que entonces trae el equipo a la retrospectiva se entiende muy fácilmente.
Cuando corremos para llegar a tiempo al tren podemos olvidar meter cosas importantes en nuestra maleta, es decir, podemos olvidar detalles importantes en una funcionalidad. También podemos caernos al ir más rápido, es decir, cometer un error tal que nos impida poner la funcionalidad en producción. O quizás podemos alcanzar el tren a tiempo, pero llegar sudados y cansados, es decir, no disfrutamos de nuestro trabajo y no estaremos frescos para seguir trabajando en el resto de funcionalidades que irán a continuación. Lo mejor es cuando alguien propone llevar maletas más pequeñas, es decir, cuando plantean simplificar las funcionalidades.
El tren se lleva a quien está en el andén
Esta frase surge cuando hablamos del DoR (“Definition of Ready” o Definición de Listo) para las funcionalidades que deben participar de una entrega dada. Así, el equipo puede hablar de que hay que “comprar el billete” cuando se refiere a hacer “pull request en la rama de integración”. Incluso pueden hablar de que hay alguien que se encarga de “vender los billetes” y que sólo te los venderá si tienes el dinero, es decir, si has cumplido con algún requisito anterior, como tener pruebas automatizadas, la aprobación de las pruebas funcionales, o cualquier otra que hayan decidido.
La metáfora ayuda también cuando hay que cuestionar el propio proceso. Por ejemplo, cuando queremos dejar de hacer “tren de releases” e ir hacia “continuous delivery”, es decir, entregar tan pronto como una funcionalidad está lista. En la metáfora se convierte en transformar el tren en un taxi. De esta manera, el equipo puede debatir sobre cómo transformar el proceso de una manera mucho más creativa y con menos apego a las tareas que cada cuál realiza.
Conclusiones
El uso de la metáfora del tren permite que el equipo reflexione acerca del proceso sin personalizar en el trabajo individual de las personas y además ayuda a encontrar soluciones más creativas a los retos que el proceso trae consigo.
Me gustaría conocer si has usado esta metáfora alguna vez y que compartieras aquí tu experiencia. Además, si te ha gustado este artículo y te ha resultado útil, compártelo para que le llegue a más gente.