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 2

Last edited by Guerrero Jun 17, 2024
Page history

Sprint Retrospective 2

Sprint Retrospective

1. Validación y Cierre de Issues

Como desarrollador full stack, me aseguro de que los issues funcionen tanto en el front-end como en el back-end antes de cerrarlos. Esto a veces lleva a cerrar varios issues a la vez porque no siempre sé cómo hacer validaciones aisladas de cada issue. Para mejorar este aspecto, se propone:

  • Investigar y aprender métodos para realizar validaciones aisladas de issues.
  • Pedir ayuda o buscar asesoramiento de compañeros o recursos externos para mejorar la validación individual.
  • Implementar pruebas automatizadas que puedan facilitar la validación de issues por separado.
  • Documentar cualquier problema encontrado durante la validación grupal para facilitar su resolución en el futuro.

2. Fragmentación de Tareas y Aprendizaje

A veces, mis tareas incluyen una parte significativa de aprendizaje, lo que dificulta la planificación precisa. Para abordar esto, se propone:

  • Dividir las tareas en partes más pequeñas y manejables.
  • Estimar el tiempo de aprendizaje por separado y ajustar las estimaciones de las tareas en consecuencia.
  • Comunicar cualquier dificultad o necesidad de aprendizaje durante las Daily para ajustar las expectativas del equipo.

3. Pruebas Relacionadas con el Envío de Emails

Las pruebas relacionadas con el envío de emails requieren un despliegue real para conseguir acceso por HTTPS, ya que el entorno de pruebas de Eclipse solo proporciona HTTP. Para abordar este desafío, se propone:

  • Configurar un entorno de pruebas que permita el uso de HTTPS.
  • Buscar soluciones alternativas o temporales para realizar pruebas de envío de emails sin necesidad de despliegue completo.
  • Documentar cualquier problema encontrado durante estas pruebas y buscar formas de optimizar el proceso de despliegue para futuras pruebas.
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 Retrospective

4.1. Sprint 2

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

Anexo I. Bibliografia