Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • Gocourt Gocourt
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 9
    • Issues 9
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • 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
  • menadim46
  • GocourtGocourt
  • Wiki
    • Documentacion
  • Sprint Retrospective

Last edited by menadim46 May 20, 2024
Page history

Sprint Retrospective

Con la retrospectiva se pretende inspeccionar el sprint respecto a individuos, interacciones, procesos, herramientas y su Definición de Hecho.

En este sentido se indentifican los siguientes aspectos:

Individuos

  • Para el siguiente sprint, generar un documento desde la planning con las reuniones diarias, para tratar recopilar puntos de fallo revisables en los días siguientes antes de llegar al final del sprint.
  • De acuerdo con lo anterior cumplir con todas las reuniones diarias en el sprint 2 y comprobar su efectividad con respecto al sprint 1.

Interacciones

  • Las reuniones diarias se han realizado comprobando la funcionalidad, sin embargo en algunas ocasiones no se han podido realizar, espaciando su celebración entre ellas, detectando aspectos tanto positivos como negativos que resultan de interés. Por un lado, beneficia la perspectiva que se tiene del producto ya que se identifican ciertas consideraciones durante el sprint o para implementar a futuro, y por otro lado, se pierde el contacto con el producto ya que a diario se orienta de forma más precisa y con margen de corrección la aceptación del desarrollo de acuerdo al objetivo del sprint.

Procesos

  • Los criterios de aceptación podrían refinarse con la experiencia del sprint, para poder ser más objetivos. Como la variedad de las pruebas y número de ellas que se han realizado.

  • No perder el foco en la funcionalidad definida gastando tiempo en funcionalidades secundarias antes de haber finalizado todos los issues. Si bien estas implementaciones resultan de utilidad, puede repercutir negativamente en el alcance del objetivo para futuros sprints.

  • A la hora de cerrar issues, verificar tanto historias de usuario como objetivos y notificar su cierre para poder definir algún issue adicional que complete el pbi antes de cerrarlo.

Clone repository

#Home

1. EVS - Estudio de Viabilidad del Sistema

  • Alcance del Sistema
  • Mind Map
  • Impact Map
  • Entregables Ordenados por Prioridad
  • Alternativas al Producto
  • Matriz de Cumplimiento
  • Matriz de Decisión

2. ERS - Estudio de Requisitos del Sistema

  • Diagrama de Clases

  • Interfaz de Usuario

3. MVP - Minimo Producto Viable

  • Entregables MVP

4. Desarrollo

  • Historias de Usuario
  • Product Backlog
  • Definicion de Hecho

4.1. Sprint 1

  • Sprint Planning
  • Sprint Backlog
  • Sprint Review
  • Sprint Review

4.1. Sprint 2

  • Sprint Planning