Planificaci´ on de releases

Los planes dereleases son una pr´actica complementaria a scrum, que mira hacia adelante en varios sprints y proporciona un estimado de cu´ando estar´a disponible un conjunto coherente de funcionalidades [100].

Durante la etapa dediscovery, adem´as de definir que se iban a tener instancias de demostraci´on con cliente para que brindara retroalimentaci´on de forma temprana, tambi´en se gener´o un plan dereleases, tanto del backend como de las aplicaciones.

El plan inicial fue tener tres releases, finalizando a comienzos de diciembre y dejando el tiempo restante hasta enero para pruebas y soluci´on de defectos. Cada uno de los releases corresponder´ıa a un timebox¹ con un objetivo de entregable definido junto con el cliente.

Figure 6.1: Primer plan de release del sistema.

Pero este plan fue modificado a partir de la mitad delsprint 0. El equipo evalu´o las tareas que quedaban por terminar de dichosprint, y determin´o que para la fecha

1Untimebox es un enfoque en el que se establece un periodo de tiempo espec´ıfico para trabajar en un objetivo. En lugar de trabajar hasta alcanzar el objetivo, el trabajo se detiene al final de la caja de tiempo y se eval´ua lo que se logr´o en ese per´ıodo. [101]

del primer release no se iban a haber implementado las funcionalidades estimadas en un comienzo.

Siguiendo el principio de calidad integrada [102], el equipo decidi´o incluir las pruebas en el proceso de desarrollo, al igual que la resoluci´on de los defectos encon- trados, en lugar de dedicar la mayor parte de diciembre a las pruebas y arreglo de defectos.

Esta decisi´on ten´ıa como objetivo que el equipo iterara sobre un producto con calidad, y por consiguiente lograra trabajar de forma eficiente. De esta manera, se iban a detectar los errores en el c´odigo y defectos en las aplicaciones prematuramente, aprendiendo de estos para evitar cometerlos durante el resto del proyecto. Como resultado de esto el equipo pudo ver que a medida que el proyecto iba creciendo las pruebas encontraban errores m´as complejos, producto de la complejidad que adquir´ıa el sistema. Por lo tanto, mitigar los defectos encontrados de manera temprana fue beneficioso a largo plazo.

A ra´ız de esto, se gener´o un segundo plan con solo dosreleases. Luego del primer release, estaba planificado con el cliente realizar pruebas con expertos en el dominio del problema (ver apartado 2.1), para obtener retroalimentaci´on que pudiera resultar valiosa para el desarrollo restante. En el ´ultimo release, que ser´ıa a mediados de diciembre, se har´ıan pruebas de usabilidad con usuarios deUlta, dejando el resto de dicho mes para implementar ajustes a partir de los resultados obtenidos.

Figure 6.2: Segundo plan de release del sistema.

El equipo comenz´o a preparar el primer release a comienzos de noviembre. Esto fue un gran acierto, ya que se descubri´o de forma temprana que elrelease delbackend no lo podr´ıan realizar los miembros del equipo por falta de permisos, que no se les pod´ıa brindar por pol´ıticas de seguridad de Ulta. As´ı que se necesit´o que dicho release lo hiciera la representante t´ecnica que estaba trabajando con el equipo.

Tom´o semanas coordinar con el cliente los permisos, accesos y despliegue tanto del backend como las aplicaciones frontend, pero finalmente el 21 de noviembre se hizo el primerrelease exitoso del proyecto. Despu´es de esto, el equipo cre´o dos gu´ıas que detallaban los pasos necesarios para desplegar el sistema, principalmente con el objetivo de transferir ese conocimiento a la representante t´ecnica deUlta, que solo se especializaba enbackend y no sab´ıa c´omo realizar este tipo de despliegues. Estas gu´ıas se pueden ver en el Anexo 18, y el detalle de c´omo hacer los despliegues en la secci´on 7.1.1. Control de cambios.

Luego de esto, el equipo aprovech´o para generar despliegues luego de cadasprint, para que las pruebas de exploraci´on hechas por el cliente fueran realizadas en un ambiente lo m´as similar a producci´on. Estos despliegues de versiones intermedias

del producto no forman parte del plan de release, sino que son un complemento a las iteraciones.

Si bien se ten´ıa planificado que el primer release lo probaran expertos de Ulta, esto no se pudo gestionar, ya que dicho equipo no ten´ıa la disponibilidad horaria durante ese per´ıodo. Por lo tanto, estas pruebas se dejaron para hacer junto con las de los usuarios, al terminar el proyecto.

El desarrollo finaliz´o el 2 de enero de 2023, dando fin a la etapa dedelivery.

Figure 6.3: Burn up chart [103] con la evoluci´on del backlog del producto y los releases.

Aunque durante el desarrollo se presentaron algunos retrasos (que se pueden ver en la figura 6.3), el equipo logr´o mantener el enfoque en las historias de usuario relacionadas con los objetivos comprometidos para el primer release, por lo que

con los objetivos del ´ultimo sprint. M´as adelante durante esta secci´on, se detallar´a m´as sobre estas decisiones tomadas.

Esta modificaci´on en la fecha de finalizaci´on, y por consiguiente el release final, se produjo como consecuencia de nuevas funcionalidades que se agregaron durante el proyecto. Estas ten´ıan como objetivo brindar un producto m´as completo, mejorando la experiencia de usuario. Se agregaron funcionalidades relacionadas con el skin tracking,widgets para el dispositivo celular, y la posibilidad de recuperar una rutina eliminada.

A partir del ´ultimo release se comenzaron a preparar las pruebas que se iban a realizar con usuarios y expertos. Finalmente, las pruebas con usuarios no se pudieron hacer por limitaciones de la empresa.

Luego del ´ultimo release se tuvieron que hacer arreglos debido a cambios en los servicios de Ulta con los que interoperaba el backend. En consecuencia, se hizo un release extra despu´es de finalizada la etapa dedelivery.