Lecciones aprendidas PF1 - martin-hendricks/MISO-PROYECTO-FINAL-SOLVENTA GitHub Wiki

Lecciones aprendidas · Proyecto Final 1 — Solventa (MISW4501)

Índice

1. Propósito y alcance

Este documento registra el conocimiento adquirido por el equipo durante la primera iteración del entregable (Proyecto Final 1) con dos fines explícitos: mejorar la ejecución del Proyecto Final 2, cuyo plan ya está comprometido en tres sprints, y dejar constancia verificable de por qué el equipo decidió lo que decidió, de modo que las decisiones sean auditables después de que se pierda el contexto conversacional.

Dentro del alcance. Las siete semanas del PF1: definición de alcance, requisitos de calidad y ASR, escenarios de calidad y árbol de utilidad, diseño de la arquitectura y del diseño detallado, catálogo de historias de arquitectura HA-01–HA-31, diseño y ejecución de los dos experimentos de arquitectura (HA-01 y HA-08), prototipo navegable web/móvil/back-office, refinamiento del backlog y versión inicial del plan de trabajo del PF2.

Fuera del alcance. La ejecución de los sprints del PF2 (aún no ha empezado), la evaluación individual de desempeño de los integrantes y cualquier juicio sobre personas. El registro documenta situaciones y decisiones, no responsables de fallas.

Una lección aprendida no es una queja ni un pendiente. Para que una entrada figure en §5 tiene que cumplir tres condiciones: describe una situación que efectivamente ocurrió y está respaldada por un artefacto; permite extraer un enunciado reutilizable más allá de este proyecto; y se traduce en una acción concreta para la iteración siguiente. Lo que no cumple las tres cosas va a §8 (riesgo o brecha abierta) o al backlog, no aquí.

2. Formato adoptado y cómo se llena

El formato es un híbrido deliberado de dos estándares, porque ninguno de los dos cubre solo el caso:

Componente Origen Qué aporta
Registro de lecciones aprendidas (§5) — ficha por lección con ID, categoría, situación, impacto, causa raíz, lección y recomendación Lessons Learned Register del PMBOK (PMI), práctica estándar de gestión del conocimiento del proyecto Trazabilidad, causa raíz explícita y accionabilidad. Es el formato que un evaluador o un equipo entrante reconoce sin explicación previa
Retrospectiva Continuar / Empezar / Dejar de hacer (§6) Scrum / DAD, el marco híbrido que el equipo declaró en sus acuerdos La voz del equipo sobre el proceso, en el formato en que el equipo ya trabaja. Es lo que hace que el documento se use y no solo se archive
Plan de acción con responsable, sprint y criterio de verificación (§7) Acción correctiva/preventiva (PMI) aterrizada al sprint Cierra el ciclo: una lección sin acción verificable en el plan del PF2 es una observación, no una lección

Por qué este híbrido y no otro. Un post-mortem técnico puro habría dejado fuera la gestión de alcance y de equipo, que es donde está la mitad del aprendizaje de esta iteración. Una retrospectiva ágil pura no habría dejado registro de causa raíz ni trazabilidad a la evidencia, que es justamente lo que el curso evalúa. Un informe de cierre de fase estilo ISO/IEC/IEEE 15288 habría sido desproporcionado para un equipo de cuatro personas en siete semanas.

Escala y convenciones del registro

Campo Valores admitidos
ID LA-nn, secuencial y estable. Un ID nunca se reutiliza ni se renumera
Tipo ✅ Práctica a replicar · 🔧 Oportunidad de mejora · ⚠️ Situación a evitar
Impacto observado Alto (afectó el entregable, el cronograma o una decisión de arquitectura) · Medio (generó retrabajo acotado) · Bajo (fricción sin consecuencia en el entregable)
Estado de validación ☑ Validada · ✖ Rechazada (se conserva con la razón del rechazo)
Evidencia Enlace al artefacto versionado que respalda la situación. Una lección sin evidencia no entra al registro

Cómo se validó

El registro se validó en la sesión de retrospectiva del equipo: se recorrió el índice de §5.1 y se decidió ☑ o ✖ por lección. Las 19 lecciones quedaron validadas; ninguna fue rechazada ni se añadieron lecciones nuevas. Cada acción de §7 salió con responsable nombrado y criterio de verificación, y el documento quedó cerrado en su versión 1.0 con la firma de los cuatro integrantes en §10. A partir de aquí se revisa al cierre de cada sprint del PF2.

3. Contexto de la iteración

El PF1 no produjo software de producción: produjo una arquitectura con evidencia empírica detrás y un plan de ejecución calibrado. Esa distinción explica la naturaleza de casi todas las lecciones que siguen — el aprendizaje de la iteración es sobre cómo se decide y cómo se evidencia, no sobre cómo se construye.

Trayectoria de las siete semanas

Bloque Qué se produjo Estado al cierre
Semanas 1–4 Alcance, requisitos de calidad, ASR, escenarios de calidad en seis partes, árbol de utilidad, vistas de arquitectura y diseño detallado, catálogo HA-01–HA-31, backlog refinado Cerrado
Semana 5 Diseño formal de los dos experimentos de arquitectura, con hipótesis de diseño y sub-hipótesis declaradas antes de medir Cerrado
Semana 6 HA-08 ejecutado al 100 %. HA-01 al 60 %: montaje completo y validado sintácticamente, cero corridas. Prototipo con 8 pantallas de back-office pendientes Parcial
Semana 7 Campaña completa de HA-01 (56 corridas), prototipo cerrado con back-office, documento de arquitectura ajustado conforme a la evidencia, versión inicial del plan del PF2 Cerrado

Los dos experimentos y su dictamen

Experimento Hipótesis de diseño Veredicto Consecuencia sobre la arquitectura
HA-08 — modelo de lectura de baja latencia para el estado de siniestro (CQRS con proyección materializada y caché) HD-08: la separación del modelo de lectura es necesaria para cumplir EC-LAT-11 (p95 ≤ 150 ms) ❌ No se confirma Se descarta introducir proyector, almacén de proyección y caché. La línea base cumple el ASR con 19× de margen
HA-01 — protección del presupuesto de latencia de la cotización embebida 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 ✅ Se confirma, con un matiz no anticipado Ninguna vista cambia. Se corrigen el razonamiento, el modelo de fallas, la redacción de dos escenarios de calidad y la parametrización de tres tácticas

El resultado más útil de la iteración fue un experimento que refutó su propia hipótesis. HA-08 no falló: demostró que la complejidad propuesta no hacía falta al volumen ensayado, y ese dictamen ahorró tres componentes y un nodo de despliegue. Es el hecho del que se derivan las lecciones LA-01 y LA-02, y conviene tenerlo presente al leer el resto del registro.

4. Métricas de la iteración

Las métricas de producto (velocidad real, cumplimiento del compromiso, defectos) no existen todavía: el PF1 no ejecutó sprints de construcción. Lo que sigue son las métricas de la iteración de arquitectura y la línea base contra la cual se medirá el PF2.

Métrica Valor al cierre del PF1 Observación
Experimentos de arquitectura diseñados y ejecutados 2 / 2 HA-01 y HA-08, ambos al 100 %
Corridas ejecutadas 76 20 en HA-08 · 56 en HA-01
Hipótesis y sub-hipótesis con veredicto explícito 14 4 de HA-08 · 8 de HA-01 · 2 restricciones de presupuesto
Sub-hipótesis refutadas o confirmadas solo en parte 7 de 12 58 %. Ver LA-01
Vistas de arquitectura modificadas por la evidencia 0 Los ajustes se concentraron en diseño detallado, razonamiento y escenarios
Decisiones marcadas para corregir, decidir o revisar tras la experimentación 7 5 correcciones/decisiones · 1 confirmación · 1 brecha abierta de negocio
Historias de arquitectura catalogadas 31 (23 en el tablero) HA-01–HA-31
Historias de usuario en el tablero 120 HU · 399 SP 89 del backlog refinado + 31 de pantallas de cliente
Catálogo MVP 100 HU · 304 SP —
Capacidad calculada de los tres sprints del PF2 137 SP Sin histórico: derivada de la historia base. Ver LA-06
Comprometido en el plan del PF2 131 SP · 58 HU (96 % de la capacidad) 6 SP de holgura, todos en el Sprint 1
Alcance declarado explícitamente fuera del compromiso 117 SP No es deuda oculta. Ver LA-05
Versiones que necesitó el plan de trabajo antes de estabilizarse 3 (v1 borrador → v2 → v2.1) Ver LA-17
Historias comprometidas con refinamiento completo al cierre 50 de 58 A 8 les falta el número medible del escenario de calidad
Factor de conversión horas ↔ puntos 2,4 h/SP Derivado, no validado empíricamente. Ver LA-06
Bus factor del canal móvil 1 39 de los 131 SP comprometidos son móviles. Ver LA-16

5. Registro de lecciones aprendidas

5.1 Índice del registro

ID Categoría Lección Tipo Impacto Validación
LA-01 Experimentación Un experimento que refuta su hipótesis entrega el mismo valor que uno que la confirma ✅ Alto ☑
LA-02 Experimentación La atribución causal se diseña antes de medir, no se argumenta después ✅ Alto ☑
LA-03 Experimentación El esfuerzo de un experimento no está en el montaje 🔧 Alto ☑
LA-04 Experimentación Versionar la evidencia cruda cuesta menos que repetir una corrida ✅ Medio ☑
LA-05 Alcance La capacidad es un dato de entrada, no una variable de ajuste ✅ Alto ☑
LA-06 Estimación Sin histórico, la velocidad se deriva de una historia base — y se declara provisional 🔧 Alto ☑
LA-07 Arquitectura Dos tácticas sobre el mismo escenario deben tener méritos separados en el razonamiento 🔧 Alto ☑
LA-08 Arquitectura El modelo de fallas se deriva del estímulo del escenario, e incluye el fallo a medias 🔧 Alto ☑
LA-09 Arquitectura Una medida de respuesta única puede satisfacerse degradando lo que el escenario protege 🔧 Alto ☑
LA-10 Arquitectura Una restricción de presupuesto debe declarar bajo qué estado del entorno es exigible 🔧 Medio ☑
LA-11 Arquitectura El parámetro de una táctica es parte de la decisión, no un detalle de implementación ⚠️ Alto ☑
LA-12 Arquitectura El aislamiento de recursos se dimensiona por consumidor, no solo por proveedor ⚠️ Alto ☑
LA-13 Arquitectura El alcance de lo validado se declara, o la evidencia se extiende por analogía ✅ Medio ☑
LA-14 Prototipo Un hueco de diseño es una dependencia de planificación, no deuda de UX 🔧 Medio ☑
LA-15 Prototipo Declarar la limitación es preferible a reportar la condición como cumplida ✅ Medio ☑
LA-16 Equipo La concentración de conocimiento es un riesgo de cronograma ⚠️ Alto ☑
LA-17 Documentación Dos fuentes de verdad divergen; una de ellas tiene que ser la vigente 🔧 Medio ☑
LA-18 Proceso Los acuerdos de equipo caducan si no se revisan al cierre de la iteración 🔧 Bajo ☑
LA-19 Proceso Una brecha de decisión no se cierra con más corridas ✅ Medio ☑

5.2 Experimentación y validación de ASR

LA-01 · Un experimento que refuta su hipótesis entrega el mismo valor que uno que la confirma
Tipo ✅ Práctica a replicar
Categoría Experimentación y validación de ASR
Fase Semanas 5–6
Impacto observado Alto — evitó introducir tres componentes y un nodo de despliegue
Evidencia Informe HA-08 · detallado · semana 7 §2.2
Validación ☑

Situación. El experimento HA-08 se diseñó para demostrar que la separación del modelo de lectura (CQRS con proyección materializada y caché) era necesaria para cumplir EC-LAT-11 (p95 ≤ 150 ms en la consulta de estado de siniestro). El resultado fue el contrario: el brazo A —lectura directa sobre el modelo normalizado, sin CQRS— midió p95 = 7,86 ms, 19× por debajo del umbral, con 0 % de error en las nueve corridas contrabalanceadas. Tres de las cuatro sub-hipótesis quedaron refutadas, y una de ellas en la dirección contraria: el caché (brazo C) resultó 9 % peor que la proyección sola, porque con el hit-rate real de 7,6 % la mayoría de las peticiones paga la serialización y la escritura a Redis sin beneficiarse de un acierto.

Impacto. El dictamen descartó introducir proyector, almacén de proyección desnormalizado (siniestros_r) y una instancia de Redis para este camino de lectura. La arquitectura publicada quedó confirmada sin cambios, no porque nadie la revisara, sino porque se puso a prueba y resistió.

Causa raíz del acierto. Tres decisiones tomadas antes de medir: se declararon las sub-hipótesis por separado (HD-08.1 a HD-08.4) en lugar de una sola afirmación global; se incluyó un brazo de línea base sin la táctica propuesta; y el criterio de éxito se fijó contra el umbral del ASR, no contra la mejora relativa entre brazos. Sin el brazo A no habría habido nada con lo que comparar, y la mejora del 21 % del brazo B sobre A —que es real— habría parecido un argumento de necesidad cuando representa menos del 1,2 % del umbral.

Lección aprendida. Un experimento de arquitectura se diseña para decidir, no para confirmar lo que ya se decidió. La refutación de una hipótesis de diseño es un resultado de primera clase: ahorra complejidad que habría entrado al sistema sin que nadie pudiera después justificar por qué está ahí. Corolario operativo: todo experimento debe incluir un brazo de línea base sin la táctica bajo prueba, y el criterio de éxito debe ser el umbral del ASR y no la mejora relativa entre brazos.

Recomendación. Incorporar a la plantilla de diseño de experimentos del PF2 dos casillas obligatorias: brazo de línea base y umbral del ASR como criterio de decisión. Aplicar a HA-02, HA-07, HA-09 y HA-10 (Sprint 2) y a HA-03–HA-06, HA-11 y HA-12 (Sprint 3).

LA-02 · La atribución causal se diseña antes de medir, no se argumenta después
Tipo ✅ Práctica a replicar
Categoría Experimentación y validación de ASR
Fase Semanas 5 y 7
Impacto observado Alto — es el argumento que sostiene la decisión de arquitectura más importante de la iteración
Evidencia Informe HA-01 · semana 7 §2.2
Validación ☑

Situación. HA-01 tenía que distinguir el mérito de dos tácticas que actúan sobre el mismo escenario: el circuit breaker y el desacople por actualización oportunista. El hallazgo decisivo apareció en la celda de fallos intermitentes del 30 %: allí el interruptor 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í el brazo B incumple (1,10–1,25 % de cotizaciones sobre 475 ms) y el brazo C cumple (0,00 %). Como el interruptor no interviene en ninguno de los dos, la diferencia es atribuible únicamente al desacople.

Impacto. Ese resultado elimina la explicación alternativa y convierte una correlación en una atribución. Además 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, lo que descarta que el hallazgo sea un artefacto del doble del proveedor.

Causa raíz del acierto. El diseño del experimento previó la necesidad de aislar factores: seis estados del proveedor en lugar de dos, protocolo de tres fases (sana / degradada / recuperación), corridas contrabalanceadas, y celdas específicas —la de estampida, la de sensibilidad al acierto, la de política del interruptor a dos niveles de tráfico— construidas cada una para aislar una variable. La celda que produjo el hallazgo existe porque alguien previó que el interruptor podía no abrir.

Lección aprendida. Cuando dos mecanismos actúan sobre el mismo escenario de calidad, la única forma de saber cuál sostiene el ASR es diseñar una condición experimental en la que uno de los dos esté inactivo. Esa condición se diseña antes de medir; después de medir solo se puede argumentar, y un argumento no es evidencia. El costo de prever esa celda es bajo; el costo de no tenerla es no poder defender la decisión.

Recomendación. En el diseño de cada experimento del PF2, incluir explícitamente la pregunta ¿qué otra cosa podría explicar este resultado? y, por cada respuesta, la celda que la descarta. Documentarlo en la sección de amenazas a la validez, que en HA-08 ya existe y debe volverse obligatoria.

LA-03 · El esfuerzo de un experimento no está en el montaje
Tipo 🔧 Oportunidad de mejora
Categoría Experimentación y validación de ASR
Fase Semanas 6–7
Impacto observado Alto — concentró la campaña completa de un experimento en la última semana de la iteración
Evidencia semana 6 §1.1 · semana 7 §2
Validación ☑

Situación. Al cierre de la semana 6, HA-01 reportaba 60 % de avance: montaje implementado y validado sintácticamente —:MsCotización con sus cuatro brazos, :AdaptadorOF con interruptor y aislamiento, doble del proveedor con latencia log-normal, Toxiproxy, Redis, PostgreSQL, Prometheus, Grafana y escenarios k6— y cero corridas ejecutadas. Las 56 corridas del protocolo de tres fases, su análisis y la redacción del dictamen se ejecutaron enteramente en la semana 7, en paralelo con el cierre del prototipo, el ajuste del documento de arquitectura y la elaboración del plan del PF2.

Impacto. El entregable se cerró completo, pero sin margen. Cualquier hallazgo que hubiera obligado a rediseñar el montaje —y HA-01 produjo varios hallazgos inesperados— habría llegado sin tiempo de reacción. La semana 7 absorbió simultáneamente el trabajo de dos semanas de experimentación y el cierre de tres entregables más.

Causa raíz. La estimación del experimento trató «montaje listo» como el hito relevante, y el porcentaje de avance se reportó contra la implementación. Pero un experimento con 56 corridas sobre seis estados del proveedor, cinco tasas de acierto, dos políticas de interruptor y cuatro escalones de llegada tiene su esfuerzo repartido en al menos cuatro actividades de tamaño comparable: montaje, ejecución de la campaña, análisis de los datos y redacción del dictamen con su trazabilidad. Reportar 60 % con el montaje terminado sobreestimó el avance real.

Lección aprendida. En un experimento de arquitectura, el montaje es la parte más visible y no la más costosa. El hito que se debe planificar y comprometer es la fecha de la primera corrida válida, no la de montaje terminado, porque es la primera corrida la que revela si el montaje mide lo que se pretende medir. Corolario: el porcentaje de avance de un experimento no debe calcularse sobre la implementación.

Recomendación. Estimar cada experimento del PF2 desglosado en cuatro actividades con esfuerzo propio (montaje · campaña · análisis · dictamen y trazabilidad) y comprometer la fecha de la primera corrida. Como los experimentos del PF2 están repartidos entre S2 y S3 sobre las HU que ya están en el sprint, fijar esa fecha en la mitad del sprint, no al final.

LA-04 · Versionar la evidencia cruda cuesta menos que repetir una corrida
Tipo ✅ Práctica a replicar
Categoría Experimentación y validación de ASR
Fase Semanas 6–7
Impacto observado Medio — permitió recalcular percentiles por fase sin reejecutar 56 corridas
Evidencia semana 7 §2.1 · repositorios de experiments/ha-08-lectura-siniestro y experimentos/ha01
Validación ☑

Situación. En ambos experimentos se versionaron, por corrida, las métricas finales, la configuración efectiva, las verificaciones de sanidad, el resumen de k6 y las series temporales segundo a segundo, junto con el consolidado en CSV y las figuras del informe. En HA-01 se versionó además una instantánea completa de la base de Prometheus (raspado de 1 s, 20 MB comprimidos) cubriendo toda la campaña.

Impacto. Cualquier cifra citada en los informes es recalculable sin reproducir las corridas, y los percentiles pueden recalcularse por fase del protocolo. Eso fue lo que permitió producir, después de terminada la campaña, análisis que no estaban previstos en el diseño original: el corte del p95 del adaptador por fase que reveló el incumplimiento de EC-LAT-07, y la verificación del hallazgo bajo los dos modelos de fallo.

Causa raíz del acierto. Se decidió versionar la evidencia cruda durante la campaña y no al final, cuando ya se sabe qué figuras irán al informe. Los análisis más valiosos del experimento fueron los que no estaban planeados, y solo fueron posibles porque el dato seguía ahí.

Lección aprendida. El dato crudo de un experimento vale más después de terminarlo que durante. Veinte megabytes comprimidos son un costo despreciable frente a reejecutar una campaña de 56 corridas, y la disponibilidad del dato crudo es lo que permite responder la pregunta que nadie previó — que, en esta iteración, resultó ser la pregunta decisiva.

Recomendación. Mantener como práctica obligatoria en el PF2: instantánea de la serie temporal completa por campaña, configuración efectiva por corrida y consolidado en CSV, versionados en el repositorio del experimento. Incluirlo en la definición de terminado de las historias de arquitectura.

5.3 Arquitectura y diseño

LA-07 · Dos tácticas sobre el mismo escenario deben tener méritos separados en el razonamiento
Tipo 🔧 Oportunidad de mejora
Categoría Arquitectura y diseño
Fase Semana 5 (origen) · semana 7 (detección)
Impacto observado Alto — obligó a corregir el razonamiento de la decisión de arquitectura central del proyecto
Evidencia semana 7 §2.2, decisión 1 · semana 7 §3.1
Validación ☑

Situación. El razonamiento publicado en §1.2.4 de la semana 5 atribuía toda la protección del presupuesto de latencia de la cotización a la actualización oportunista. HA-01 mostró que los méritos son separables y distintos: el circuit breaker protege frente al proveedor caído —fallo limpio y detectable—, mientras que 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 de 700 ms. Con el proveedor lento, además, el interruptor no abre nunca y el camino degradado (189 ms) resulta más lento que el camino frío con proveedor sano (159 ms), refutando HD-01.3 tal como estaba enunciada.

Impacto. La topología no cambió —el brazo C validado es exactamente el modelo publicado—, pero el razonamiento que la justificaba era incorrecto en su atribución. Un razonamiento mal atribuido es peligroso de una forma particular: invita a retirar la táctica que parece redundante. Si alguien hubiera leído §1.2.4 y concluido que el interruptor sobra porque el desacople ya protege el presupuesto, habría quedado el sistema sin protección frente al proveedor caído.

Causa raíz. Las dos tácticas se adoptaron juntas, contra el mismo escenario, y el razonamiento se escribió sobre el efecto agregado observado en el diseño, no sobre el mecanismo de cada una. No existía una condición —ni analítica ni experimental— en la que una de las dos estuviera inactiva, así que no había forma de distinguirlas sobre el papel.

Lección aprendida. Cuando varias tácticas responden al mismo escenario de calidad, el documento de arquitectura debe declarar qué hace cada una y frente a qué estímulo concreto. Un razonamiento que describe el efecto conjunto no permite saber qué se pierde al retirar una pieza, que es precisamente la pregunta que alguien hará cuando haya que simplificar.

Recomendación. Adoptar en el diseño detallado del PF2 una tabla táctica ↔ estímulo que neutraliza, con una fila por táctica y no por escenario. Revisar con ese criterio las demás decisiones donde coexisten varias tácticas, empezando por las de escalabilidad (HA-09, HA-10) y las del canal paramétrico (HA-11, HA-12).

LA-08 · El modelo de fallas se deriva del estímulo del escenario, e incluye el fallo a medias
Tipo 🔧 Oportunidad de mejora
Categoría Arquitectura y diseño
Fase Semana 5 (origen) · semana 7 (detección)
Impacto observado Alto — el estado omitido es el que materializa el ASR
Evidencia semana 7 §2.2, decisión 2
Validación ☑

Situación. El modelo de fallas del proveedor externo tenía cinco estados y resultó incorrecto en dos sentidos. Faltaba intermitente, que es el estado donde se produjo el hallazgo principal del experimento. Y degradado —que el modelo trataba como un estado propio— resulta ser en la práctica una caída, mientras el estado que realmente materializa el estímulo de EC-LAT-09 es lento: el proveedor que responde, pero no dentro de su presupuesto.

Impacto. El escenario EC-LAT-09 estaba redactado contra un estímulo que no era el crítico. Con el proveedor caído el interruptor basta por sí solo, así que el escenario tal como estaba enunciado no ejercitaba el mecanismo que el diseño necesitaba defender. Si el experimento hubiera ensayado solo los cinco estados originales, habría concluido que el desacople es prescindible.

Causa raíz. El modelo de fallas se construyó enumerando estados del proveedor desde la perspectiva de su disponibilidad —arriba, abajo, y grados intermedios nombrados informalmente— en lugar de derivarlos del estímulo que el escenario de calidad necesita representar. Un escenario de latencia se rompe por respuestas tardías, no por ausencia de respuesta: la ausencia de respuesta es el caso fácil, porque es detectable.

Lección aprendida. El modelo de fallas de una dependencia externa se deriva del estímulo del escenario de calidad, no de una enumeración de estados de disponibilidad. Y debe incluir explícitamente las formas de fallar a medias —lento, intermitente, respuesta parcial, respuesta incorrecta—, porque son las que derrotan los mecanismos de detección: un componente que responde dentro del timeout no dispara ningún contador.

Recomendación. Añadir intermitente como sexto estado del modelo (ya acordado en §3.1 de la semana 7) y revisar el modelo de fallas de las demás dependencias externas con la pregunta ¿cómo falla esto a medias?: los adaptadores de Open Finance y Open Data, la firma electrónica, la pasarela de cobro y el canal de eventos paramétricos.

LA-09 · Una medida de respuesta única puede satisfacerse degradando lo que el escenario protege
Tipo 🔧 Oportunidad de mejora
Categoría Arquitectura y diseño
Fase Semana 7
Impacto observado Alto — un escenario de calidad era satisfacible por un camino que el propio diseño declara inaceptable
Evidencia semana 7 §2.2, decisión 4 · §3.1, escenarios de calidad
Validación ☑

Situación. EC-LAT-09 estaba definido con una sola medida de respuesta: la latencia. El experimento mostró que el brazo A —invocación bloqueante sin caché— cumple el umbral con el proveedor caído, y lo cumple tarifando el 98,9 % de las cotizaciones con perfil por defecto. Es decir: satisface el escenario de calidad por el procedimiento de renunciar al dato que le da sentido a la cotización.

Impacto. Un escenario que puede aprobarse degradando el resultado de negocio no discrimina entre diseños. De haberse quedado la medición en la latencia, el brazo A habría pasado y el argumento a favor del desacople se habría debilitado por una razón espuria.

Causa raíz. La medida de respuesta se escribió pensando en el atributo de calidad (latencia) y no en qué significa responder bien para ese escenario. En un escenario de degradación, responder rápido es trivial: basta con no intentar. Lo que hay que medir es si la respuesta rápida conserva el valor.

Lección aprendida. En todo escenario de calidad que describe una degradación, una sola medida de respuesta es insuficiente: hay que añadir la medida que impide satisfacerla por la vía trivial. Para EC-LAT-09 esa medida es la proporción de cotizaciones resueltas con valor de respaldo. Generalizando: por cada escenario de degradación, preguntar ¿cómo se aprobaría este escenario haciendo trampa? y medir también eso.

Recomendación. Incorporar la proporción con respaldo como segunda medida de respuesta de EC-LAT-09 (ya acordado) y revisar con el mismo criterio los demás escenarios de degradación del catálogo, señaladamente EC-LAT-08 (degradación del perfilamiento, que sostiene HU-56) y los de disponibilidad de HA-14 en adelante.

LA-10 · Una restricción de presupuesto debe declarar bajo qué estado del entorno es exigible
Tipo 🔧 Oportunidad de mejora
Categoría Arquitectura y diseño
Fase Semana 7
Impacto observado Medio — obligó a reredactar una restricción de diseño
Evidencia semana 7 §2.2, restricciones de presupuesto
Validación ☑

Situación. EC-LAT-07 fijaba un presupuesto de ≤ 120 ms por dependencia externa. La medición lo 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. Con el proveedor sano se cumple al filo (114,9–121,8 ms), y el único estado degradado en que se cumple es caído, donde se cumple por el interruptor, que al abrir corta las llamadas sin tocar al proveedor. EC-LAT-08 (timeout duro de 700 ms), en cambio, se cumple en los cuatro brazos sin excepción.

Impacto. El incumplimiento no debilita la hipótesis de diseño, 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 que 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. Pero la restricción, tal como estaba redactada, quedaba formalmente incumplida y habría figurado así en cualquier auditoría del diseño.

Causa raíz. La restricción se derivó de una descomposición aritmética del presupuesto total de latencia entre los participantes del camino, asumiendo implícitamente el estado sano del entorno. Un presupuesto repartido de esa forma es una herramienta de diseño válida, pero no es una afirmación sobre el comportamiento del sistema bajo degradación.

Lección aprendida. Una restricción de presupuesto derivada de una descomposición aritmética es exigible solo en el estado del entorno bajo el cual se derivó. Si no declara ese estado, se convierte en un incumplimiento aparente en cuanto el entorno se degrada, y ese falso incumplimiento compite por atención con los reales. La redacción correcta declara el estado y el mecanismo con que el diseño absorbe el exceso — en este caso, abandonando la espera.

Recomendación. Mantener EC-LAT-07 como presupuesto objetivo con la salvedad medida explícita (ya acordado) y revisar todas las restricciones del catálogo derivadas por descomposición para que declaren su estado de exigibilidad.

LA-11 · El parámetro de una táctica es parte de la decisión, no un detalle de implementación
Tipo ⚠️ Situación a evitar
Categoría Arquitectura y diseño
Fase Semana 5 (origen) · semana 7 (detección)
Impacto observado Alto — una de las dos parametrizaciones posibles rompe el ASR
Evidencia semana 7 §2.2, decisión 3 · sub-hipótesis HD-01.6
Validación ☑

Situación. El diseño adoptaba la táctica de circuit breaker sin definir su política de apertura. El experimento midió las dos alternativas a dos niveles de tráfico: la política por conteo con tráfico bajo produce 1,19 % de cotizaciones sobre 475 ms y un p99 de 716 ms — rompe el ASR. La política por tasa sobre ventana deslizante da 0,24 % con tráfico alto y 0,77 % con tráfico bajo, y no incumple en ninguna condición.

Impacto. La táctica figuraba como adoptada en el documento de arquitectura, de modo que el escenario aparecía como cubierto. Pero una de las dos formas razonables de implementarla rompe el ASR precisamente en la condición menos vigilada: tráfico bajo, donde diez fallos consecutivos tardan en acumularse y la ventana por conteo se llena despacio. Es un incumplimiento que ninguna prueba de carga a tráfico nominal habría encontrado.

Causa raíz. El catálogo de tácticas se documentó al nivel de qué táctica y no de con qué parámetros, tratando la parametrización como una decisión de implementación delegada al desarrollo. Para tácticas cuyo comportamiento depende de una ventana, un umbral o un timeout, esa delegación traslada la garantía del ASR a quien escribe el código sin darle el criterio para decidir.

Lección aprendida. Una táctica adoptada sin sus parámetros no cubre el escenario: cubre a lo sumo la mitad de él. El parámetro pertenece a la decisión de arquitectura, con su valor adoptado y la evidencia que lo respalda, y debe quedar en el documento — no en el código. Señal de alerta reutilizable: si el comportamiento de una táctica depende de una ventana, un umbral o un tiempo de espera, el documento de arquitectura tiene que fijar ese número.

Recomendación. Adoptar la política por tasa sobre ventana deslizante (ya decidido) y auditar el catálogo de tácticas del diseño detallado: cada táctica adoptada debe listar sus parámetros, el valor adoptado y la evidencia o el criterio que lo sostiene. Las que no lo tengan quedan marcadas como parametrización pendiente, visible, en lugar de figurar como cubiertas.

LA-12 · El aislamiento de recursos se dimensiona por consumidor, no solo por proveedor
Tipo ⚠️ Situación a evitar
Categoría Arquitectura y diseño
Fase Semana 7
Impacto observado Alto — modo de fallo silencioso con el tercero sano
Evidencia semana 7 §3.1, diseño detallado · sub-hipótesis HD-01.7
Validación ☑

Situación. El aislamiento de recursos de :AdaptadorOF está dimensionado por proveedor, y :MsCotización y :MsPerfilamiento comparten ese mismo pool, pese a tener picos no correlacionados por diseño. La celda de estampida de HA-01 (20 claves, TTL 2 s) 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 ninguna señal que lo explicara.

Impacto. Es un modo de fallo silencioso: el síntoma es degradación del recorrido crítico #1, la causa está en el consumo del recorrido #5, y ningún indicador lo relaciona. La coalescencia por clave (brazo C′) lo contiene —coalesce 577 invocaciones y deja el vuelo en 20, con la latencia prácticamente igual: 183 contra 184 ms— pero con el patrón de acceso normal ensayado hubo 0 coalescencias, así que es una táctica condicionada que protege el pool y al proveedor, no el percentil.

Causa raíz. El aislamiento se pensó como protección frente al proveedor —evitar que un tercero lento consuma todos los recursos— y no como protección entre consumidores del mismo recurso interno. Y el contador de fallas del interruptor se definió sobre fallas del proveedor, dejando fuera el agotamiento de un recurso propio, que produce el mismo efecto observable sin activar ninguna defensa.

Lección aprendida. Un recurso compartido necesita aislamiento en ambas direcciones: por proveedor y por consumidor. Y los contadores de falla de un mecanismo de protección deben incluir el agotamiento de los recursos propios, no solo los fallos de la dependencia: si no, el mecanismo queda ciego justo en el caso en que la culpa es de la casa. Corolario: todo componente compartido por dos recorridos con picos no correlacionados es un punto de acoplamiento operacional que hay que dimensionar explícitamente.

Recomendación. Dimensionar el aislamiento por proveedor y por consumidor, incluir las tareas de refresco en segundo plano en el dimensionamiento (no solo las conexiones) e incorporar PoolTimeout a la señal observable. Añadir al PF2 un inventario de recursos compartidos entre recorridos, con su dimensionamiento y su indicador.

LA-13 · El alcance de lo validado se declara, o la evidencia se extiende por analogía
Tipo ✅ Práctica a replicar
Categoría Arquitectura y diseño
Fase Semana 7
Impacto observado Medio — acota correctamente el valor probatorio del experimento
Evidencia semana 7 §3.1, alcance de lo validado
Validación ☑

Situación. El documento de arquitectura ajustado declara explícitamente que HA-01 ejercitó el camino de cotización (:MsCotización → :CacheOF → :AdaptadorOF) y que el camino de perfilamiento —el fan-out de :MsPerfilamiento hacia :AdaptadorOF y :AdaptadorOD— comparte el mismo adaptador y no se ejercitó. La misma práctica aparece en HA-08, donde se declara que la evidencia de aislamiento de carga (~2,5× de CPU sobre PostgreSQL en el brazo A) es insumo para un experimento futuro sobre ese atributo, no de latencia.

Impacto. Sin esa declaración, la conclusión de HA-01 se habría leído como validación del adaptador completo, cuando el camino de perfilamiento tiene un patrón de acceso distinto (fan-out a dos proveedores) sobre el recurso compartido que LA-12 identifica como punto de acoplamiento. Declarar el límite es lo que mantiene visible ese hueco.

Causa raíz del acierto. Se trató el alcance de la validación como parte del dictamen y no como una salvedad de cortesía. Un experimento valida un camino, una carga y un rango; todo lo demás es extrapolación, y la extrapolación se nombra como tal.

Lección aprendida. Un experimento valida el camino que ejercitó, con la carga que aplicó, en el rango que midió. Declarar ese alcance es lo que impide que la evidencia se extienda por analogía a caminos que comparten componentes pero no patrón de uso — que es exactamente donde aparecen los modos de fallo no previstos.

Recomendación. Mantener la declaración de alcance como sección obligatoria del dictamen de cada experimento del PF2, y llevar una matriz camino crítico ↔ experimento que lo cubre, de forma que los caminos sin cobertura sean visibles en lugar de quedar cubiertos por analogía. Primer hueco a registrar: el camino de perfilamiento sobre :AdaptadorOF.

5.4 Gestión de alcance y estimación

LA-05 · La capacidad es un dato de entrada, no una variable de ajuste
Tipo ✅ Práctica a replicar
Categoría Gestión de alcance y estimación
Fase Semana 7
Impacto observado Alto — determina la viabilidad del compromiso del PF2 completo
Evidencia Plan PF2 §5 y §6 · semana 7 §4.1
Validación ☑

Situación. El catálogo MVP sumaba 304 SP contra una capacidad calculada de 137 SP para los tres sprints: un factor de 2,2. Había tres salidas posibles — inflar la velocidad, recortar recorridos críticos, o renegociar el tamaño de las historias. El equipo tomó la tercera: renegoció 45 historias (canal delgado, fusiones por capacidad y reestimación de lo ya resuelto en el PF1) hasta llegar a 131 SP comprometidos, y declaró explícitamente 117 SP fuera del compromiso, historia por historia y con su motivo — diferida, fusionada o ya resuelta. Los seis recorridos críticos del enunciado §5.1 siguen cerrando.

Impacto. El compromiso quedó al 96 % de la capacidad con una trazabilidad completa de lo que no se hará y por qué. Las 117 SP excluidas no son deuda oculta: siguen en el tablero con su prioridad original, y nueve de esas historias desaparecen por fusión o porque ya estaban resueltas, mientras ocho son diferimientos reales que no rompen ningún recorrido.

Causa raíz del acierto. Se trató la capacidad como un dato medido y el alcance como la variable negociable, en ese orden. Y la renegociación se hizo historia por historia con su razón, no aplicando un factor global de recorte, lo que permite auditar cada decisión y revertirla individualmente si aparece holgura.

Lección aprendida. Cuando el alcance no cabe en la capacidad, la respuesta profesional es renegociar el tamaño de las historias y declarar lo que queda fuera, no ajustar la velocidad hasta que la aritmética cierre. Una velocidad inflada convierte el problema en invisible durante dos sprints y lo devuelve, agravado, en el tercero. Un alcance declarado fuera es una decisión; un alcance que no se alcanza es un incumplimiento.

Recomendación. Mantener la tabla de alcance declarado fuera actualizada durante los tres sprints y revisarla en cada planeación, con dos reglas: una historia solo entra al compromiso si otra sale o si hay holgura medida, y las 117 SP excluidas se revisan como candidatas antes de considerar cualquier historia nueva.

LA-06 · Sin histórico, la velocidad se deriva de una historia base — y se declara provisional
Tipo 🔧 Oportunidad de mejora
Categoría Gestión de alcance y estimación
Fase Semana 7
Impacto observado Alto — los 131 SP comprometidos dependen de un factor no validado empíricamente
Evidencia Velocidad del equipo · Plan PF2 §2
Validación ☑

Situación. El equipo no tiene histórico de sprints —el PF2 es el primero que ejecuta junto—, así que la velocidad no se pudo promediar hacia atrás. Se derivó hacia adelante: se fijó HU-6 como historia de referencia (5 SP), se desglosó en actividades técnicas, el planning poker de los cuatro integrantes dio 3, 5, 3 y 3, y se llegó a 12 h para 5 SP → 2,4 h por punto. Con 12 h/semana por desarrollador, 4 desarrolladores y 2 h de ceremonias por sprint, la capacidad sale en 39 · 39 · 59 = 137 SP.

Impacto. El plan tiene una cifra defendible y con evidencia detrás en lugar de un número de manual, y el Sprint 1 se alivió deliberadamente al 85 % reconociendo que el arranque consume capacidad en organización, infraestructura y primer contacto con el stack. Pero todo el compromiso de 131 SP cuelga de un factor de 2,4 h/SP que aún no ha sido validado contra ninguna ejecución real, y de un supuesto de 12 h/semana por integrante que tampoco se ha medido en un equipo que cursa otras asignaturas en paralelo.

Causa raíz. Es una limitación estructural, no un error: no hay forma de tener histórico antes del primer sprint. Lo que sí es una oportunidad de mejora es que el plan no fija todavía el momento ni el criterio para recalibrar ese factor, ni qué pasa con el compromiso de S2 y S3 si el real se aparta del estimado.

Lección aprendida. Una velocidad derivada de una historia base es el mejor dato disponible en el primer sprint, y es legítima si se declara como provisional con fecha de recalibración. La estimación derivada resuelve el arranque; lo que la vuelve peligrosa es tratarla después como si fuera histórico. Segundo aprendizaje: derivar la velocidad de una sola historia de referencia deja el factor expuesto a que esa historia no sea representativa del resto del catálogo.

Recomendación. Recalibrar el factor h/SP al cierre del Sprint 1 con los puntos efectivamente terminados y las horas realmente invertidas, y fijar de antemano el umbral que obliga a renegociar el compromiso de S2 y S3 — umbral acordado: una desviación superior al 20 %. Registrar además las horas reales por integrante durante S1 para validar el supuesto de 12 h/semana. Considerar añadir una segunda historia de referencia de otra épica para no depender de una sola.

5.5 Diseño de experiencia y prototipo

LA-14 · Un hueco de diseño es una dependencia de planificación, no deuda de UX
Tipo 🔧 Oportunidad de mejora
Categoría Diseño de experiencia y prototipo
Fase Semanas 6–7
Impacto observado Medio — 8 historias del PF2 no podían refinarse hasta cerrar el hueco
Evidencia semana 7 §1 · HU pendientes de refinamiento, grupo A
Validación ☑

Situación. Al cierre de la semana 6, las 8 pantallas del back-office de asesor y operador (HU-8, 10, 19, 26, 27, 29, 59, 61) figuraban como Falta UI. Esas 8 historias están comprometidas en los sprints 2 y 3 del PF2 y no podían alcanzar la definición de refinada —que exige frame de Figma, imagen embebida y navegación— hasta que el diseño existiera. El hueco se cerró en la semana 7 y las 8 historias quedaron refinadas en el refinamiento del 18 de septiembre.

Impacto. Se resolvió dentro de la iteración, sin consecuencia en el entregable. Pero durante dos semanas hubo 8 historias comprometidas que no eran tomables, y el cierre coincidió con la semana más cargada de la iteración (LA-03).

Causa raíz. El prototipo se priorizó por recorrido de cliente, que es el criterio correcto para validar la experiencia con usuarios, pero no coincide con el criterio de desbloqueo del backlog: las pantallas de back-office no aparecen en los recorridos del cliente y sostienen recorridos completos del enunciado (los #3 y #4) desde el otro lado. Con dos criterios de priorización implícitos y solo uno explícito, el segundo se atendió tarde.

Lección aprendida. En un proyecto donde la definición de historia refinada exige diseño, un hueco de diseño es una dependencia de planificación con fecha, no deuda de experiencia de usuario. La cola de diseño tiene que priorizarse por dos criterios simultáneos: valor de validación con usuarios y desbloqueo de historias comprometidas. El segundo es el que se olvida, porque sus pantallas no salen en las demos.

Recomendación. Llevar en el PF2 un tablero visible de huecos de diseño (los G-02…G-10 ya identificados en el backlog de UI) con la historia que cada uno bloquea y el sprint en que esa historia está comprometida. Regla: ninguna historia de canal entra a un sprint con su hueco de diseño abierto. Nota: HU-25 y HU-98 están hoy fuera del compromiso precisamente por falta de frame de Figma, lo que confirma que la regla ya se está aplicando de hecho.

LA-15 · Declarar la limitación es preferible a reportar la condición como cumplida
Tipo ✅ Práctica a replicar
Categoría Diseño de experiencia y prototipo
Fase Semanas 6–7
Impacto observado Medio — traslada una verificación real al PF2 en lugar de darla por hecha
Evidencia semana 7 §1.2, condiciones de usabilidad
Validación ☑

Situación. La accesibilidad del canal móvil se diseñó con el mismo rigor que la del canal web —tokens y pares Light/Dark con contraste garantizado, nombres de capa usados como especificación para el lector de pantalla, estado seleccionado marcado con borde + check + texto y nunca solo con color— pero TalkBack y VoiceOver iOS no leen prototipos de Figma en el teléfono. El equipo no reportó la condición como satisfecha: la declaró como limitación explícita y trasladó la validación con lector real al canal implementado en Compose.

Impacto. La condición de usabilidad quedó registrada como diseñada pero no verificada con lector real, que es exactamente su estado. El canal web, donde sí es verificable con VoiceOver, NVDA o JAWS, se reportó como verificable.

Causa raíz del acierto. Se distinguió entre diseñado conforme al criterio y verificado contra la herramienta real, y se reportó cada cosa en su nivel. La alternativa —marcar accesibilidad como cumplida en ambos canales porque el diseño es el mismo— habría sido más cómoda y habría ocultado una verificación pendiente en el canal con menos capacidad de equipo (LA-16).

Lección aprendida. Una condición de calidad se reporta en el nivel en que la evidencia la respalda. Diseñado conforme al criterio y verificado contra la herramienta son estados distintos, y confundirlos convierte una verificación pendiente en un supuesto invisible. La limitación declarada es un activo: se puede planificar. El supuesto invisible aparece en la demo.

Recomendación. Incluir en la definición de terminado de las HU móviles del PF2 la validación con lector de pantalla real (TalkBack sobre la app en Compose), y no solo la conformidad con los tokens del design system. Aplicar el mismo criterio de reporte por nivel de evidencia a internacionalización, localización y responsividad.

5.6 Equipo, proceso y herramientas

LA-16 · La concentración de conocimiento es un riesgo de cronograma
Tipo ⚠️ Situación a evitar
Categoría Equipo
Fase Semana 7 (identificado al planificar el PF2)
Impacto observado Alto — 39 de los 131 SP comprometidos dependen de una persona
Evidencia Plan PF2 §8, estrategia de canal móvil
Validación ☑

Situación. El canal móvil tiene bus factor 1: John es el único integrante con Kotlin/Jetpack Compose y Swift. Y la carga móvil comprometida es de 39 SP de los 131 (15 en S2 y 22 en S3), que es más de lo que una sola persona entrega en dos sprints. El plan lo identificó al elaborarse, no al ejecutarse, y respondió con tres medidas: harness JUnit en el Sprint 1 como red de seguridad, pairing obligatorio desde S2 con John como revisor de toda HU móvil y un segundo integrante como autor en las de menor riesgo técnico (HU-94, HU-97, HU-99, HU-31), y el sacrificio consciente del E2E móvil antes que del producto móvil.

Impacto. El riesgo está mitigado en el plan pero no eliminado: las medidas son un plan, no un hecho consumado, y su eficacia depende de que el segundo integrante llegue a ser productivo en Kotlin dentro del Sprint 2. Además, la reclasificación de HU-53 en la versión 2.1 del plan reveló que la carga móvil real era mayor de la declarada en el borrador (39 SP contra 23): el borrador omitía HU-22 y HU-53, cuya pantalla la construye el canal Android aunque la historia lleve etiqueta de núcleo en Jira.

Causa raíz. Es una composición de equipo dada, no una decisión. Lo que sí es aprendizaje es el error de medición que el borrador contenía: la carga por canal se contó por la etiqueta de la historia en el tablero y no por qué canal construye la pantalla, subestimando la exposición en un 70 %.

Lección aprendida. Una habilidad concentrada en una persona es un riesgo de cronograma, y se mitiga con estructura —red de seguridad técnica primero, pairing después, y un entregable designado para sacrificar— no con voluntad. Segundo aprendizaje, más transferible: la carga por canal se mide por quién construye el artefacto, no por la etiqueta de la historia; contarla por etiqueta subestimó la exposición del canal más frágil.

Recomendación. Verificar el pairing como práctica efectiva, no declarada: al cierre del Sprint 2, medir cuántas HU móviles tienen un autor distinto de John. Criterio de éxito acordado: al menos 2 de las 6 HU móviles de S2. Si no se cumple, activar la renegociación de la carga móvil de S3 antes de que empiece.

LA-18 · Los acuerdos de equipo caducan si no se revisan al cierre de la iteración
Tipo 🔧 Oportunidad de mejora
Categoría Proceso y herramientas
Fase Semana 1 (origen) · cierre del PF1 (detección)
Impacto observado Bajo — sin consecuencia en el entregable
Evidencia Home · acuerdos del equipo contra semana 7 §5 y Plan PF2 §3
Validación ☑

Situación. Los acuerdos iniciales publicados en Home declaran GitHub Projects como tablero Kanban del equipo y ciclos de sprint semanales. La ejecución del PF1 y el plan del PF2 usan Jira (tableros SA y SOLV) y sprints de 2 y 3 semanas. Los acuerdos sobre ramas (GitFlow desde develop), revisión por pares obligatoria, DoR/DoD y escalamiento de bloqueantes sí se mantienen vigentes y se reflejan en la definición de terminado del plan del PF2.

Impacto. Ninguno en el entregable: el cambio de herramienta y de cadencia fue acertado y está documentado en los artefactos vigentes. El efecto es que la página de acuerdos —que es lo primero que lee alguien que llega al proyecto— describe un proceso que el equipo ya no sigue en dos de sus puntos.

Causa raíz. Los acuerdos se escribieron al inicio, cuando aún no se conocía la cadencia real del curso ni la herramienta que el equipo terminaría usando, y no se sometieron a revisión al cierre de la iteración. No hay un momento definido en el proceso para actualizarlos.

Lección aprendida. Los acuerdos de equipo son un artefacto vivo: describen cómo trabaja el equipo hoy, no cómo pensaba trabajar antes de empezar. Si no tienen un momento fijo de revisión, divergen en silencio de la práctica real, y el costo lo paga quien los lee creyendo que están vigentes.

Recomendación. Actualizar Home con la herramienta y la cadencia vigentes, y añadir la revisión de los acuerdos como punto fijo de la retrospectiva de cierre de cada sprint del PF2.

LA-19 · Una brecha de decisión no se cierra con más corridas
Tipo ✅ Práctica a replicar
Categoría Proceso
Fase Semana 7
Impacto observado Medio — evita gastar capacidad de experimentación en una pregunta que no es empírica
Evidencia semana 7 §2.2, decisión 7
Validación ☑

Situación. HA-01 dejó una brecha abierta que el equipo clasificó explícitamente como no resoluble con más corridas: el umbral de respaldo aceptable para actuaría — qué proporción de cotizaciones tarifadas con valor de respaldo en lugar de dato real es admisible para el negocio. El experimento puede medir esa proporción con precisión en cualquier estado del proveedor; lo que no puede es decidir qué valor es aceptable.

Impacto. La brecha quedó registrada como pendiente de decisión de negocio y no como pendiente de experimentación, así que no consume capacidad de los sprints del PF2. Relacionado: la instrumentación del origen y la edad del dato con que se tarifica (origen ∈ {cache, open_finance, fallback, default}) se mantuvo deliberadamente en el nivel de instrumentación y no se promovió a atributo persistido de la entidad de cotización, porque promoverla es una decisión de alcance que depende justamente de ese umbral.

Causa raíz del acierto. Se distinguió entre dos tipos de pendiente que se parecen: la brecha de evidencia, que se cierra midiendo, y la brecha de decisión, que se cierra preguntando a quien tiene la autoridad. Confundirlas produce el patrón de correr experimentos cada vez más finos sobre una pregunta que ninguna medición puede responder.

Lección aprendida. Antes de diseñar un experimento, hay que verificar que la pregunta sea empírica. Una brecha de decisión se escala; una brecha de evidencia se mide. La distinción parece obvia enunciada así y no lo es cuando la pregunta viene envuelta en números, como ¿cuánto respaldo es demasiado?.

Recomendación. Mantener en el PF2 dos listas separadas de pendientes —brechas de evidencia y brechas de decisión— con responsable distinto: las primeras al equipo, las segundas escaladas al cliente o al instructor con la pregunta formulada y el dato que el equipo ya puede aportar.

5.7 Documentación y trazabilidad

LA-17 · Dos fuentes de verdad divergen; una de ellas tiene que ser la vigente
Tipo 🔧 Oportunidad de mejora
Categoría Documentación y trazabilidad
Fase Semana 7
Impacto observado Medio — obligó a sanear restricciones en conflicto y a realinear nombres
Evidencia Plan PF2 §11, restricciones saneadas · HU pendientes de refinamiento
Validación ☑

Situación. El plan de trabajo del PF2 necesitó tres versiones para estabilizarse (v1 borrador de la semana 7 → v2 → v2.1) y la divergencia se manifestó en tres frentes. Las restricciones del borrador entraron en conflicto con la versión 2 —ocho de las doce quedaron reemplazadas, ajustadas o eliminadas— y hubo que publicar una tabla única y vigente contra la cual se leen todas las demás menciones en el tablero y la wiki. Los nombres de las historias en la wiki ya no coincidían con Jira, y la v2 tuvo que adoptar los del tablero (HU-11, HU-22, HU-31, HU-47). Y un documento de seguimiento (HU-pendientes-refinamiento-PF2) quedó obsoleto dos días después de escribirse, al refinarse el backlog completo el 18 de septiembre.

Impacto. Se resolvió con dos decisiones acertadas —la tabla única de restricciones vigentes y la adopción de los nombres de Jira— y con una práctica que conviene conservar: el documento obsoleto no se borró, se marcó como superado con la fecha y el enlace al estado vigente, conservando el registro de dónde estaba el backlog antes del refinamiento. Pero se gastaron dos reversiones del plan en detectar y sanear conflictos que no eran de contenido sino de sincronización.

Causa raíz. La wiki y Jira sostenían ambos la misma información —nombres, criterios de aceptación, alcance, estimaciones— sin que estuviera declarado cuál manda. Mientras el backlog se movía a diario, la wiki quedaba desactualizada en horas, y cada lectura de un documento requería verificar si seguía vigente.

Lección aprendida. Cuando dos artefactos sostienen la misma información, hay que declarar cuál es la fuente de verdad y qué contiene el otro. La convención que el equipo terminó adoptando es buena y conviene enunciarla: los criterios de aceptación definitivos viven en Jira, la wiki contiene el razonamiento, las decisiones y la trazabilidad. Segundo aprendizaje: un documento de seguimiento de un estado transitorio caduca rápido — o se marca como superado con enlace al vigente, o no se escribe.

Recomendación. Enunciar explícitamente la política de fuente de verdad en Home (Jira para criterios y estimaciones, wiki para razonamiento y decisiones), mantener la tabla única de restricciones vigentes del plan como el único lugar donde se leen, y marcar con encabezado de documento superado —no borrar— todo documento de estado transitorio que quede obsoleto.

6. Retrospectiva del equipo

Prácticas acordadas por el equipo en la sesión de retrospectiva, a partir del registro de §5.

Continuar haciendo

# Práctica Por qué Origen
C-1 Declarar las sub-hipótesis por separado e incluir siempre un brazo de línea base Es lo que hizo utilizable el dictamen de HA-08 LA-01
C-2 Versionar la evidencia cruda por corrida, incluida la serie temporal completa Permitió los análisis que no estaban planeados LA-04
C-3 Declarar el alcance de lo validado y lo que queda fuera del compromiso, con su razón Hace auditables tanto la evidencia como el plan LA-13, LA-05
C-4 Reportar cada condición de calidad en el nivel en que la evidencia la respalda Convierte supuestos invisibles en pendientes planificables LA-15
C-5 Marcar como superado, sin borrar, todo documento de estado transitorio Conserva el registro de la decisión y evita lecturas de material caduco LA-17

Empezar a hacer

# Práctica Resultado esperado Origen
E-1 Comprometer la fecha de la primera corrida de cada experimento, no la de montaje terminado Elimina la concentración de la campaña al final del sprint LA-03
E-2 Fijar en el documento de arquitectura los parámetros de cada táctica adoptada, con su evidencia Ningún escenario figura como cubierto con la táctica sin parametrizar LA-11
E-3 Tabla táctica ↔ estímulo que neutraliza, una fila por táctica Hace imposible atribuir a una táctica el mérito de otra LA-07
E-4 Revisar cada dependencia externa con la pregunta ¿cómo falla esto a medias? Cierra el hueco que produjo el modelo de cinco estados LA-08
E-5 Recalibrar el factor h/SP al cierre del Sprint 1, con umbral de renegociación acordado de antemano El compromiso de S2 y S3 se ajusta con dato real, no con el derivado LA-06
E-6 Tablero de huecos de diseño con la historia y el sprint que cada uno bloquea Ninguna HU de canal entra a un sprint con su hueco abierto LA-14
E-7 Dos listas separadas: brechas de evidencia y brechas de decisión La capacidad de experimentación no se gasta en preguntas no empíricas LA-19

Dejar de hacer

# Práctica Riesgo que elimina Origen
D-1 Reportar el avance de un experimento sobre el porcentaje de montaje implementado Sobreestimación del avance real LA-03
D-2 Adoptar una táctica dejando su parametrización al desarrollo Trasladar la garantía del ASR a quien no tiene el criterio para decidir LA-11
D-3 Medir la carga por canal según la etiqueta de la historia en el tablero Subestimación de la exposición del canal con bus factor 1 (70 % en el borrador) LA-16
D-4 Mantener la misma información en la wiki y en Jira sin declarar cuál manda Divergencia silenciosa y reversiones de saneamiento LA-17
D-5 Definir un escenario de degradación con una sola medida de respuesta Escenarios satisfacibles por la vía trivial LA-09

7. Plan de acción para el Proyecto Final 2

Una lección sin acción verificable es una observación. Cada acción tiene responsable nombrado y se revisa en la retrospectiva del sprint indicado.

# Acción Lección Responsable Sprint Criterio de verificación
A-01 Añadir a la plantilla de diseño de experimentos las casillas obligatorias de brazo de línea base y umbral del ASR como criterio de decisión LA-01 Martin Romero S1 Los diseños de HA-02, HA-07, HA-09 y HA-10 las traen antes de la primera corrida
A-02 Sección obligatoria de amenazas a la validez con una celda por explicación alternativa LA-02 Juan Acevedo S1 Presente en el diseño de cada experimento de S2 y S3
A-03 Estimar cada experimento en cuatro actividades (montaje · campaña · análisis · dictamen) y comprometer la fecha de la primera corrida LA-03 Martin Romero S1 Fecha de primera corrida registrada en Jira para cada HA de S2
A-04 Incluir en la DoD de las HA: instantánea de serie temporal, configuración efectiva por corrida y consolidado en CSV versionados LA-04 Juan Acevedo S1 DoD actualizada en el plan y aplicada en la primera HA que cierre
A-05 Revisar la tabla de alcance declarado fuera en cada planeación; una historia entra solo si otra sale o hay holgura medida LA-05 Mauricio Rodriguez S1–S3 Acta de cada planeación referencia la tabla
A-06 Recalibrar el factor h/SP con puntos y horas reales de S1; acordar el umbral de desviación que obliga a renegociar S2 y S3 LA-06 Mauricio Rodriguez S1 Nuevo factor publicado en Velocidad-Equipo antes de la planeación de S2
A-07 Registrar horas reales por integrante durante S1 para validar el supuesto de 12 h/semana LA-06 Mauricio Rodriguez S1 Serie de horas disponible en la retrospectiva de S1
A-08 Publicar la tabla táctica ↔ estímulo que neutraliza en el diseño detallado LA-07 Martin Romero S1 Una fila por táctica adoptada, empezando por las de HA-01
A-09 Revisar el modelo de fallas de cada dependencia externa con la pregunta ¿cómo falla a medias? LA-08 John Guerrero S2 Modelo revisado para Open Finance, Open Data, firma, cobro y canal paramétrico
A-10 Añadir segunda medida de respuesta a los escenarios de degradación del catálogo LA-09 Martin Romero S2 EC-LAT-09 actualizado y criterio aplicado a los demás escenarios de degradación
A-11 Reredactar las restricciones derivadas por descomposición declarando su estado de exigibilidad LA-10 Juan Acevedo S2 EC-LAT-07 y las demás restricciones de presupuesto revisadas
A-12 Auditar el catálogo de tácticas: parámetros, valor adoptado y evidencia; marcar las que queden sin parametrizar LA-11 Mauricio Rodriguez S1 Ninguna táctica figura como adoptada sin parámetros o sin la marca de pendiente
A-13 Inventario de recursos compartidos entre recorridos, con dimensionamiento por consumidor e indicador observable LA-12 Juan Acevedo S2 Inventario publicado; PoolTimeout incorporado a la señal
A-14 Matriz camino crítico ↔ experimento que lo cubre, con los huecos visibles LA-13 Martin Romero S2 Matriz publicada; el camino de perfilamiento registrado como hueco
A-15 Tablero de huecos de diseño (G-02…G-10) con historia bloqueada y sprint comprometido LA-14 John Guerrero S1 Ninguna HU de canal entra a un sprint con hueco abierto
A-16 Añadir validación con lector de pantalla real a la DoD de las HU móviles LA-15 John Guerrero S2 DoD actualizada; primera HU móvil verificada con TalkBack
A-17 Medir el pairing efectivo del canal móvil al cierre de S2 y activar renegociación si no se alcanza el criterio LA-16 Mauricio Rodriguez S2 Número de HU móviles con autor distinto de John, contra el criterio acordado
A-18 Enunciar la política de fuente de verdad en Home (Jira: criterios y estimaciones · wiki: razonamiento y decisiones) LA-17 Juan Acevedo S1 Política publicada y aplicada en la siguiente actualización del plan
A-19 Actualizar Home con herramienta y cadencia vigentes; añadir la revisión de acuerdos a la retrospectiva de sprint LA-18 Juan Acevedo S1 Home actualizado con Jira y la cadencia de sprints vigente
A-20 Mantener listas separadas de brechas de evidencia y brechas de decisión, con responsable distinto LA-19 Martin Romero S1 Ambas listas publicadas; el umbral de respaldo de actuaría escalado

8. Riesgos y brechas que se trasladan al PF2

Lo que sigue no son lecciones: son pendientes reales que la iteración no cerró. Se listan aquí para que no se confundan con aprendizaje ni se pierdan al cambiar de iteración.

# Riesgo o brecha Tipo Estado al cierre del PF1 Mitigación vigente
R-01 El factor de 2,4 h/SP y el supuesto de 12 h/semana por integrante no están validados contra ninguna ejecución real, y los 131 SP comprometidos cuelgan de ellos Estimación Abierto Sprint 1 al 85 % con 6 SP de colchón; recalibración comprometida en A-06
R-02 Bus factor 1 en el canal móvil, con 39 de 131 SP comprometidos en ese canal Equipo Mitigado, no cerrado Harness JUnit en S1, pairing obligatorio desde S2, E2E móvil sacrificable
R-03 Umbral de respaldo aceptable para actuaría: proporción de cotizaciones tarifadas con valor de respaldo admisible para el negocio Brecha de decisión Abierto Escalar; no se cierra con más corridas (LA-19)
R-04 El camino de perfilamiento comparte :AdaptadorOF con la cotización y no fue ejercitado por HA-01 Brecha de evidencia Abierto Registrar en la matriz de cobertura (A-14); candidato a experimento en S3
R-05 El pool compartido de :AdaptadorOF produce un modo de fallo silencioso: la cotización se degrada con el tercero sano y sin señal, porque PoolTimeout no computa como falla Arquitectura Identificado, sin implementar Dimensionamiento por consumidor e instrumentación (A-13)
R-06 S2 y S3 están comprometidos al 100 % de la velocidad, sin holgura: cualquier desviación se propaga al sprint siguiente Planificación Abierto por decisión El overflow se resuelve en la planeación del sprint, no con una regla fija (R8 del plan)
R-07 8 de las 58 historias comprometidas no tienen todavía el número medible del escenario de calidad en su criterio de aceptación Refinamiento Abierto Cerrar antes de que la historia entre a un sprint
R-08 La evidencia de aislamiento de carga de HA-08 (~2,5× de CPU sobre PostgreSQL en el brazo A) queda sin experimento asignado: es sobre otro atributo de calidad, no sobre latencia Brecha de evidencia Registrada Candidato a experimento futuro; no ordena el tablero en este corte
R-09 La accesibilidad del canal móvil está diseñada pero no verificada con lector de pantalla real Calidad Declarado como limitación Validación con TalkBack en la DoD de las HU móviles (A-16)

9. Preguntas de la sesión de retrospectiva

Preguntas sobre lo que los artefactos no registran, respondidas por el equipo en la sesión de retrospectiva.

Sobre el proceso y la cadencia

  1. La cadencia declarada era Sync los lunes, tres encuentros de desarrollo semanales y reuniones de emergencia según necesidad. ¿Se cumplió? ¿Cuántas reuniones de emergencia hubo y qué las disparó?

    Sí, la cadencia fue adecuada, dado que la sesión de los lunes permitió planear adecuadamente las actividades y su distribución.

  2. ¿Hubo bloqueantes que tardaron más de 48 horas en resolverse? ¿El mecanismo de escalamiento de los acuerdos funcionó, o los bloqueantes se resolvieron por otra vía?

    Los bloqueantes siempre fueron resueltos en menos de 48 horas. La comunicación efectiva del equipo mediante los canales establecidos permitió resolver los imprevistos.

  3. ¿El cambio de GitHub Projects a Jira fue una decisión acordada o una deriva? (LA-18 depende de esta respuesta)

    Sí, la decisión fue acordada entre todos los integrantes del equipo.

Sobre la carga y la distribución del trabajo

  1. ¿Cómo se repartió realmente el esfuerzo entre los cuatro integrantes? ¿Hubo semanas en que alguien absorbió trabajo que no le correspondía?

    La carga de trabajo se repartió de manera equitativa y se aprovecharon las fortalezas de cada integrante del equipo.

Sobre las herramientas y la fricción técnica

  1. ¿Qué parte del montaje de los experimentos costó más de lo previsto y por qué? (Toxiproxy, los dobles, la instrumentación de Prometheus, la reproducibilidad de las corridas)

    Tuvimos varios problemas al lanzar el segundo experimento relacionados con la configuración del entorno, pero fueron resueltos en su momento.

  2. ¿Hubo retrabajo por problemas de ambiente, versiones o configuración que no quedó documentado?

    No, todo fue documentado en los experimentos.

Sobre las decisiones

  1. ¿Hubo alguna decisión de arquitectura que se tomó por falta de tiempo y que el equipo revisaría con más margen?

    Las decisiones de arquitectura estuvieron respaldadas por los ASR; siempre se tomaron priorizando el desempeño de la solución y no hubo decisiones tomadas de afán.

  2. ¿Alguna decisión se tomó sin que todos la entendieran igual, y se detectó después?

    No, todos estuvieron siempre de acuerdo.

10. Validación del equipo

Integrante Rol en la iteración Revisó §5 Acuerdo con el registro Fecha
Juan Acevedo Desarrollador ☑ ☑ 24/09/2026
John Guerrero Desarrollador ☑ ☑ 24/09/2026
Mauricio Rodriguez Desarrollador ☑ ☑ 24/09/2026
Martin Romero Desarrollador ☑ ☑ 24/09/2026

Lecciones rechazadas en la sesión

ID Razón del rechazo
Ninguna —

Lecciones añadidas en la sesión

ID Lección Evidencia
Ninguna — —

11. Trazabilidad y fuentes

Artefactos de la iteración

  • Hoja de trabajo semana 7 — cierre del PF1: prototipo final, resultados finales de experimentación, documento de arquitectura ajustado, versión inicial del plan del PF2
  • Hoja de trabajo semana 6 — avance de experimentación (HA-08 al 100 %, HA-01 al 60 %) y del prototipo
  • Hoja de trabajo semana 5 — vistas de arquitectura, diseño detallado, diseño de los experimentos
  • Plan de trabajo · Proyecto Final 2 v2.1 — velocidad, renegociación de alcance, plan por sprint, estrategia de canal móvil, restricciones saneadas
  • Velocidad del equipo — plantillas EstimaciónHUBase y VelocidadEquipo, derivación del factor h/SP
  • Home — acuerdos del equipo y metodología declarada

Experimentos de arquitectura

Backlog, calidad y diseño

Tableros

12. Control de versiones

Versión Fecha Autor Cambios
0.9 21/09/2026 Equipo Solventa Borrador inicial: registro de 19 lecciones derivadas de los artefactos versionados del PF1. Formato: registro PMI + retrospectiva ágil
1.0 24/09/2026 Equipo Solventa Versión cerrada. 19 lecciones validadas, retrospectiva acordada, responsables asignados en el plan de acción, preguntas de la sesión respondidas y §10 firmado por los cuatro integrantes