Sprint 1 del Proyecto Final 2: del 5 al 18 de octubre de 2026.

El compromiso del sprint fue de 6 historias de usuario, 39 puntos de historia y 28 puntos de valor de negocio.

Al cierre funcional del 16 de octubre se completaron las seis historias comprometidas, alcanzando 39 de 39 puntos (100%) y 28 de 28 puntos de valor de negocio (100%).

El Sprint inició con 39 puntos pendientes.

Durante la primera parte se completaron HU10 y HU11, reduciendo el trabajo pendiente a 29 puntos. Posteriormente se integraron HU19 y HU24, dejando 21 puntos. El inicio de sesión biométrico correspondiente a HU02 quedó funcionalmente terminado el 12 de octubre, reduciendo el pendiente a 8 puntos.

Finalmente, con el cierre de HU01 y sus ajustes de registro móvil con KYC, el 16 de octubre se alcanzaron 0 puntos pendientes.

xychart-beta
    title "Sprint 1 — Burndown (puntos restantes)"
    x-axis ["5 oct", "6 oct", "7 oct", "8 oct", "9 oct", "10 oct", "11 oct", "12 oct", "13 oct", "14 oct", "15 oct", "16 oct", "17 oct", "18 oct"]
    y-axis "Puntos restantes" 0 --> 40
    line [39, 36, 33, 30, 27, 24, 21, 18, 15, 12, 9, 6, 3, 0]
    line [39, 39, 39, 29, 29, 29, 21, 8, 8, 8, 8, 0, 0, 0]

Primera línea: avance ideal.
Segunda línea: avance real.

El comportamiento del burndown muestra un inicio más lento que la línea ideal, seguido de una recuperación durante la segunda semana. El equipo finalizó la totalidad de los puntos comprometidos antes de la fecha formal de cierre.

La velocidad final del Sprint fue de 39 puntos completados sobre 39 puntos comprometidos.

Durante la primera semana se completaron 18 puntos y durante la segunda semana se completaron los 21 puntos restantes.

xychart-beta
    title "Sprint 1 — Velocidad por semana (puntos)"
    x-axis ["Semana 1 (5–11 oct)", "Semana 2 (12–18 oct)"]
    y-axis "Puntos" 0 --> 25
    bar [21, 18]
    bar [18, 21]

Primera serie: puntos planeados inicialmente.
Segunda serie: puntos efectivamente completados.

La diferencia semanal se explica por movimientos en el orden de terminación de las historias. Algunas historias previstas inicialmente para una semana fueron completadas en otra, sin afectar el compromiso total del Sprint.

Al finalizar el Sprint, la velocidad total fue:

39 puntos entregados / 39 puntos comprometidos = 100% del compromiso.

El Sprint comprometió 28 puntos de valor de negocio distribuidos entre las seis historias.

Durante la primera semana se habían entregado 21 puntos de valor y durante la segunda semana se completaron los 7 restantes.

xychart-beta
    title "Sprint 1 — Valor de negocio acumulado"
    x-axis ["Inicio", "Semana 1", "Semana 2"]
    y-axis "Valor acumulado" 0 --> 30
    line [0, 18, 28]
    line [0, 21, 28]

Primera línea: valor planeado acumulado.
Segunda línea: valor realmente entregado acumulado.

El Sprint cerró con el 100% del valor de negocio comprometido, alcanzando los 28 puntos previstos.

En el Sprint 1 se comprometieron 39 puntos de historia, correspondientes a seis historias de usuario. Al cierre funcional del Sprint se completaron los 39 puntos comprometidos, alcanzando el 100 % del alcance definido para este Sprint.

xychart-beta
    title "Release Burndown — cierre Sprint 1"
    x-axis ["Inicio Sprint 1", "Cierre Sprint 1"]
    y-axis "Puntos de historia pendientes" 0 --> 40
    line [39, 0]

El equipo completó las seis historias comprometidas y cerró el Sprint sin puntos de historia pendientes dentro de su alcance.

El equipo consiguió completar el alcance funcional comprometido antes del cierre formal del Sprint.

El equipo logró completar todas las historias comprometidas antes de la fecha de cierre. El trabajo con ramas separadas y pull requests permitió que cada integrante avanzara de forma independiente en sus HU sin bloquear el trabajo de los demás, para posteriormente integrar los cambios de manera controlada. Además, el uso de CI fue positivo, ya que el pipeline permitió detectar errores de formato, pruebas y otros inconvenientes antes de llevar los cambios a main. En términos generales, todos los integrantes cumplieron con lo asignado y se logró cerrar satisfactoriamente el alcance del Sprint.

Uno de los principales aspectos por mejorar fue la gestión de los Escenarios de Calidad, ya que en varios casos se revisaron al final del desarrollo. Esto generó reprocesos, pues fue necesario volver sobre funcionalidades que ya se consideraban terminadas. Por otra parte, se presentó un desbalance en la carga de trabajo debido a las diferencias en puntos y complejidad entre las historias asignadas. Asimismo, en algunas ocasiones no se ejecutó Ruff o no se revisó completamente el pipeline antes de subir los cambios, lo que ocasionó correcciones adicionales. Finalmente, algunas aprobaciones de pull requests tardaron más de lo esperado y retrasaron temporalmente la integración de ciertos cambios.

Para el siguiente Sprint se propone trabajar los EC en paralelo con cada HU, evitando dejarlos para la etapa final. También se buscará distribuir mejor la carga desde la planeación, considerando tanto los puntos como la complejidad de cada historia. Adicionalmente, se pretende agilizar la revisión de los pull requests y realizar, antes de subir cambios, una validación de formato, lint, pruebas y cobertura con el fin de reducir reprocesos.

Sprint 1 Backlog en Jira

Las seis historias comprometidas para el Sprint quedaron terminadas.

Durante el Sprint se utilizaron ramas de corta duración y pull requests hacia main.

Los PR principales de las seis historias fueron integrados a main. Adicionalmente se realizaron PR complementarios para completar la experiencia web de socios, alta de socios embebidos, registro Android con selfie KYC y ajustes de seguridad y autorización en la aplicación web.

Documento completo: CONTRIBUTING.md

• Ramas: desarrollo basado en trunk con ramas cortas. main es la única rama permanente; cada cambio sale de main y vuelve mediante pull request.
• Nombre de rama: <tipo>/BPM-<número>-<descripción-corta>.
• Commits: se utilizan Conventional Commits asociados a la clave de Jira.
• Pull requests: cada integración hacia main pasa por revisión y ejecución del pipeline.
• Versionamiento: se utiliza versionamiento semántico MAYOR.MENOR.PARCHE.

Estrategia de pruebas

Las pruebas unitarias y de API del backend se ejecutan con Pytest dentro del pipeline, que publica el reporte JUnit y el de cobertura como artefactos de cada ejecución.

Los pull requests #75 y #79 fueron fusionados por una integrante distinta a su autor.

Revisión automática de código: Ruff analiza el backend en cada pull request.

Tablero del Sprint 1 en Jira

• Sprint 1 Backlog

• Prácticas CI/CD

• Revisión automática de código

• Estrategia de pruebas