|
|
|
### Retrospective
|
|
|
|
### 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.
|
|
|
|
|
|
|
|
#### Product Owner
|
|
|
|
Durante el evento se han detectado los siguientes aspectos a mejorar por parte del Product Owner.
|
|
|
|
- **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>3</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>4</sup>
|
|
|
|
#### Interacciones
|
|
|
|
|
|
|
|
#### Developers
|
|
|
|
|
|
|
|
#### Comunicación
|
|
|
|
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.
|
|
|
|
|
|
|
|
A diario se han realizado los eventos Daily Scrum que han permitido que Product Owner y Developer inspeccionen el trabajo y puedan resolver dudas y continuar revisando el progreso. En ciertas ocasiones se han aprovechado estos eventos para revisar que todo el equipo compartía los mismos conceptos, en concreto respecto a la _DoD_.El principal canal de comunicación ha sido presencial, si bien en algunas ocasiones se ha optado por el telemático para estos eventos. A lo largo del resto del proceso, la comunicación ha sido libre entre los miembros del equipo cuando ha sido necesaria.
|
|
|
|
En cuanto a la Sprint Planning, deberían haberse contemplado todos los item que han acabado conformando el Sprint Backlog
|
|
|
|
|
|
|
|
#### Herramientas
|
|
|
|
|
|
|
|
En cuanto a las herramientas usadas, Gitlab ha propocionado herramientas que no se han explotado adecuadamente:
|
|
|
|
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>5</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
|
|
|
|
|
|
|
|
#### Definición de Hecho
|
|
|
|
Depués de los comentarios del cliente respecto al incremento, se ha decidido incluir en la DoD el siguiente punto:
|
|
|
|
|
|
|
|
El equipo se ha podido ajustar a la _definición del hecho_ y el producto se adhiere a los estándares de calidad requeridos por el cliente. Por ello se considera que no es necesario revisar la Definición del hecho.
|
|
|
|
* 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
|
|
|
|
[3] 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/
|
|
|
|
[4] 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/
|
|
|
|
[5] Apuntes de Dirección de Proyectos. Diploma de Informática Militar, Academia de Ingenieros, Hoyo de Manzanares, Madrid [en línea] [fecha de consulta: 26 abril 2024]. Disponible en: https://dptosic.github.io/dgp/combat-agile/combat-agile |
|
|
\ No newline at end of file |
|
|
|
[5] Apuntes de Di |
|
|
\ No newline at end of file |
