|
|
|
### 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.
|
|
|
|
|
|
|
|
**Gestión del Product Backlog**:
|
|
|
|
- **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> -->
|
|
|
|
#### 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<sup>3</sup>.
|
|
|
|
- **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
|
|
|
|
|
|
|
|
<!-- 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] 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 |
