Aplicación de Scrum

el proceso explicado en 9.5 Gestión de cambios .

Como ningún integrante del equipo había trabajado en funcionalidades que no dependieran de conexión a internet, durante esta etapa también se realizó un spike para investigar acerca de cómo implementar la funcionalidad offline ( RF9 ). Realizar un spike implicó llevar a cabo una investigación intensa acerca las diferentes maneras que existen de implementar funcionalidades offline y las tecnologías que lo permiten. Se buscó reducir la incertidumbre o los riesgos asociados acerca de una temática desconocida para el equipo, para poder tomar decisiones de manera informada.

7.2.3 Conclusión

En la etapa final del proyecto, el equipo se centró en los otros entregables que se encontraban dentro del alcance del proyecto, como los manuales de deploys y en la elaboración de la documentación académica. A medida que se acercaban los últimos sprints del proyecto (13 y 14), se comenzó a disminuir el esfuerzo dedicado al desarrollo del producto por parte del equipo, y progresivamente se aumentó el esfuerzo en la elaboración de la documentación. En esta etapa final, el esfuerzo dedicado al desarrollo se enfocó en la resolución de bugs .

proyecto y los riesgos mencionados, se establecía la velocidad deseada para el siguiente sprint .

El próximo paso era revisar el product backlog ya priorizado, teniendo en cuenta en todo momento las funcionalidades de alto nivel a incluir en el release actual establecido por el release plan , para determinar las historias de usuario y tareas que se agregarían al sprint . Una vez cargado el sprint, si había alguna historia que no tuviera asignada story points aún, se realizaba su correspondiente estimación. Esto se llevaba a cabo utilizando la técnica planning poker que se implementó a través de una extensión de Jira. Se estableció que debían participar por lo menos 3 integrantes del equipo a la hora de estimar, y se utilizó la escala de Fibonacci del 1 al 13, siendo 1 el menor esfuerzo y 13 el máximo. Por ejemplo, si a una tarea se le asignaba un puntaje de 5 puntos, al resto de las tareas que se considerarán más complejas, se les asignaba un puntaje de 8 o 13 puntos, según que tan más compleja se creía que era. A medida que se avanzaba en los sprints , las estimaciones fueron siendo cada vez más precisas, ya que había más tareas e historias con las que comprar. En el anexo 12.12.3 Planning Poker se explica más en detalle la estimación realizada con planning poker. Cuando todas las historias se encontraban estimadas, se comparaba la velocidad estimada para el sprint con la velocidad deseada, y en caso de ser notablemente diferentes, se consideraba con el equipo sacar o agregar alguna tarea según correspondiese.

También se revisaba que ninguna tarea o historia dependiera de otra para ser desarrollada, ya que de ser así, provocaría que no se pudiera realizar o completar la tarea. Una vez que se encontraban seleccionadas y estimadas todas las tareas del sprint , pasaban a conformar el sprint backlog .

7.3.2 Ejecución de las iteraciones

La ejecución de un sprint comenzaba cuando el equipo daba comienzo al mismo en Jira. A partir de este momento, cualquier integrante era libre de tomar las tareas que

deseaba, en base a sus preferencias o afinidades técnicas.

Como se comentó en 4.3 Metodología de Trabajo , el equipo no realizó Daily Meetings de la manera que SCRUM lo sugiere, pero cuando un integrante se asignaba una historia, avisaba al resto del equipo por Whatsapp para que todos estuvieran informados. También en las llamadas semanales realizadas por Discord, cada integrante comentaba el progreso de su tarea y si requería ayuda debido a algún bloqueo. Esto permitió al equipo estar al tanto de qué fue desarrollado por cada integrante, lo que podía resultar útil en un futuro en caso de que existan dudas.

Cuando un integrante terminaba una tarea, creaba los Pull Requests (PRs) necesarios para la revisión de otro compañero y movía la tarjeta asociada a la tarea a la columna de “Revisión” en el Board de Jira. Esta columna indicaba que la tarea estaba finalizada y que existían PRs listos para ser revisados. En cualquier momento de la ejecución de una iteración, los integrantes podían revisar los PRs disponibles y avisar al colaborador que existían cambios o mejoras a realizar, en caso de ser necesario. Si la tarea cumplía con la definition of done , el revisor aprobaba el PR y se movía la tarjeta a la columna de “ Done” .

7.3.3 Evaluación de las iteraciones

En los sprints que el equipo consideró necesario, la primera evaluación que se realizaba al finalizar el sprint era la sprint review. Como se explicó en 4.4.3 Sprint review , esta ceremonia se vio omitida en aquellos sprints donde el equipo sintió que el valor aportado al producto no sería visible para el cliente, ya que se trataban de mejoras de calidad interna, o por una reducción en la velocidad promedio, disminuyendo las tareas realizadas a mostrar. En los sprints que sí se realizaron sprint review , el equipo se reunió con el cliente, se le comentaron los avances de la última iteración y se les presentó una demostración del producto.

Como segunda instancia, se realizaban las Sprint Retrospective . Para estas reuniones el equipo se reunía en modalidad virtual la mayoría de las veces y se aplicaba la técnica de retroalimentación “ Start, Stop, Continue ”. Para hacer esta reunión dinámica e interactiva, se decidió que integrantes del equipo se turnaran uno a uno para responder de manera oral. Se comenzaba analizando qué nuevas prácticas se podrían introducir, para mejorar tanto el proyecto como el equipo, tomando en cuenta la experiencia ganada en los sprints anteriores. Luego, se discutía acerca de qué prácticas debían dejar de hacerse, ya que tenían un impacto negativo y por último, las acciones que debían mantenerse debido a que venían funcionando bien. Esta instancia le dio al equipo las herramientas necesarias para mejorar constantemente su gestión y proceso, logrando mejorar el desempeño sprint a sprint .