validacion SOLV_epics_HUs_semana 3 - martin-hendricks/MISO-PROYECTO-FINAL-SOLVENTA GitHub Wiki

Validación — SOLV_epics_HUs_semana-3_jira_import.csv

Archivo validado: MISO-PROYECTO-FINAL-SOLVENTA.wiki/files/SOLV_epics_HUs_semana-3_jira_import.csv Fecha: 2026-08-23 Alcance: formato/estructura de importación a Jira + formato y contenido de las 89 HU funcionales (SOLV). Fuera de alcance por decisión del equipo: detalle de historias de arquitectura (HA/SBA, ya validado aparte), capacidad del equipo, y contenido propio de los escenarios de calidad (solo se valida la relación HA→HU).

Fuentes usadas: Backlog-refinado-semana-3.md, Backlog-Jira.md, Rúbricas Proyecto 1 v5.pdf (semana 3), MISW4501-202614-Proyecto.pdf (caso Solventa), notebook NotebookLM de testing/BDD, notebook NotebookLM de arquitectura (historias de arquitectura y escenarios de calidad).

1. Formato de importación a Jira (estructura del CSV)

Check Resultado
Columnas consistentes en las 96 filas de datos ✅ OK
Issue ID únicos, sin duplicados ✅ OK
Parent ID de cada Story apunta a un Issue ID de Epic existente ✅ OK
Epic Link de cada Story coincide textualmente con Epic Name de su épica padre ✅ OK (Jira resuelve el link por texto, no por ID)
Épicas sin Parent ID ni Epic Link propio; Stories sin Epic Name propio ✅ OK
4 columnas Labels (multi-valor) sin espacios ni caracteres inválidos ✅ OK
Cada Story con ≥1 label de plataforma (web/mobile/api/core/devops) y ≥1 de alcance (mvp/post-mvp) ✅ OK — 0 excepciones
Summary sin duplicados ✅ OK
Priority solo con valores válidos de Jira (Highest/High/Medium/Low/Lowest) ✅ OK
HU-1 a HU-89 completas, sin huecos ni repetidos ✅ OK — 89/89
7 épicas presentes (E1–E7) ✅ OK

Conclusión: el archivo está listo para importar en Jira sin errores estructurales.

2. Cobertura vs. rúbrica de Semana 3 (100 pts)

Ítem rúbrica Puntos Cubierto por este CSV
1. Escenarios de calidad (≥2 por requisito) 20 ❌ No — vive en Hoja-de-trabajo.md / Escenarios-de-calidad-ajustados-hoja-de-trabajo.md (fuera de alcance de esta validación)
2a. HU web y móvil 15 ✅ Sí
2b. Detalle de historias de arquitectura 15 ❌ No — vive en historias-arquitectura-solventa-jira-v2.csv (ya validado aparte)
2c. Priorización por importancia 10 ⚠️ Parcial — ver sección 5
2d. Capacidad del equipo (pts/historia por semana) 10 ❌ No aplica a este archivo (fuera de alcance)
3–6. Estrategia de pruebas, frameworks, plan/tablero, showcase 45 Fuera de alcance de este CSV

3. Formato/estructura de las 89 HU (Como / quiero / para)

Criterio base: convención de la wiki (Backlog-refinado-semana-3.md línea 229, INVEST) + reglas de redacción confirmadas en el notebook de arquitectura (aplican por igual a HU funcionales y a historias de arquitectura, ya que ambas comparten la misma plantilla narrativa).

Regla Resultado
Plantilla Como X, quiero Y, para Z. 88/89 OK. Única excepción: HU-66 "Autoservicio web" — falta la cláusula "para..." (defecto heredado del catálogo fuente en la wiki, no introducido al exportar el CSV).
Atomicidad: una sola meta por historia (sin "quiero...y quiero...") ✅ 89/89 — ninguna HU mezcla dos objetivos en un mismo "quiero"
No partir la historia por capa técnica (tabla/endpoint/DTO) ✅ OK — todas describen comportamiento observable por un actor, no artefactos técnicos aislados
Testeable / verificable (criterio BDD: debe poder traducirse en Given-When-Then con oráculo claro) ✅ OK en general — los "quiero" son concretos (ej. HU-3 "obtener un cotizacionId", HU-16 "póliza con número, vigencia, coberturas y estado vigente")
Lenguaje positivo, no negativo (regla explícita del notebook de arquitectura: evitar "nadie pueda", "no quiero que...") ✅ 89/89 — ninguna HU usa formulación negativa/restrictiva
No ambigüedad — evitar adjetivos vagos sin condición medible (regla explícita del notebook: "rápido", "seguro" sin cuantificar no es aceptable) ⚠️ 1 caso: HU-49 "Autenticación biométrica" — "...para acceder rápido y seguro" no define ninguna condición medible (¿cuántos segundos? ¿qué nivel de seguridad?). Es exactamente el ejemplo de ambigüedad que el notebook señala como no aceptable. Impacto acotado: HU es post-mvp / prioridad Lowest.
Extremos de longitud de descripción Sin indicios de historias infladas tipo épica disfrazada; rango razonable en toda la muestra

4. Cobertura vs. enunciado del caso (PDF MISW4501-202614-Proyecto)

Check Resultado
Las 7 épicas mapean 1:1 a los 6 recorridos críticos §5.1 ✅ E1→#1 cotización, E2→#2 suscripción/emisión, E3→#3+#4 siniestro asistido/paramétrico, E5→#5 perfilamiento hipotecario, E6→#6 ciclo de vida; E4 (identidad) y E7 (plataforma/BFF) como enablers §2.3/§5.2
Caso insignia §2.4 (perfilamiento vida hipotecario) con épica propia ✅ E5, 6 HU dedicadas
Terceros marcados como stub, consistente con restricción del PDF §4/§7 ✅ Open Finance, KYC, pagos, firma, eventos paramétricos etiquetados "(stub)" en los summaries donde aplica
No falta ni sobra ningún recorrido crítico del caso ✅ OK

5. Priorización (detalle de olas)

La wiki prioriza con 3 criterios en cascada (Backlog-refinado-semana-3.md, sección Priorización):

  1. ASR en alcance — solo latencia y escalabilidad (HA-01 a HA-13) ordenan el tablero SOLV; disponibilidad/seguridad/modificabilidad/integrabilidad quedan documentadas pero no mandan la cola.
  2. Recorridos críticos §5.1 — no sigue el orden 1→6; prioriza primero donde hay ASR de latencia/escalabilidad (cotización, emisión, perfilamiento), luego siniestros, y al final ciclo de vida.
  3. Dependencias INVEST — orden técnico obligado (lab antes del experimento; catálogo antes de prima; oferta vigente antes de aceptar).

Traducción a Jira: Ola 1→Highest, 2→High, 3→Medium, 4→Low, 5→Lowest.

Verificación HU por HU: las 89 HU tienen su Priority en el CSV 100% alineado con la ola documentada en la wiki — 0 desviaciones.

Ola Jira Priority # HU % Contenido
1 Highest 14 16% Cotización embebida (#1) + lab de medición
2 High 14 16% Suscripción/emisión (#2) + perfilamiento (#5)
3 Medium 34 38% Siniestro asistido+paramétrico (#3,#4), identidad, UIs que cierran el MVP
4 Low 7 8% Ciclo de vida (#6) — sin ASR de latencia/escalabilidad
5 Lowest 20 22% Todo post-mvp, aunque el HA asociado sea ASR (ej. HA-13→HU-81 va a ola 5 igual)

Observaciones para el equipo:

  • La columna "Ola" no existe en el CSV — solo queda el Priority de Jira. El razonamiento (criterio ASR-primero, no intuición) vive únicamente en la wiki. Si el profesor evalúa el razonamiento de la priorización y no solo el resultado importado, conviene que quede visible también en Jira o en un documento aparte.
  • Ola 5 mezcla dos motivos distintos: HU genuinamente sin ASR (ej. HU-38 recibo extra) y HU que sí son ASR pero se degradaron a ola 5 por decisión de alcance (HU-81, ligada a HA-13 escalabilidad). Sin leer la wiki, un evaluador podría interpretar que el equipo subestimó un ASR real cuando fue una decisión consciente.

6. Relación hacia escenarios de calidad / HA (solo el link)

La wiki mantiene una tabla explícita "Relación HA → HU" (Backlog-refinado-semana-3.md) que ancla cada HA-01 a HA-13 (ASR en alcance) a un conjunto concreto de HU. Se verificó que todos los HU-IDs referenciados desde esa tabla existen en este CSV — ningún HA apunta a una HU inexistente o eliminada. Ejemplo: HA-01/HA-02 (p95/p99 cotización) → HU-1…HU-6, HU-79, HU-89, todas presentes.

Resumen ejecutivo

  • Formato Jira: listo para importar, sin errores estructurales.
  • Formato narrativo de HU: 88/89 conformes a la plantilla Como/quiero/para; único defecto real es HU-66 (falta "para...", heredado de la wiki).
  • Ambigüedad: 1 caso real — HU-49, adjetivos "rápido y seguro" sin condición medible (impacto bajo: post-mvp).
  • Lenguaje negativo: 0 casos.
  • Cobertura de negocio vs. PDF: completa, las 7 épicas cubren los 6 recorridos críticos sin huecos.
  • Priorización: consistente al 100% entre CSV y wiki, pero el razonamiento (criterio ASR) no es visible solo con el CSV importado — recomendable documentarlo también en Jira.
  • Relación HA→HU: íntegra, sin referencias rotas.
⚠️ **GitHub.com Fallback** ⚠️