Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • PEGASO PEGASO
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 13
    • Issues 13
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Infrastructure Registry
  • Analytics
    • Analytics
    • CI/CD
    • Repository
    • Value stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • imunnic
  • PEGASOPEGASO
  • Wiki
  • 4.6.4. Sprint Retrospective

Last edited by imunnic Jun 15, 2024
Page history

4.6.4. Sprint Retrospective

Sprint Retrospective

Durante el desarrollo del Sprint se han detectado dos posibles aspectos a mejorar:

  • Asegurar un uso correcto de GIT
  • Reducir la deuda técnica

Asegurar un uso correcto de GITLAB

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.

En este sentido, se han detectado las siguientes prácticas inadecuadas en el desarrollo del Sprint:

  • 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

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.

Revisión de la deuda técnica

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.

Lo que se pretende es reducir esa deuda que posteriormente puede provocar una estimación inadecuada de los issues.

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

Clone repository

Home

  1. Especificación y formulación del problema
  2. Estudio de viabilidad del sistema
    2.1 Mind Map
    2.2 Impact Map
    2.3 Estudio de Alternativas
    2.4 Matriz de Cumplimento de funcionalidades
    2.5 Matriz de decisión
  3. Propuesta de desarrollo
    3.1 Planificación general
    3.2 Diagramas
    3.3 Funcionalidades
    3.4 Interfaz de usuario
    3.5 Producto Mínimo Viable
  4. Desarrollo
    4.1. Marco de trabajo
    4.2. Metodología
    4.3. Historias de usuario
    4.4. Producto
    4.5. Sprint 1
         4.5.1. Sprint Planning
        4.5.2. Sprint Backlog
        4.5.3. Sprint Review
        4.5.4. Sprint Retrospective
    4.6 Sprint 2
        4.6.1 Sprint Planning
        4.6.2 Sprint Backlog
        4.6.3 Sprint Review
        4.6.4 Sprint Retrospective
    Anexo I
    Anexo II