GitLab

Sprint Retrospective

Individuos

Es necesario interiorizar aún más la guía scrum para entender mejor el marco de trabajo en el que se desarrolla el proyecto.

- **Criterio de aceptación adecuado al PBI**: Los criterios de aceptación de los PBI está referidos a las historias de usuario y sus propios criterios de aceptación. Las historias de usuario pueden ser mucho mayores y que los criterios de aceptación no coincidan, por lo que se deben definir criterios de aceptación específicos para cada PBI.​ El problema reside en que son los PBI los que se deben aceptar, y no las historias de usuario<sup>1</sup>. Se pueden redactar de una forma que permita la comprobación más exahustiva, utilizando enfoques como Checklist Format o Given-When-Then<sup>2</sup>

Interacciones

En cuanto a las interacciones lo más destacable es la necesidad de definir una fecha de finalización concreta del Sprint para poder ajustarse a ella. Por lo demás, considerando que el equipo Scrum está compuesto por 2 personas las interacciones se han desarrollado según lo esperado y por las vías de comunicación acordadas.

En cuanto a la Sprint Planning, deberían haberse contemplado todos los item que han acabado conformando el Sprint Backlog

Herramientas

La principal herramienta de la que se puede mejorar el uso es GIT. Se pueden aprovechar mucho mejor las capacidades que ofrece de control y revisión sobre el proyecto. En concreto es interesante el sistema de validación y mergeo de los issues en relación al cumplimiento de la DoD. A continuación se describe la forma de mejorar el uso de las herramientas:

• Boards: La gestión del PBI debe llevarse según la metodología Combat Agile desde el principio mediante los tableros que ofrece el servicio GIT, por lo que debe revisarse el uso en el siguiente Sprint. Será necesario adaptar el uso del mismo a lo establecido según la metodología³.
• Diagrama burndown y GIT: el uso no adecuado de los FIX y Merge puede generar que la herramienta de Diagrama de burndown no sea todo lo eficiente que debería por lo que se debe ajustar el uso de los mismos.

Procesos

El proceso detectado para la revisión de la DoD que se podría implementar sería realizar un Merge Request por cada PBI que se cierre, de forma que ese merge request pueda ser validado por alguien que se encargue de comprobar que la DoD se cumple y por lo tanto, que ese PBI puede convertirse en un incremento. Una vez validad, se aceptaría la Merge Request.

No obstante sería necesario comprobar cuál sería el impacto de este proceso en el diagrama de burndown puesto que el Merge Request comenta automáticamente todos los issues sobre los que se hayan hecho Fix con Close, haciendo que esos issues queden cerrados el mismo día, puediendo anular una herramienta importante para la inspección del trabajo.

DoD

Depués de los comentarios del cliente respecto al incremento, se ha decidido incluir en la DoD el siguiente punto:

• Los textos descriptivos deben tener sentido semántico y facilitar la selección de elementos con la menor información posible

[1] BERNÉ, Marta. Criterios de aceptación: ejemplos para elaborarlos. [en línea] Blog de Scrum manager, 08 de marzo de 2023 [fecha de consulta: 30 de abril de 2024]. Disponible en: https://www.scrummanager.com/blog/2023/03/criterios-de-aceptacion-definicion-y-ejemplos/
[2] PAZ, Fernando. Mejores Historias de Usuario para Scrum[en línea] Software Evolutivo, 24 de mayo de 2021 [fecha de consulta: 30 de abril 2024]. Disponible en: https://softwareevolutivo.com.ec/mejores-historias-de-usuario-para-scrum/
[3] Apuntes de Di