|
|
### Sprint Retrospective
|
|
### Sprint Retrospective
|
|
|
|
|
|
|
|
#### Individuos
|
|
Durante el desarrollo del Sprint se han detectado dos posibles aspectos a mejorar:
|
|
|
|
|
|
|
|
<!-- 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.
|
|
- Asegurar un uso correcto de GIT
|
|
|
|
- Reducir la deuda técnica
|
|
|
|
|
|
|
|
**Gestión del Product Backlog**:
|
|
#### Asegurar un uso correcto de GITLAB
|
|
|
- **Items demasiado pequeños**: Los items del product Backlog eran demasiado pequeños mientras que las historias de usuario de las que son parte son demasiado grandes. Debería encontrarse un término intermedio para dar más pie a definir las tareas para el desarrollador. Las _epicas_ deben durar entre 2-4 semanas por equipo como referencia y las _historias de usuario_ entre 4 y 8 días por programador<sup>1,2</sup>.
|
|
|
|
|
|
|
|
|
|
- **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> -->
|
|
La herramienta GIT que se está utilizando es GITLAB. Es una herramienta que no solo permite el control de versiones, si no que además proporciona herramientas de seguimiento y tableros para el control y adaptación del trabajo pendiente. Siguiendo la metodología de *Combat Agile* el uso de GIT es importante para poder asegurar que se sigue el marco *Scrum*, permitiendo aportar el máximo de valor al cliente.
|
|
|
#### 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 este sentido, se han detectado las siguientes prácticas inadecuadas en el desarrollo del Sprint:
|
|
|
|
|
|
|
|
En cuanto a la Sprint Planning, deberían haberse contemplado todos los item que han acabado conformando el Sprint Backlog. -->
|
|
- Issues mal definidos
|
|
|
|
- Issues sin estimar
|
|
|
|
- Varios issues en progreso
|
|
|
|
- Varios issues asignados al mismo desarrollador sin cerrar
|
|
|
|
- PBI completados que no están cerrados
|
|
|
|
|
|
|
|
#### Herramientas
|
|
Creemos que si se mejora en este aspecto, podría ayudar a ganar foco sobre el objetivo del Sprint. Por ello se propone este aspecto a mejorar para el siguiente Sprint, teniendo en cuenta la definición que se le asigna como [Issue #53]((https://git.institutomilitar.com/imunnic/generador-melmil/-/issues/53)).
|
|
|
|
|
|
|
|
<!-- 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:
|
|
#### Revisión de la deuda técnica
|
|
|
|
|
|
|
|
- **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<sup>3</sup>.
|
|
Durante el desarrollo, pueden darse situaciones en las que el trabajo realizado, desde el punto de vista del código, no sea el óptimo. Esto puede provocar que adaptaciones futuras de la aplicación sean más complejas de lo que deberían, pudiendo complicar y retrasar trabajo futuro.
|
|
|
- **Diagrama burndown y GIT**: el uso no adecuado de los _FIX_ y _Merge_ puede generar que la herramienta de [Diagrama de burndown](https://burndown-dim.netlify.app/#/) no sea todo lo eficiente que debería por lo que se debe ajustar el uso de los mismos. -->
|
|
|
|
|
|
|
|
|
|
#### Procesos
|
|
Lo que se pretende es reducir esa deuda que posteriormente puede provocar una estimación inadecuada de los issues.
|
|
|
|
|
|
|
|
<!-- 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.
|
|
Para ello, se propone este aspecto a mejorar para el siguiente Sprint, teniendo en cuenta la definición que se le asigna como [Issue #54](https://git.institutomilitar.com/imunnic/generador-melmil/-/issues/54)
|
|
|
|
|
|
|
|
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] Apuntes de Scrum. Diploma de Informática Militar, Academia de Ingenieros, Hoyo de Manzanares, Madrid [en línea] [fecha de consulta: 30 abril 2024]. Disponible en: https://minisdefeet.sharepoint.com/sites/acingxlvidim/Documentos%20compartidos/Forms/AllItems.aspx?id=%2Fsites%2Facingxlvidim%2FDocumentos%20compartidos%2FScrum%2F04%5FSCRUM%20%5FArtefactos%2Epdf&viewid=da382f22%2D4676%2D4d08%2D8ff3%2D511f3a432bb0&parent=%2Fsites%2Facingxlvidim%2FDocumentos%20compartidos%2FScrum
|
|
|
|
|
[2] MEZINSKY, Alexander. ¿Cómo representar la granularidad de la pila de producto? [en línea] Blog de un Apóstol de Scrum y Kanban , 16 de febrero de 2015[fecha de consulta: 30 abril 2024]. Disponible en: https://scrum.menzinsky.com/2015/02/como-representar-la-granularidad-de-la.html -->
|
|
|
|
|
<!-- [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 Dirección de Proyectos. Diploma de Informática Militar, Academia de Ingenieros, Hoyo de Manzanares, Madrid [en línea] [fecha de consulta 30 de abril de 2024]. Disponible en: https://dptosic.github.io/dgp/combat-agile/indice --> |
|
|
|
\ No newline at end of file |
|
|
