GitLab

Retrospective

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^1,2.

  • 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³. Se pueden redactar de una forma que permita la comprobación más exahustiva, utilizando enfoques como Checklist Format o Given-When-Then⁴

Developers

Comunicación

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.

Herramientas

En cuanto a las herramientas usadas, Gitlab ha propocionado herramientas que no se han explotado adecuadamente:

• 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.

Definición de Hecho

[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