Hoja de trabajo semana 7 - martin-hendricks/MISO-PROYECTO-FINAL-SOLVENTA GitHub Wiki

Hoja de trabajo semana 7
Proyecto Solventa — Aseguradora digital
Elaboración Juan Acevedo, John Guerrero, Mauricio Rodriguez, Martin Romero
Versión 1.0
Atributos priorizados Escalabilidad y Latencia (desempeño)
Insumos Enunciado MISW4501-202614-Proyecto.pdf · Hoja de trabajo semana 6

Cierre del Proyecto Final 1: prototipo final, experimentación completada (HA-08 y HA-01 al 100 %), modelos de arquitectura ajustados conforme a la evidencia y versión inicial del plan de trabajo del Proyecto Final 2.

Índice

1. Versión final del prototipo

El prototipo navegable en Figma se cierra en esta semana. La versión final del cliente es Screens · S7 validación (web y Android). Screens de S6 no se toca. Frente al avance de la semana 6, S7 incorpora el contexto de ramo y estado de la validación del 18 sep, y el archivo web suma el back-office de asesor y operador.

Página completa del entregable: Prototipo web/móvil · Cliente y back-office

Versión final (S7): Abrir y recorrer el prototipo web · Abrir y recorrer el prototipo móvil · Abrir y recorrer el back-office · Design web S7 · Design Android S7 · Design back-office

Alcance del prototipo final Cliente web Cliente móvil Back-office
Design system compartido (tokens, Style Tile, Component Gallery, modos Light/Dark) ✅ ✅ ✅ (hereda del de cliente)
Prototipo navegable de punta a punta, sin cuenta de Figma ✅ ✅ ✅
Los 6 recorridos críticos del enunciado §5.1 ✅ ✅ ➖ (soporte a los recorridos 3 y 4)
Accesibilidad ✅ ✅ ✅
Internacionalización y localización (4 locales) ✅ ✅ ✅
Ubicación geográfica ✅ (opcional del navegador) ✅ (permiso nativo JIT) ➖

1.1 Versión web que incluye navegación a la funcionalidad definida y condiciones de usabilidad

Navegación a la funcionalidad definida

Condiciones de usabilidad

Condición Cómo se resuelve en el canal web Evidencia
Accesibilidad Pares Light/Dark del design system con contraste garantizado (fill primary → texto on-primary); hotspots nombrados como los pronuncia el lector de pantalla (Continuar, Volver); orden de tabulación derivado del orden de capas; el estado seleccionado se marca con borde + check + texto, nunca solo con color. Verificable con Adapt content for screen readers y VoiceOver / NVDA / JAWS. S7 web · §4 · Cumplimiento Axe y Nielsen · cliente
Internacionalización Locales es-CO, es-MX, es-CL y es-PE. Selección en el primer arranque (idioma-region) y luego desde Perfil. El núcleo solo entrega prima y código de moneda; el formateo de monto y fecha es responsabilidad del canal. Play S7 · i18n · §4 · i18n
Localización Mismo monto con distinto formato según locale: es-CO $48.900 COP · 07/09/2026 frente a es-MX $1,234.56 MXN · 09/07/2026. §4
Ubicación geográfica Dirección escrita siempre disponible; geolocalización del navegador opcional al adjuntar archivo. Si el usuario la niega, el aviso se envía sin geoetiqueta. Play S7 · evidencia · §4 · Ubicación
Responsividad Cuatro breakpoints diseñados como frames independientes: 390 (teléfono), 768 (tablet), 1024 y 1440 (escritorio), con cambio de gutters, columnas y TopNav ↔ hamburguesa. Design system · Web

1.2 Versión móvil que incluye navegación sobre la funcionalidad definida y condiciones de usabilidad

Navegación sobre la funcionalidad definida

Condiciones de usabilidad

Condición Cómo se resuelve en el canal móvil Evidencia
Accesibilidad Mismos tokens y pares Light/Dark que web; nombres de capa usados como especificación para el lector de pantalla; estado seleccionado con borde + check + texto. Limitación declarada: TalkBack y VoiceOver iOS no leen prototipos de Figma en el teléfono, así que la validación con lector real queda para el canal implementado (Compose). S7 Android · §4 · Cumplimiento Axe y Nielsen · cliente
Internacionalización Selección de locale en Splash → idioma-region y luego desde Perfil (sheet). Recursos previstos values-es-rMX / rCL / rPE. Se implementa en PF2 como HU-94, comprometida en el Sprint 2. Play S7 · i18n · §4 · i18n
Localización Misma prima con distinto formato de monto y fecha según el locale elegido. §4
Ubicación geográfica Permiso nativo JIT (just-in-time): el sistema pregunta en el momento de geoetiquetar la foto del siniestro (HU-24, enunciado §5.2), no en el splash ni en la instalación. No hay rastreo en segundo plano. Si el usuario niega, la ruta evidencia-geo-denegada continúa el recorrido con UI distinta. Play S7 · ubicación JIT · §4 · Ubicación

1.3 Versión back-office que incluye navegación a la funcionalidad definida y condiciones de usabilidad

Herramienta de escritorio para asesor y operador. Vive en la página Back-office · Asesor / Operador del archivo web (127:2); no se clona a Screens · S7. Cierra las 8 HU del grupo A que en Lucid figuraban como Falta UI.

Navegación a la funcionalidad definida

Condiciones de usabilidad

Condición Cómo se resuelve en el back-office Evidencia
Accesibilidad Mismos pares Light/Dark y tokens del design system de cliente. TopNavAdmin nombra destinos como los pronuncia el lector (Clientes, Cotizaciones, Pólizas, Avisos). Cada BadgeBO lleva texto (Activo / Inactivo, En revisión, …), nunca solo color. Un rol sin permiso conserva el shell y sustituye el contenido por EmptyState / SinPermiso. Design back-office · Cumplimiento Axe y Nielsen · back-office
Internacionalización Locales es-CO, es-MX, es-CL y es-PE, heredados del canal web. Prima y código de moneda vienen del núcleo; el formateo de monto y fecha es del canal. §4 · i18n · §6
Localización Mismo monto con distinto formato según locale, igual que en el prototipo de cliente. §4
Ubicación geográfica No aplica: el asesor y el operador no geoetiquetan evidencia. El GPS JIT queda en el canal del asegurado. ➖
Responsividad Solo 1440: es una herramienta de escritorio. No hay frames 768/390. §6

Fuera del alcance del prototipo, declarado explícitamente: portal de socio (aliados), back-office en 768/390 —es una herramienta de escritorio, solo se diseñó 1440— y el código Angular / Compose, que es objeto del Proyecto Final 2. Ver Fuera de este avance.

2. Resultados finales de experimentación

Los dos experimentos de arquitectura quedan ejecutados y cerrados. En la semana 6, HA-01 estaba al 60 % —montaje implementado, sin corridas—; en esta semana se ejecutó la campaña completa y ambos experimentos llegan al 100 %.

2.1 Evidencias de la experimentación

Experimento ASR que valida Montaje y carga ejecutada Métricas medidas % de avance Evidencias
HA-08 — Modelo de lectura de baja latencia para el estado de siniestro (CQRS con proyección materializada y caché) EC-LAT-11 — Latencia, prioridad (A,A) Docker Compose con API de consulta (tres brazos: A lectura directa normalizada, B proyección materializada, C proyección + caché), proyector, simulador de eventos, PostgreSQL, Redis, Redpanda, Prometheus y Grafana. Dataset de 1.000.000 de siniestros. 20 corridas ejecutadas: 9 contrabalanceadas (cuadrado latino, rampa 10→80 req/s), 8 de sensibilidad al TTL (0 s / 300 s, n=3 cada una) y 3 de alta carga (pico de 600 req/s). p95, p50 y p99 extremo a extremo (k6); latencia interna del servicio; hit-rate de caché; lag de proyección; CPU y memoria por contenedor en serie; tasa de error y dropped_iterations. 100 % · Diseño del experimento
· Informe del experimento
· Informe detallado
· Implementación y datos crudos
HA-01 — Protección del presupuesto de latencia de la cotización embebida EC-LAT-01, EC-LAT-02 y EC-LAT-09 — Latencia, prioridad (A,A); restricciones EC-LAT-07 (≤ 120 ms por dependencia) y EC-LAT-08 (timeout duro de 700 ms) Docker Compose con :MsCotización (cuatro brazos: A invocación bloqueante sin caché, B cache-aside bloqueante en fallo, C actualización oportunista con valor de respaldo, C′ C + coalescencia), :AdaptadorOF con circuit breaker y aislamiento por proveedor, doble del proveedor con latencia log-normal, Toxiproxy para inyección de fallas, Redis, PostgreSQL, Prometheus y Grafana. 56 corridas ejecutadas sobre un protocolo de tres fases (120 s sana + 120 s degradada + 60 s de recuperación): seis estados del proveedor, cinco tasas de acierto (99/98/96/90/50 %), dos políticas de interruptor en dos niveles de tráfico, cuatro escalones de llegada (20/50/100/200 sol/s) y celdas de estampida para aislar la coalescencia. p95 y p99 en el servicio; fracción exacta de cotizaciones por encima de 475 ms (conteo directo de buckets, métrica decisoria); proporción resuelta con valor de respaldo; latencia del adaptador cortada por fase; tiempo hasta la apertura del interruptor; invocaciones en vuelo y coalescidas; lag del bucle de eventos. 100 % · Diseño del experimento
· Informe del experimento
· Informe detallado
· Estado de las corridas
· Implementación y datos crudos

Trazabilidad de la evidencia cruda. En ambos experimentos cada cifra citada es recalculable sin reproducir las corridas: los datos crudos por corrida están versionados en el repositorio de código (métricas finales, configuración efectiva, verificaciones de sanidad, resumen de k6 y series temporales segundo a segundo), junto con el consolidado en CSV y las figuras del informe. En HA-01 se versiona además una instantánea completa de la base de Prometheus (raspado de 1 s, 20 MB comprimidos) que cubre toda la campaña, de modo que cualquier percentil puede recalcularse por fase sin volver a correr nada.

2.2 Análisis de resultados: ¿se cumplieron las hipótesis de diseño?

Dictamen global

Experimento Hipótesis de diseño ¿Se cumplió? Lectura
HA-08 HD-08 — La separación del modelo de lectura (CQRS) es necesaria para cumplir EC-LAT-11 (p95 ≤ 150 ms) No se confirma La línea base sin CQRS ya satisface el ASR con 19× de margen. El experimento no fracasó: su aportación es precisamente demostrar que la complejidad propuesta no hace falta al volumen ensayado.
HA-01 HD-01 — Tratar la invocación de Open Finance como actualización oportunista permite cumplir EC-LAT-01/EC-LAT-02 con el proveedor sano y también degradado (EC-LAT-09) Se confirma, con un matiz que el diseño no anticipaba El brazo C cumple en los seis estados del proveedor. El matiz: el desacople no hace falta frente a cualquier degradación, sino frente al proveedor que falla a medias —lento o intermitente—. Con el proveedor caído, el circuit breaker basta por sí solo.

Detalle por sub-hipótesis — HA-08 (informe completo: Informe HA-08 · detallado)

Sub-hipótesis Veredicto Evidencia
HD-08.1 — La lectura directa sobre el modelo normalizado no alcanza el p95 objetivo Refutada Brazo A: p95 = 7,86 ms contra un umbral de 150 ms — 19× de margen, 0 % de error en las 9 corridas contrabalanceadas. Validado además con shared_buffers reducido 4× y el conjunto caliente dispersado: el p95 solo sube a 8,19 ms (+4,2 %).
HD-08.2 — La proyección materializada reduce el p95 en ≥ 60 % Refutada en magnitud Brazo B: p95 = 6,19 ms. La reducción real frente a A es del 21 %, no del 60 %, y representa < 1,2 % del umbral.
HD-08.3 — El caché en memoria aporta una mejora adicional Refutada en la dirección contraria Brazo C: p95 = 6,72 ms — 9 % peor que B. Con el hit-rate real (7,6 % a TTL 30 s) la mayoría de peticiones paga la serialización y escritura a Redis sin beneficiarse. Subir el TTL a 300 s eleva el hit-rate a 32-33 % pero empeora el p95.
HD-08.4 — El lag de la proyección se mantiene ≤ 2 s Aceptada Lag p95 ≤ 50 ms bajo carga concurrente de lectura y escritura (~5 eventos/s sostenidos).

Detalle por sub-hipótesis — HA-01 (informe completo: Informe HA-01)

Sub-hipótesis Veredicto Evidencia
HD-01.1 — Con el proveedor sano cumplen los tres brazos Confirmada p95: A 174,1 ms · B 64,9 ms · C 64,9 ms, contra un umbral de 225 ms.
HD-01.2 — Con el proveedor degradado solo cumple el brazo C Confirmada solo en parte C cumple en los seis estados. B también cumple en degradado, sin respuesta y caído; solo incumple con el proveedor lento (1,28 % sobre 475 ms) e intermitente (1,10–1,25 %).
HD-01.3 — El camino degradado es más rápido que el camino frío Depende del estado Solo se cumple con el interruptor abierto. Con el proveedor lento el interruptor nunca abre, y el camino degradado (189 ms) resulta más lento que el frío con proveedor sano (159 ms).
HD-01.4 — C sostiene el umbral con tasa de acierto ≥ 96 % Refutada En C el acierto no decide el percentil: el peor caso es ~190 ms con cualquier acierto, incluso al 50 %. Quien depende del acierto es B, cuyo mínimo está alrededor del 97 %.
HD-01.5 — Las peticiones sacrificadas hasta abrir el interruptor son < 1 % con tráfico alto Se mide en B, no en C En C las cuatro celdas cumplen con holgura porque ninguna petición espera más que el presupuesto: el efecto es invisible. En C el interruptor no protege la latencia, protege el pool y al proveedor.
HD-01.6 — Con tráfico bajo el umbral por conteo no mantiene las sacrificadas bajo el 1 %, y el de tasa sí Confirmada Política por conteo con tráfico bajo: 1,19 % sobre 475 ms y p99 de 716 ms — rompe el ASR. Política por tasa: 0,24 % (alto) y 0,77 % (bajo), nunca incumple.
HD-01.7 — Sin coalescencia, los fallos concurrentes sobre la misma clave saturan el pool Confirmada Celda de estampida (20 claves, TTL 2 s): C llega a 101 invocaciones en vuelo sobre un pool de 40; C′ coalesce 577 y queda en 20. La latencia apenas cambia (183 contra 184 ms).
HD-01.8 — Al recuperarse el proveedor, el interruptor cierra sin estampida en ≤ 60 s Confirmada El interruptor cierra entre 5 y 14 s; el respaldo vuelve bajo el 5 % entre 0 y 26 s; el pico de invocaciones no supera la línea base (8,4 contra 10,3/s).

Restricciones de presupuesto evaluadas en HA-01

Restricción Veredicto Evidencia
EC-LAT-08 — timeout duro de 700 ms en el adaptador Se cumple Aplicado de forma idéntica en los cuatro brazos; ninguna llamada lo excede.
EC-LAT-07 — ≤ 120 ms por dependencia externa Se incumple Con el proveedor lento, el p95 del adaptador cortado por fase es de 495,6 ms y el 99,78 % de sus llamadas excede el presupuesto. El único estado degradado en que se cumple es caído (19,7–85,1 ms), y se cumple por el interruptor, que al abrir corta las llamadas sin tocar al proveedor. Con el proveedor sano se cumple al filo: 114,9–121,8 ms.

El incumplimiento de EC-LAT-07 no debilita HD-01, la refuerza. Si la dependencia cupiera en 120 ms cabría preguntar para qué hace falta la actualización oportunista. Lo que muestra la evidencia es lo contrario: con el proveedor degradado la dependencia no cabe, y por eso el desacople no es una optimización sino la condición para cumplir el ASR de cotización. El brazo C cumple justamente porque abandona al agotar el presupuesto, que es el mecanismo bajo prueba.

El hallazgo principal de HA-01: el mérito del interruptor y el del desacople son separables

Con fallos intermitentes del 30 %, el circuit breaker no llega a abrir en ningún brazo —no se alcanzan diez fallos consecutivos ni el 50 % de la ventana, breaker_max = 0 en las ocho corridas— y aun así B incumple (1,10–1,25 %) y C cumple (0,00 %). Como el interruptor no interviene en ninguno de los dos, la diferencia es atribuible solo al desacople. Es el argumento más fuerte del experimento porque elimina la explicación alternativa, y se verificó bajo los dos modelos de fallo posibles (fallo atado al cliente y fallo derivado de un contador por petición), con el resultado manteniéndose en ambos.

Decisiones que merecen ser corregidas o revisadas (se materializan en §3.1)

# Decisión Estado
1 Atribuir la protección del presupuesto de latencia únicamente a la actualización oportunista (§1.2.4 semana 5) 🔧 Corregir — separar qué hace el interruptor y qué hace el desacople
2 Modelo de fallas de cinco estados del proveedor 🔧 Corregir — añadir intermitente; lento es el que materializa EC-LAT-09; degradado es en la práctica una caída
3 Política del interruptor sin definir 🔧 Decidir — adoptar por tasa sobre ventana deslizante; la de conteo rompe el ASR con tráfico bajo
4 EC-LAT-09 medido solo por latencia 🔧 Revisar — añadir la proporción con respaldo como segunda medida de respuesta
5 EC-LAT-07 como restricción de diseño (≤ 120 ms) Revisar — se incumple con el proveedor degradado; el diseño lo absorbe por abandono, pero la restricción debe redactarse con esa salvedad
6 CQRS para el estado de siniestro Confirmada su no adopción — HA-08 demuestra que no hace falta para EC-LAT-11
7 Umbral de respaldo aceptable para actuaría ⏳ Brecha abierta — no se resuelve con más corridas; requiere decisión de negocio

3. Documento de arquitectura ajustado

3.1 Modelos de arquitectura y diseño ajustados conforme a los resultados de experimentación

En la semana 6 solo se disponía del dictamen de HA-08, que confirmó la arquitectura vigente en vez de cambiarla: como las vistas publicadas nunca incorporaron el proyector, la proyección materializada ni el caché de estado, refutar la necesidad de CQRS no obligaba a modificar ningún diagrama.

Con HA-01 cerrado la situación es distinta. Su evidencia no contradice la topología publicada —el montaje no introdujo componentes nuevos: cada pieza corresponde a un «component» o «datastore» ya publicado—, pero sí obliga a corregir el razonamiento, el modelo de fallas, la redacción de dos escenarios de calidad y la parametrización de tres tácticas.

Ninguna vista cambia: no se añade, quita ni mueve un solo componente, conector, nodo ni entidad. Los modelos publicados se confirman tal como están y los ajustes se concentran íntegramente en el diseño detallado —parametrización de tácticas, razonamiento y redacción de escenarios—, que es donde la evidencia del experimento tiene efecto.

Alcance de lo validado. HA-01 ejercitó el camino de cotización (:MsCotización → :CacheOF → :AdaptadorOF). El camino de perfilamiento —el fan-out de :MsPerfilamiento hacia :AdaptadorOF y :AdaptadorOD, visible en el diagrama— comparte ese mismo adaptador y no se ejercitó.

Ajustes por vista y modelo

Vista / modelo Ajuste realizado conforme a la experimentación Modelo
Vista funcional — componentes Topología sin cambios; razonamiento corregido. Los cuatro componentes del camino de cotización (:MsCotización, :CacheOF, :AdaptadorOF, :MotorRaiting) y sus conectores se confirman: el brazo C validado es exactamente el modelo publicado. Lo que cambia es §1.2.4, que atribuía toda la protección del presupuesto a la actualización oportunista. La redacción ajustada separa los dos mecanismos: el circuit breaker protege frente al proveedor caído (fallo limpio y detectable); el desacople es el único que protege frente al proveedor lento o intermitente, donde el interruptor nunca llega a abrir porque el proveedor responde dentro del timeout duro.

Para la consulta de estado de siniestro se mantiene :MsSiniestros sobre :DBSiniestros sin proyector ni almacén de proyección —el brazo A validado por HA-08— y la réplica de :DBSiniestros sigue pasiva, fuera del camino de lectura.		 Ver modelo
Vista de despliegue — AWS Sin nodos nuevos, con una salvedad de alcance. HA-01 valida el diseño desplegado en el camino de cotización: ElastiCache Redis se confirma como :CacheOF —es la pieza que sostiene el ~96 % de resoluciones con dato real— y el grupo de escalado de cotización se confirma dimensionado: la latencia es plana de 20 a 200 sol/s (p95 de 65 ms, p99 entre 138 y 149 ms). HA-08 descarta introducir un nodo de proyector o una instancia de Redis para el estado de siniestro.

 Ver modelo
Vista de información Sin cambios en el modelo. Se conserva el esquema transaccional normalizado de siniestros —el desnormalizado siniestros_r existía solo en el montaje de HA-08 y no se promueve— y en el lado de cotización se confirma la política de valor de respaldo (§1.4.4): :CacheOF mantiene la copia local con último valor conocido, que es lo que el experimento validó.

El experimento hizo visible que el origen y la edad del dato con que se tarifica son observables y medibles —origen ∈ {cache, open_finance, fallback, default} y la antigüedad asociada, nula por diseño en el perfil por defecto, que no tiene marca de tiempo—. En esta iteración viven como instrumentación, que es el nivel en que la evidencia los respalda, y no se promueven a atributos persistidos de la entidad de cotización: hacerlo es una decisión de alcance que se evalúa en PF2 junto con el umbral de respaldo de actuaría. Ninguna entidad, relación ni clave del modelo cambia. 		Ver modelo
Diseño detallado — tácticas y patrones Es donde se concentran los ajustes. Cuatro cambios: (a) la táctica de circuit breaker se parametriza con política por tasa sobre ventana deslizante, no por conteo, con la evidencia de que la de conteo rompe el ASR con tráfico bajo (1,19 % sobre 475 ms, p99 de 716 ms); (b) el aislamiento de recursos se dimensiona por proveedor y por consumidor —hoy es solo por proveedor, y :MsCotización y :MsPerfilamiento comparten el pool de :AdaptadorOF pese a tener picos no correlacionados por diseño (§1.2.4); HA-01 midió 101 invocaciones en vuelo sobre un pool de 40, y como PoolTimeout se excluye del cómputo de fallas del proveedor el interruptor no abriría: la cotización se degradaría con el tercero sano y sin señal que lo explicara. Se dimensiona además sobre las tareas de refresco en segundo plano, no solo sobre las conexiones; (c) la coalescencia por clave (brazo C′) queda como táctica condicionada: con el patrón de acceso ensayado hubo 0 coalescencias, y donde sí aplica protege el pool y al proveedor, no el percentil; (d) se registra que EC-LAT-11 se satisface sin tácticas de separación del modelo de lectura, y que la evidencia de aislamiento de carga de HA-08 (~2,5× de CPU sobre PostgreSQL en el brazo A) queda como insumo para un experimento futuro sobre ese atributo, no de latencia. Ver diseño detallado
Escenarios de calidad Dos escenarios se ajustan y uno se matiza. EC-LAT-09 incorpora la proporción de cotizaciones resueltas con valor de respaldo como segunda medida de respuesta, junto a la latencia: el experimento demostró que el brazo A cumple el umbral con el proveedor caído tarifando el 98,9 % con perfil por defecto, es decir, cumpliendo la latencia por un camino que el propio diseño declara inaceptable. Además se declara que el estado que materializa su estímulo es lento (no responde dentro de su presupuesto), y se añade intermitente como sexto estado del modelo de fallas. EC-LAT-07 se mantiene como presupuesto objetivo pero se redacta con la salvedad medida: no se cumple frente a un proveedor degradado, y el diseño lo absorbe abandonando la espera, no haciendo caber la dependencia. Ver escenarios

4. Versión inicial del plan de trabajo Proyecto Final 2

4.1 Plan de trabajo para los sprints 1, 2 y 3

Tablero: SOLV — backlog por sprint · equipo Mauricio, Juan, Martin, John.

El alcance del Proyecto Final 2 se reparte en tres sprints (S1 de 2 semanas, S2 de 2 semanas, S3 de 3 semanas), con la velocidad del equipo detrás de cada cifra y con el Sprint 1 aliviado. Incluye las historias de pantalla del cliente asegurado que los recorridos críticos necesitan para poder recorrerse de punta a punta en la app, y la internacionalización del canal móvil (HU-94).

1. Resumen
Historias de usuario en SOLV (sin etiqueta ha) 131 HU · 342 SP (89 del backlog refinado, 31 de pantallas del cliente HU-90–HU-120 y 13 slices de BFF HU-121–HU-139)
De ellas, MVP (mvp) 111 HU · 247 SP
Capacidad de los tres sprints (velocidad calculada) 137 SP
Comprometido en el plan 130 SP · 69 HU
Holgura reservada 7 SP

Las historias de arquitectura (etiqueta ha, 23 en SOLV del catálogo HA-01–HA-31) quedan fuera de este conteo: no se desarrollan como producto. Cada una se evidencia con un experimento o spike sobre las HU que ya están en el sprint correspondiente (§7).

El catálogo MVP no cabe en 137 SP de capacidad. El plan no infla la velocidad ni recorta recorridos: acota el alcance de cada historia hasta que los seis recorridos del enunciado §5.1 quepan en la capacidad real, y declara explícitamente qué queda fuera (§6).

Los puntos de este documento son los del alcance acotado y son los mismos que están cargados en el tablero. No se maneja una doble cifra: el reestimado sustituyó al valor original del catálogo en cada historia de Jira, de modo que el tablero suma exactamente lo que dice §3.

El contrato de BFF se compromete como slices, no como paraguas. El borde de canal entra al plan con 13 slices de 1 SP del Backlog BFF · Web / Móvil y back-office, uno por recorrido y canal. Cada slice es trabajo de borde: vive en :BFFWeb o :BFFMovil, no en el núcleo ni en la UI, y se compromete solo si una historia de canal del plan lo consume. De los 21 del catálogo entran 13 por esa regla; los 8 restantes quedan fuera y su motivo está en §6.

2. Velocidad del equipo

Fuente: plantilla EstimaciónHUBase + VelocidadEquipo. No hay histórico de sprints — este es el primer sprint del equipo junto —, así que la velocidad se deriva de la estimación por desarrollador sobre la historia de referencia.

Conversión horas ↔ puntos. HU-6 (historia base, 5 SP) se desglosó en actividades técnicas y el planning poker de los cuatro integrantes (3, 5, 3, 3) dio 12 h para 5 SP → 2,4 h por punto de historia.

Capacidad por sprint.

Sprint 1 Sprint 2 Sprint 3
Semanas 2 2 3
Horas/semana por desarrollador 12 12 12
Desarrolladores 4 4 4
Capacidad bruta (h) 96 96 144
Horas transversales (refinamiento, daily, retro, planeación, revisión) 2 2 2
Capacidad neta (h) 94 94 142
÷ 2,4 h/SP → velocidad (SP) 39 39 59

Capacidad total de los tres sprints: 137 SP.

3. Distribución de los tres sprints

Se aplica la recomendación de la clase: el Sprint 1 no se carga igual que el Sprint 2 aunque ambos duren dos semanas, porque se va en organización del equipo, infraestructura, pipelines y primer contacto con el stack.

Sprint Semanas Velocidad Comprometido Holgura % de la velocidad
Sprint 1 2 39 33 6 85 %
Sprint 2 2 39 38 1 97 %
Sprint 3 3 59 59 0 100 %
Total 7 137 130 7 95 %

Colchón de S1: 15 %. El Sprint 1 carga 33 de sus 39 SP. Las 6 SP de colchón no se redistribuyen: absorben el arranque del equipo. La semana de receso se usa para dejar instalado el tutorial, las imágenes base y una corrida de prueba de los GitHub Actions; si eso se cumple, el colchón queda disponible para adelantar historias de S2.

Sprint 3 al 100 %. Los ocho slices de BFF que cierran los recorridos #2 a #6 caben en el sprint porque el alcance de cuatro historias se ajustó a lo que el recorrido exige: HU-20, HU-30 y HU-55 entregan su resultado verificable en 2 SP y HU-59 en 1. Es el mismo criterio de §5 aplicado a la última iteración del plan.

Tema de cada sprint

Sprint Tema Recorridos §5.1 que quedan cerrados al final
S1 Fundación + motor de cotización + reconsulta + harness web y móvil — (núcleo del #1 sin canal)
S2 Recorrido #1 completo con canal, BFF, carga e identidad; app móvil navegable e internacionalizada; núcleo del #2 #1 cotización embebida
S3 Cierre de los cinco recorridos restantes, login y estados de canal #2, #3, #4, #5, #6

4. Criterio de asignación

En este orden:

  1. ASR de latencia y escalabilidad primero. El equipo tomó EC-LAT-* y EC-ESC-* (HA-01–HA-13). Las HU que sostienen esos escenarios (cotización, emisión, perfilamiento, paramétrico) entran antes que las que no tienen ASR asociado. Por eso el ciclo de vida de póliza (#6, sin ASR LAT/ESC) cierra en S3 y es el primero en adelgazarse.
  2. El lab antes del experimento. Repos, imágenes, nube, dobles y ambiente de carga están en S1/S2 porque sin ellos no hay evidencia que mostrar de HA-01, HA-02, HA-07, HA-09 y HA-10.
  3. Móvil desde el Sprint 1. S1 monta el harness JUnit, S2 entrega la app navegable (shell, idioma, onboarding, oferta) y S3 cierra los recorridos. Detalle en §8.
  4. Dependencias INVEST. Catálogo → prima → oferta → aceptación → emisión. Consentimiento antes del adaptador de perfilamiento. Cada slice de BFF viaja en el mismo sprint que la pantalla que lo consume, nunca después: por eso HU-122, HU-123, HU-125, HU-126 y HU-139 caen en S2 y los ocho restantes en S3. Shell e idioma antes de las pantallas que formatean moneda y fecha (HU-93/HU-94 junto a HU-11). Login junto al validador JWT móvil (HU-90 con HU-76).
  5. Recorrido recorrible, no solo demostrable. Una historia de pantalla del cliente entra si sin ella el recorrido no se puede completar en la app (entrar, navegar, pedir permiso al SO, ver el resultado de negocio). Las que agregan riqueza a un recorrido que ya cierra quedan fuera (§6).

5. Alcance acotado por historia

El catálogo MVP no cabía en 137 SP de capacidad. La diferencia se cerró adelgazando el alcance de cada historia, no eliminando recorridos. Tres movimientos:

a) Historias ya resueltas en Proyecto Final 1. Los mockups navegables web y móvil ya se construyeron y se validaron con usuarios en las semanas 6–7; la infraestructura IaC y el ambiente de experimentos ya están montados y corriendo. Esas historias se cierran con la evidencia existente o se reestiman a lo que falta (versionar, hacer destruible, documentar).

b) Fusiones. Una capacidad, una historia: la foto entra dentro del aviso de siniestro; la consulta ligera de póliza es la misma consulta de póliza; un solo validador de JWT sirve a web y móvil; un solo mecanismo de aviso in-app cubre estado de siniestro y pago paramétrico.

c) Canal delgado. Las reglas del canal están en §11. En resumen: una vista por paso del recorrido, sin estados vacíos ricos, errores solo donde el negocio, el sistema operativo o el ASR los imponen, e internacionalización acotada a formato regional en el canal móvil. Las UIs bajan de 3–5 SP a 1–3 SP.

Alcance por historia
HU SP Alcance comprometido
HU-3 Recibir solicitud de cotización 2 Contrato mínimo; el cotizacionId no persiste histórico en MVP
HU-5 Combinar factor de riesgo (stub) 2 Stub de 2 atributos + valor de respaldo; sin caché de perfil (eso es HA-07)
HU-11 Ver oferta (Android) 3 Una pantalla de precio firme; formato por locale de HU-94
HU-13 Decisión automática de suscripción 2 Regla única aceptar/rechazar con motivo
HU-15 Cobro de prima (stub) 2 Solo clave de idempotencia; sin conciliación
HU-19 UI web suscripción y emisión 2 Canal delgado
HU-20 UI móvil aceptar y póliza 2 Emitiendo → póliza emitida, sin navegación visible
HU-22 Reportar siniestro 2 Formulario único que absorbe HU-23 (foto); permiso y confirmación van en HU-101 / HU-97
HU-26 Ver aviso en back-office 2 Una pantalla de lectura
HU-29 Pagar siniestro de bajo monto 2 Stub idempotente, sin autorización por montos
HU-31 Lista de siniestros (Android) 2 Lista con estado; absorbe el aviso in-app de HU-35
HU-32 / HU-34 Evento y pago paramétrico 2 / 2 Stub con un valor comparable; la historia no implementa reintentos ni DLQ: esa capacidad se diseña y se mide en HA-11, aunque el criterio de aceptación cite la meta del escenario
HU-36 Vista móvil paramétrico 2 Canal delgado; absorbe la traza de HU-37
HU-45 Onboarding con datos y documento 2 Sin OCR ni validación externa del documento
HU-46 Consentimiento de datos 2 Otorgar/revocar con auditoría; la propagación es HA-21
HU-54 Adaptadores stub OF/OD 2 Dos atributos propios detrás del adaptador
HU-55 Perfil y oferta explicable 2 Factores internos en lista, sin visualización
HU-56 Degradar perfilamiento lento 2 Timeout + valor de respaldo
HU-59 Renovar póliza 1 Un verbo, un comando, sin recálculo de prima
HU-71 Imágenes Docker base 2 Base ya construida en PF1; se documenta y se versiona
HU-121…HU-139 Slices de BFF (13) 1 c/u Un slice por recorrido y canal. Contrato de Solventa sobre stub ok / fallo / lento; sin OpenAPI de proveedores
HU-30 Estados del siniestro 2 Máquina de estados del siniestro y su lectura; sin histórico de transiciones
HU-74 Validar JWT Web 1 Validación sobre el gateway existente; sin emisión ni rotación de token
HU-75 Autorizar roles Web 2 RBAC sobre el gateway existente
HU-76 Validar JWT Móvil 2 Absorbe HU-77 (mismo validador, misma política de roles)
HU-78 Red y clúster cloud 3 IaC de PF1; falta versionarlo y hacerlo destruible
HU-79 Pruebas de carga de cotización 3 Script K6 del experimento PR-01 reutilizado
HU-83 Framework E2E 1 Runner instalado y un recorrido feliz web corriendo en CI; el E2E móvil pasa a operación
HU-86 / HU-87 Harness Karma y JUnit 2 / 2 CI ya existe; se agrega el runner y un caso semilla
HU-88 Ambiente de integración con dobles 3 Los dobles ya existen del experimento PI-01; falta Pact
HU-89 Ambiente cloud de experimentos 3 Ya montado en PF1; se versiona y se documenta
HU-8 / HU-10 / HU-57 UIs web y móvil 2 c/u Canal delgado
HU-90 Login con correo y contraseña 2 Correo + contraseña; error de credenciales y de red inline en la misma vista; sin recuperación de contraseña ni biometría
HU-93 Shell de navegación cliente (Android) 2 NavigationBar de 4 destinos que alojan las pantallas ya comprometidas; Inicio con los CTA de los recorridos (sin el Inicio rico de HU-96); Perfil solo con la entrada a Idioma y región
HU-94 Idioma y región (Android) 3 Sin recorte: selector al primer arranque + cambio desde Perfil, 4 locales y formato de moneda y fecha en todas las pantallas móviles
HU-97 Confirmación de aviso de siniestro (Android) 1 Estado final de HU-22 con siniestroId y salida a la lista
HU-99 UI de suscripción rechazada (Android) 1 Estado de rechazo dentro del flujo de HU-20 con motivo y volver a Inicio
HU-101 Permisos JIT de cámara y fotos 2 Rationale + diálogo del SO al evidenciar; estado de permiso denegado en la misma ruta

Efecto: 130 SP comprometidos en 69 HU + 117 SP declarados fuera (§6). Los seis recorridos del enunciado §5.1 cierran.

6. Plan por sprint

Cómo leer estas tablas. La columna SP es el valor comprometido, el mismo que está cargado en el tablero. La columna Nivel de dependencia dice qué tan abajo en la cadena está la historia: las de nivel 1 no dependen de ninguna otra y arrancan primero; una de nivel 3 necesita que las de nivel 1 y 2 estén terminadas. No es prioridad de negocio ni orden de ejecución dentro del sprint — eso está en §9.

Sprint 1 — 33 SP · 14 HU
Jira HU Nombre Épica Nivel de dependencia SP
SOLV-94 HU-1 Catálogo mínimo (1 ramo) E1 1 2
SOLV-95 HU-2 Publicar catálogo al socio E1 1 2
SOLV-96 HU-3 Recibir solicitud de cotización E1 1 2
SOLV-97 HU-4 Calcular prima con reglas E1 1 5
SOLV-98 HU-5 Combinar factor de riesgo (stub) E1 1 2
SOLV-99 HU-6 Devolver oferta en firme E1 1 2
SOLV-100 HU-7 Reconsultar oferta por id E1 2 2
SOLV-163 HU-70 Repositorios del equipo E7 1 2
SOLV-164 HU-71 Imágenes Docker base E7 1 2
SOLV-171 HU-78 Red y clúster cloud (mínimo) E7 1 3
SOLV-178 HU-85 Harness unitario del núcleo (PyTest) E7 1 2
SOLV-179 HU-86 Harness unitario web (Karma) E7 2 2
SOLV-180 HU-87 Harness unitario móvil (JUnit) E7 2 2
SOLV-182 HU-89 Ambiente cloud de experimentos E7 1 3
Sprint 2 — 38 SP · 19 HU
Jira HU Nombre Épica Nivel de dependencia SP
SOLV-101 HU-8 Shell UI Web E1 3 2
SOLV-103 HU-10 UI web cotización E1 3 2
SOLV-104 HU-11 Ver oferta (Android) E1 3 3
SOLV-105 HU-12 Aceptar oferta vigente E2 2 2
SOLV-106 HU-13 Decisión automática de suscripción E2 2 2
SOLV-108 HU-15 Cobro de prima (stub idempotente) E2 2 2
SOLV-109 HU-16 Emitir póliza E2 2 3
SOLV-110 HU-17 Firma electrónica (stub) E2 2 2
SOLV-138 HU-45 Onboarding con datos y documento E4 3 2
SOLV-139 HU-46 Consentimiento de datos E4 3 2
SOLV-218 HU-93 Shell de navegación cliente (Android) E4 3 2
SOLV-219 HU-94 Idioma y región (Android) E4 3 3
SOLV-172 HU-79 Pruebas de carga de cotización E7 1 3
SOLV-181 HU-88 Ambiente de integración con dobles E7 1 3
— HU-122 BFF web sesión e identidad E7 2 1
— HU-123 BFF móvil alta y consentimiento E7 2 1
— HU-125 BFF móvil cotización y oferta E7 2 1
— HU-126 BFF web cotización y oferta E7 2 1
— HU-139 BFF web cartera del asesor E7 2 1
Sprint 3 — 59 SP · 36 HU
Jira HU Nombre Épica Nivel de dependencia SP
SOLV-111 HU-18 Consultar póliza emitida E2 3 2
SOLV-112 HU-19 UI web suscripción y emisión E2 3 2
SOLV-113 HU-20 UI móvil aceptar y póliza E2 3 2
SOLV-223 HU-99 UI de suscripción rechazada (Android) E2 3 1
SOLV-115 HU-22 Reportar siniestro E3 3 2
SOLV-224 HU-101 Permisos JIT de cámara y fotos E3 3 2
SOLV-221 HU-97 Confirmación de aviso de siniestro (Android) E3 3 1
SOLV-119 HU-26 Ver aviso en back-office E3 3 2
SOLV-120 HU-27 Aprobar o rechazar aviso E3 3 2
SOLV-122 HU-29 Pagar siniestro de bajo monto (stub) E3 3 2
SOLV-123 HU-30 Estados del siniestro E3 3 2
SOLV-124 HU-31 Lista de siniestros (Android) E3 3 2
SOLV-125 HU-32 Recibir evento paramétrico (stub) E3 3 2
SOLV-126 HU-33 Evaluar umbral paramétrico E3 3 2
SOLV-127 HU-34 Disparar pago paramétrico (stub) E3 3 2
SOLV-129 HU-36 Vista móvil paramétrico E3 3 2
SOLV-146 HU-53 Consentimiento de perfilamiento E5 2 2
SOLV-147 HU-54 Adaptadores stub Open Finance / Open Data E5 2 2
SOLV-148 HU-55 Perfil y oferta explicable E5 2 2
SOLV-149 HU-56 Degradar perfilamiento lento E5 2 2
SOLV-150 HU-57 UI móvil oferta vida hipotecario E5 3 2
SOLV-152 HU-59 Renovar póliza E6 4 1
SOLV-154 HU-61 Cancelar póliza E6 4 2
SOLV-215 HU-90 Login con correo y contraseña E4 3 2
SOLV-167 HU-74 Validar JWT Web E7 3 1
SOLV-168 HU-75 Autorizar roles Web E7 3 2
SOLV-169 HU-76 Validar JWT Móvil E7 3 2
SOLV-176 HU-83 Framework E2E E7 1 1
— HU-121 BFF móvil sesión e identidad E7 2 1
— HU-127 BFF móvil aceptar, emitir y billetera E7 2 1
— HU-128 BFF web aceptar, emitir y consultar póliza E7 2 1
— HU-129 BFF móvil aviso, evidencia y estado E7 2 1
— HU-130 BFF web siniestros cliente y cola operador E7 2 1
— HU-131 BFF móvil pago automático E7 2 1
— HU-133 BFF móvil perfil y oferta hipotecario E7 2 1
— HU-136 BFF web ciclo de vida de póliza E7 2 1
Fuera del compromiso — 117 SP

Backlog refinado (47 SP)

Jira HU Nombre SP Motivo
SOLV-102 HU-9 Mockup Web 3 Resuelta en PF1
SOLV-107 HU-14 Reconstruir decisión de suscripción 3 Diferida
SOLV-116 HU-23 Una foto del siniestro 3 Fusionada en HU-22
SOLV-117 HU-24 Geoetiquetar evidencia 3 Diferida
SOLV-118 HU-25 Conservar evidencia sin red 5 Diferida (sin frame Figma)
SOLV-121 HU-28 Enrutar aviso a perito 2 Diferida
SOLV-128 HU-35 Aviso de pago paramétrico 2 Fusionada en HU-31
SOLV-130 HU-37 Vista web paramétrico 2 Fusionada en HU-36
SOLV-137 HU-44 Mockup Móvil 3 Resuelta en PF1
SOLV-140 HU-47 Consulta de póliza 3 Fusionada en HU-18
SOLV-151 HU-58 UI web perfil y oferta 3 Fusionada en HU-57
SOLV-153 HU-60 Modificar póliza 3 Diferida
SOLV-155 HU-62 Reporte al regulador (stub) 3 Diferida
SOLV-156 HU-63 Reporte a reaseguradora (stub) 3 Diferida
SOLV-157 HU-64 Aviso de vencimiento 2 Diferida
SOLV-158 HU-65 Aviso de renovación efectiva 2 Fusionada en HU-31
SOLV-170 HU-77 Autorizar roles Móvil 2 Fusionada en HU-76

Pantallas del cliente no comprometidas (70 SP)

HU Nombre SP Motivo
HU-91 Hub Perfil y cierre de sesión 3 Perfil mínimo vive en HU-93
HU-92 Cotización in-app (1 ramo) 3 Opcional: el #1 lo inicia socio (HU-3) o asesor (HU-10)
HU-95 Splash de primer arranque 2 La app abre en Idioma y región (HU-94)
HU-96 Inicio 3 Inicio mínimo con CTA dentro de HU-93
HU-98 Detalle de siniestro 3 Sin frame Figma (G-03); el estado se ve en HU-31
HU-100, HU-102–HU-120 Portal web del cliente (20 HU) 56 El canal web del plan son los portales de asesor y operador; los recorridos ya cierran en web con ellos

Estas 117 SP no son deuda oculta: son historias mvp que el equipo decide no comprometer en el Proyecto Final 2 y que quedan en el tablero con su prioridad original. Nueve desaparecen por fusión o porque ya están resueltas (HU-9, HU-23, HU-35, HU-37, HU-44, HU-47, HU-58, HU-65, HU-77); ocho son diferimientos que no rompen ningún recorrido §5.1 (HU-14, HU-24, HU-25, HU-28, HU-60, HU-62, HU-63, HU-64), y las pantallas del cliente restantes son riqueza sobre recorridos que ya cierran.

7. Evidencia de los ASR por sprint

Las HA no consumen velocidad de producto. Cada una se ejecuta como experimento sobre las HU que ya están en el sprint; el esfuerzo (45 SP de HA-01–HA-11) es diseño, corrida, análisis y nota de arquitectura, y se reparte entre los cuatro integrantes fuera del compromiso de producto.

Sprint HA que se evidencian HU habilitadoras ya en el sprint Qué se corre
S1 — HU-1…HU-7, HU-78, HU-89 Línea base de latencia en local y en el ambiente de experimentos (no es aún evidencia formal)
S2 HA-01 p95 ≤ 250 ms · HA-02 p99 ≤ 500 ms · HA-07 degradación · HA-09 50k cot/min · HA-10 autoescalado ≤ 60 s HU-1…HU-7, HU-79, HU-88, HU-89 Campaña K6 sobre cotización en el ambiente de experimentos; stub lento para HA-07
S3 HA-05 p95 aceptación→póliza ≤ 1,5 s · HA-06 p99 ≤ 3 s · HA-03 p95 perfilamiento ≤ 400 ms · HA-04 p99 ≤ 800 ms · HA-08 p95 estado de siniestro ≤ 150 ms · HA-11 1M eventos/10 min HU-12…HU-17, HU-53…HU-56, HU-26, HU-30, HU-31, HU-32…HU-34 Reloj extremo a extremo del recorrido #2; medición sobre el stub OF/OD; ráfaga de eventos contra el canal paramétrico

Correspondencia de códigos. Las historias de arquitectura se nombran HA-xx en el tablero y EC-* en la hoja de escenarios de calidad: son el mismo escenario con dos numeraciones. HA-01 ↔ EC-LAT-01, HA-02 ↔ EC-LAT-02, HA-03 ↔ EC-LAT-03, HA-04 ↔ EC-LAT-04, HA-05 ↔ EC-LAT-05, HA-06 ↔ EC-LAT-06, HA-07 ↔ EC-LAT-08, HA-08 ↔ EC-LAT-11 y HA-11 ↔ EC-ESC-03. El procesamiento exactamente una vez (EC-ESC-04) y la consulta de póliza (EC-LAT-10) no tienen historia de arquitectura propia: se verifican dentro de la aceptación de HU-32/HU-34 y HU-18 respectivamente.

HA-13 (aislamiento de cuota entre socios) queda como spike de SBA solo si sobra cupo en S3: su producto, HU-81, es ola 5 y está fuera del MVP. HA-14–HA-31 (disponibilidad, seguridad, modificabilidad, integrabilidad) no ordenan el tablero SOLV en este corte. HU-94 no altera HA-01/HA-02: el núcleo sigue devolviendo solo prima y código de moneda, y el formato ocurre en el canal (PL-01).

8. Estrategia de canal móvil

El canal móvil tiene bus factor 1 (John es el único con Kotlin/Jetpack y Swift). Dejarlo para el final es el patrón que hace que los equipos no cierren el Proyecto Final 2, así que el plan lo ataca desde el Sprint 1:

Sprint Entregable móvil SP
S1 HU-87 harness JUnit de Kotlin en CI, sin emulador 2
S2 HU-93 shell de navegación (2) + HU-94 idioma y región (3) + HU-45 onboarding (2) + HU-46 consentimiento (2) + HU-11 ver oferta (3) + BFF móvil HU-123 y HU-125 (1 + 1) 14
S3 HU-90 login (2) + HU-76 JWT móvil (2) + HU-20 aceptar y póliza (2) + HU-99 rechazo (1) + HU-22 reportar siniestro (2) + HU-101 permisos (2) + HU-97 confirmación (1) + HU-31 lista de siniestros (2) + HU-36 paramétrico (2) + HU-57 hipotecario (2) + HU-53 consentimiento hipotecario (2) + BFF móvil HU-121, HU-127, HU-129, HU-131 y HU-133 (1 c/u) 25

41 SP de los 130 tocan el canal móvil, pero solo 34 son Kotlin. Los 7 slices de :BFFMovil son código de servidor: sirven a la app, no se escriben en ella. Eso importa para el bus factor, porque esos 7 SP los puede tomar cualquiera del equipo sin depender de John. HU-53 lleva etiqueta de núcleo en el tablero, pero su pantalla de consentimiento hipotecario la construye el canal Android, así que cuenta como carga móvil. La carga supera lo que una sola persona entrega en S2 y S3, así que el trabajo en pareja es obligatorio desde S2: cada HU móvil tiene a John como revisor y a un segundo integrante (Python/React) como autor en las de menor riesgo técnico (HU-94, HU-97, HU-99, HU-31). El harness JUnit de S1 existe precisamente para que ese segundo integrante pueda tocar el módulo con red de seguridad. El E2E móvil se sacrifica conscientemente antes que el producto móvil.

Recorrido del cliente en Android:

Primer arranque  Idioma y región (HU-94) → Onboarding (HU-45) | Login (HU-90) → Consentimiento (HU-46) → Inicio (HU-93)
#1  Inicio → Ver oferta (HU-11)
#2  Ver oferta → Emitiendo → Póliza emitida (HU-20) | Rechazo (HU-99)
#3  Siniestros (HU-31) → Reportar (HU-22) → Permiso (HU-101) → Confirmación (HU-97)
#4  Aviso in-app (HU-31) → Paramétrico (HU-36)
#5  Inicio → Consentimiento de perfilamiento (HU-53) → Oferta hipotecario (HU-57)
#6  Póliza emitida (HU-20) · renovar y cancelar por operador (HU-59, HU-61)

9. Arranque del backlog del Sprint 1

Los criterios de aceptación definitivos viven en Jira. Cada una de las 58 historias comprometidas tiene en su descripción: aceptación en viñetas, Gherkin con camino feliz y alterno, dependencias y bloque Fuera; las de canal traen además navegación, prototipo, enlace de Figma e imagen. La tabla siguiente es el resumen de arranque del Sprint 1.

Orden de ejecución dentro del S1

HU-70 ──▶ HU-71 ──┬──▶ HU-78 ──▶ HU-89
                  ├──▶ HU-85 ──▶ HU-1 ──▶ HU-2
                  │               └────▶ HU-3 ──▶ HU-4 ──▶ HU-5 ──▶ HU-6 ──▶ HU-7
                  ├──▶ HU-86  (paralelo, canal web)
                  └──▶ HU-87  (paralelo, canal móvil)

Detalle inicial

HU Criterio de aceptación Esquema de pruebas
HU-70 Repositorios Tres repos (web, móvil, backend) con protección de rama, plantilla de PR y CODEOWNERS; el equipo completo tiene acceso Verificación manual + un PR de humo por repo
HU-71 Imágenes Docker base Una imagen base documentada que arranca igual en local y en CI; docker build reproducible Job de CI que construye la imagen y corre --version de las herramientas
HU-78 Red y clúster cloud IaC versionado que levanta y destruye el ambiente mínimo; terraform destroy deja la cuenta limpia terraform plan en CI + corrida completa apply/destroy documentada
HU-89 Ambiente de experimentos Ambiente separado del de HU-78, con K6 instalado y apuntando al servicio de cotización Corrida de humo de K6 con 10 usuarios virtuales
HU-85 Harness PyTest PyTest corre en CI sobre el dominio Python y falla el pipeline ante un test rojo Un test semilla del cálculo de prima
HU-86 Harness Karma web Karma corre en CI sobre el proyecto web y falla el pipeline ante un test rojo Un test semilla de un componente
HU-87 Harness JUnit móvil JUnit de Kotlin corre en CI sin emulador y falla el pipeline ante un test rojo Un test semilla de la capa de presentación
HU-1 Catálogo mínimo Un ramo con coberturas fijas persistido; misma definición para todos los canales Unitaria de dominio
HU-2 Publicar catálogo GET del catálogo devuelve el ramo y sus coberturas Unitaria + contrato
HU-3 Recibir solicitud POST con producto y datos mínimos devuelve cotizacionId; entrada inválida devuelve error de validación Unitaria + contrato
HU-4 Calcular prima Mismos insumos → misma prima; las reglas viven fuera del código compilado Unitaria con tabla de casos (es la historia base de la estimación)
HU-5 Combinar factor (stub) El adaptador ajusta la prima; si el stub falla o tarda, se usa el valor de respaldo y la cotización se completa Unitaria + doble con modos ok/fallo/lento
HU-6 Devolver oferta La oferta trae prima, moneda y venceEn; se puede recuperar dentro de la vigencia Unitaria + contrato
HU-7 Reconsultar oferta GET por cotizacionId devuelve la misma oferta sin recalcular mientras esté vigente; vencida devuelve estado explícito Unitaria + contrato

Definición de terminado

  • Todas las HU: código en main vía PR revisado · pruebas unitarias verdes en CI · imagen construida por el pipeline · IaC aplicable y destruible · historia demostrable en la revisión de sprint.
  • HU móviles (desde S2): además, revisión de John · textos y formato de moneda y fecha a través del formateador de HU-94 (sin cadenas de moneda armadas a mano) · seleccionado con borde + check + texto, no solo color.
  • HU de un recorrido medido: su aceptación cita el escenario de calidad con su meta (p. ej. EC-LAT-01, p95 ≤ 250 ms) y la historia no se cierra sin ese dato. Aplica a HU-3 a HU-7, HU-12 a HU-18, HU-31, HU-32 a HU-34, HU-53 a HU-56.

10. Internacionalización (HU-94)

Alcance comprometido
Canal Android (app del cliente)
Locales es-CO, es-MX, es-CL, es-PE
Qué cambia por locale Formato de moneda y de fecha en el canal (p. ej. es-MX → $1,234.56 MXN, 09/07/2026)
Dónde se elige Primer arranque (antes de onboarding) y Perfil (entrada mínima dentro de HU-93), sin reiniciar el alta
Contrato con el núcleo El núcleo devuelve solo prima y código de moneda (PL-01); no se traduce ni se formatea en el backend
Fuera Traducir el núcleo · idiomas distintos al español · locales fuera de LatAm · paridad web HU-108 · portales de asesor y operador (quedan en es-CO)

11. Restricciones de alcance

Reglas vigentes para todo el plan; cualquier otra mención en el tablero o la wiki se lee contra esta lista.

# Regla
R1 Internacionalización acotada a lo definido en §10
R2 Una vista por paso del recorrido en cada canal (canal delgado, §5c); no se agregan vistas que no sean paso del recorrido
R3 Solo cuatro variantes de error: degradación del ASR · resultado de negocio (rechazo, HU-99) · permiso denegado por el sistema operativo (HU-101) · credenciales inválidas o fallo de red resueltos en la misma vista (HU-90)
R4 Sin estados vacíos ricos
R5 El colchón de S1 (6 SP) no se redistribuye
R6 HU-22 es un formulario único con foto; el permiso (HU-101) y la confirmación (HU-97) son historias propias
R7 Sin OCR ni validación externa del documento (HU-45) · sin caché de perfil (HU-5) · sin histórico de cotizacionId (HU-3) · regla única de suscripción (HU-13) · sin conciliación (HU-15) · sin autorización por montos (HU-29) · sin reintentos ni DLQ (HU-32 / HU-34) · sin visualización de factores (HU-55) · sin recálculo de prima (HU-59)
R8 El E2E móvil queda fuera de HU-83
R9 HA-14 a HA-31 no ordenan el tablero; HA-13 entra solo si sobra cupo en S3
R10 Sin recuperación de contraseña ni biometría (HU-90) · sin splash (HU-95) · sin notificaciones push ni campana · sin cierre de sesión en Perfil (HU-91)
R11 El BFF entra como 13 slices de 1 SP, no como contrato paraguas. Un slice solo entra si una HU de canal comprometida lo consume; los 8 restantes del catálogo quedan fuera (§6)
R12 El destino Clientes del back-office se llama Cartera y muestra lo que sostiene HU-139. No se construye CRUD de clientes (HU-140 / HU-141): el enunciado no lo pide

4.2 Detalle de historias de usuario refinadas para el Sprint 1

Backlog del Sprint 1 en Jira: SOLV — Sprint 1

Criterio de «historia refinada». Una HU está refinada cuando su descripción en Jira trae las 7 piezas del modelo de referencia (SOLV-215 · HU-90 Login):

# Pieza Qué contiene
1 Como / quiero / para Rol, capacidad y beneficio
2 Figma Etiquetas Ejecutar en Figma: (prototipo navegable) y Pantalla en Figma: (frame)
3 Imagen Captura del frame embebida en la historia
4 Navegación De dónde llega, a dónde sale, qué barra se ve
5 Criterios de aceptación Lista de viñetas verificables
6 Gherkin Mínimo 2 escenarios: camino feliz + alterno o de error
7 Paridad y Fuera Gemelo del otro canal y qué no incluye

Las 69 historias comprometidas están refinadas, incluidas las 14 del Sprint 1. Cada una tiene en Jira su lista de criterios de aceptación, Gherkin con camino feliz y camino alterno, dependencias y bloque Fuera; las 24 que tienen pantalla traen además navegación, prototipo, enlace de Figma e imagen del frame, y los 13 slices de BFF declaran los servicios que consumen y la historia de canal que los usa.

Grupo HU Criterios y Gherkin Prototipo, Figma e imagen
Historias con pantalla 24 ✅ ✅
Núcleo, API e infraestructura 29 ✅ ➖ no aplica
Técnicas de pruebas (HU-83, HU-86, HU-87) 3 ✅ ➖ no aplica
Slices de BFF del borde de canal 13 ✅ ➖ no aplica
Total 69

Las historias que pertenecen a un recorrido medido citan además el escenario de calidad con su meta: HU-6 y HU-7 el presupuesto de la cotización (EC-LAT-01 / EC-LAT-02), HU-13 el de suscripción y emisión (EC-LAT-05 / EC-LAT-06), HU-18 y HU-31 el de consulta (EC-LAT-10 / EC-LAT-11), HU-33 el pico paramétrico (EC-ESC-03 / EC-ESC-04), HU-53 la revocación del consentimiento (EC-SEG-03) y HU-55 el perfilamiento en línea (EC-LAT-03 / EC-LAT-04) junto con la reconstrucción de decisiones (EC-SEG-04).

La evidencia viva, historia por historia, está en el tablero de Jira.

5. Plan de trabajo y tablero

Se evidencia actualización del plan de trabajo y tablero en la plataforma seleccionada por el equipo: Jira.

6. Video con evidencias

Video de showcase con las evidencias de la semana 7: prototipo final navegable (web, móvil y back-office), resultados finales de los dos experimentos, ajustes al documento de arquitectura y plan de trabajo del Proyecto Final 2.

⚠️ **GitHub.com Fallback** ⚠️