Al terminar esta lección
- Producir y versionar los artefactos del Sprint de Nexo en las seis secciones del entregable, citando cada decisión por su origen.
- Armar la frontera IN, OUT y BLOCKED con una decisión controvertida por categoría, y justificar cada una con evidencia.
- Revisar el gate contra evidencia y dejar visibles los criterios pendientes, en lugar de marcarlos por inercia.
- Defender el Sprint en diez minutos frente a un cliente que objeta alcance, costo, tecnología e incógnitas.
Práctica E08 · Entregar un Sprint de Arquitectura completo
Situación. Usá todos los artefactos de Nexo y prepará una versión de 12-20 páginas equivalentes.
Entregá. contexto/problema/objetivos/out; RN/NFR/ASR; arquitectura y ADR; despliegue; riesgos; plan de pruebas; plan incremental; bundle por slice.
Está listo cuando. cada sección responde a una decisión; no hay tecnología sin ASR; los unknowns permanecen visibles; el documento puede defenderse frente a cliente y desarrollador.
Solución comentada: Solución comentada E08. Comparala después de producir tu entrega.
Construí el Sprint de Arquitectura de Nexo como si fuera un entregable facturable. No copies listas del manual sin decidir si aplican.
Esta práctica se hace en seis pasos y una defensa. Cada paso tiene un objetivo, un tiempo sugerido, un ejemplo parcial trabajado, un ejercicio de escritura y pistas. Las pistas y la respuesta parcial alcanzan para empezar. La comparación con la solución comentada llega al final, cuando ya tenés tu versión.
El recorrido completo se ve así. El gate no es el último paso: si un criterio no tiene evidencia, la vuelta lleva a revisar la arquitectura, que es donde suelen aparecer las decisiones sin origen.
El punto de partida es el caso de Nexo que viene desde el módulo 1: el brief inicial, la reunión con el dueño, el negocio real observado en depósito y en administración, los requerimientos, los casos de uso, la especificación, la arquitectura de la lección 7, las decisiones de construcción del módulo 9 y las pruebas del módulo 10. Si algún dato no aparece en esas fuentes, no lo inventes: márcalo como BLOCKED con su dueño.
El Sprint tiene que responder estas preguntas en quince minutos de lectura. Si el documento no permite contestarlas rápido, la estructura se puede mejorar.
¿Qué problema compramos resolver? ¿Qué no incluye? ¿Qué regla sigue abierta? ¿Qué puede romper la integridad? ¿Qué integración puede caer? ¿Cómo evitamos duplicados? ¿Qué veremos primero? ¿Cómo probaremos? ¿Qué necesita aportar Nexo?
Usá esta lista como control final. Cada respuesta debe poder señalarse en una sección del documento.
Paso 1 · Narrativa de una página
Objetivo. Abrir el Sprint con la situación actual, la evidencia más importante, el problema, el objetivo y la métrica. Si la narrativa no cabe en una página, todavía no sabés cuál es el problema.
Tiempo sugerido. 15 minutos.
Ejemplo parcial. La situación y la evidencia del ejemplo sirven de modelo. Fijate que el problema no menciona ninguna tecnología.
## Narrativa del Sprint
Situación: los pedidos mayoristas llegan por WhatsApp y se reescriben a mano en el ERP (EV-01). Muchos SKU se corrigen con una hoja de equivalencias personal (EV-02).
Evidencia más importante: en la muestra de 60 pedidos, 37 necesitaron corrección de SKU y 14 revisaron un acuerdo de precio. El pedido 48172 se confirmó con una unidad que no existía.
Problema: la confirmación depende de conocimiento tácito y puede prometer stock y precio que no corresponden.
Objetivo: que los pedidos se confirmen sin intervención posterior (OBJ-2).
Métrica: porcentaje de pedidos con corrección posterior, con la muestra de 60 pedidos como línea base.
Escribí tu narrativa de una página
Usando la evidencia de EV-01 a EV-08, escribí la narrativa en cinco párrafos cortos: situación, evidencia, problema, objetivo y métrica. Ningún párrafo menciona una tecnología o un patrón.
Ver pistas del paso 1
- Si el problema menciona "IA", "microservicios" o "plataforma", reescribilo como consecuencia que el dueño reconoce: un pedido, un precio, un faltante.
- Si el objetivo no tiene línea base, escribí "línea base: a medir en la semana de observación". Es mejor que un número sin origen.
- Si la métrica no tiene ventana de medición, agregála. Una métrica sin ventana no se puede comparar.
Paso 2 · Frontera IN, OUT y BLOCKED
Objetivo. Dejar explícito qué entra en el primer release, qué queda fuera deliberadamente y qué no se puede decidir todavía por falta de evidencia. Cada ítem debe poder defenderse con una frase.
Tiempo sugerido. 20 minutos.
Ejemplo parcial. Este archivo es el esqueleto de la frontera. Los valores entre comillas están pensados para leerse en voz alta.
in:
- "Registro de pedido con SKU vigentes y precio calculado en el servidor (slices 1 y 2)"
- "Autorización de excepción de crédito con motivo obligatorio (slice 3)"
out:
- "Recomendaciones de productos con IA: ningún problema medido las sostiene"
- "Emisión de comprobantes: integración posterior, el pedido queda pendiente de facturación"
blocked:
- item: "TTL de reserva (RN-07)"
falta: "medir cuánto esperan los pedidos pendientes de autorización"
dueno: "depósito y responsable comercial"
Antes de pasar al ejercicio, hacé el ejercicio de clasificación. Cada ítem tiene una sola categoría correcta.
IN, OUT o BLOCKED
Clasificá cada ítem según la frontera del primer release de Nexo.
Equivalencias de SKU vigentes por fecha de pedido.
Cuenta corriente completa para que el cliente vea todo su historial.
Tolerancia automática de sobregiro para clientes Platino.
Sustitución automática de productos cuando falta stock.
Reemplazo completo del ERP como maestro de productos.
Confirmación de pedidos con crédito dentro del límite del cliente.
Elegí tres decisiones de frontera que el cliente va a discutir
Elegí una decisión IN, una OUT y una BLOCKED de tu Sprint. Para cada una, escribí el motivo, la evidencia que la sostiene y la condición de reapertura o el dueño.
Ver pistas del paso 2
- Un OUT sin condición de reapertura se renegocia en cada reunión. Escribí qué evidencia lo reabriría.
- Un BLOCKED no es un OUT disfrazado: si podés decir qué dato falta, es BLOCKED.
- Si una decisión IN no responde a un objetivo del paso 1, o no tiene prueba asociada, probablemente no pertenece al primer release.
Paso 3 · Casos de uso y reglas que condicionan el primer horizonte
Objetivo. Seleccionar. El Sprint no tiene que anexar todo el caso de uso ni todas las reglas. Solo debe incluir lo que cambia una decisión de datos, concurrencia, fallo o alcance.
Tiempo sugerido. 20 minutos.
Ejemplo parcial. La diferencia está en el criterio de inclusión, no en la cantidad.
Anexar todo o seleccionar lo que condiciona
Anexamos todos los casos de uso, todas las reglas y todos los criterios de aceptación por si alguno hace falta.
El documento se vuelve una copia de la especificación. Nadie puede ver cuál regla decide el primer slice, y el dueño deja de leerlo.
Incluimos CU-01 en su versión final, porque define la reserva y la garantía de éxito. CU-02 entra como extensión, porque cambia la autorización. De las reglas, RN-01, RN-03, RN-05 y RN-06 condicionan el primer horizonte. RN-07 queda BLOCKED. CU-03 y CU-04 aparecen solo con los escenarios de reserva que cambian.
Cada inclusión tiene una razón. Lo que no aparece se referencia por ID en el anexo.
Seleccioná los casos de uso y reglas del horizonte
Listá los CU y las RN que condicionan el primer horizonte. Para cada uno, escribí una frase con la decisión que cambia. Lo que no condicione, referencialo por ID en el anexo.
Ver pistas del paso 3
- Preguntá para cada ítem: si lo saco, ¿cambia alguna decisión de datos, concurrencia o fallo? Si no cambia nada, va al anexo.
- Un BLOCKED no se incluye como regla. Se incluye como frontera con su dueño.
- Si te quedan muchos CU, probablemente estás describiendo el producto y no el primer horizonte.
Paso 4 · Arquitectura, decisiones y riesgos de diseño
Objetivo. Documentar ASR, decisiones, componentes, datos, integraciones, seguridad, concurrencia, idempotencia, observabilidad y despliegue solo al nivel necesario para construir. Cada tecnología tiene un origen.
Tiempo sugerido. 25 minutos.
Ejemplo parcial. El Sprint no vuelve a escribir el contexto de cada decisión: la cita por ID y completa el origen en Nexo. El texto completo de cada ADR vive en la lección 7.1.
### Decisiones que el Sprint cita
- Estilo de despliegue: monolito modular (ADR-001). Origen: consistencia entre pedido y reserva.
- Fuente transaccional de la reserva: PostgreSQL (ADR-002). Origen: RN-05 y AC-06.
- Worker separado para outbox e integraciones (ADR-003). Origen: respuesta fiscal que puede perderse después del commit.
- Handoff a preparación por outbox (ADR-004). Origen: AC-11.
- Idempotencia por requestId (ADR-005) y fingerprint del contenido (ADR-006). Origen: RN-06, AC-07 y T08.
Esta sección tiene una regla de control: no hay tecnología sin ASR, RN o riesgo que la origine. Si aparece una herramienta sin origen, se elimina o se mueve a alternativas descartadas con su motivo.
Revisá la arquitectura contra su origen
Para cada tecnología o componente que aparezca en tu Sprint, escribí el ASR, la RN o el riesgo que lo origina. Si no encontrás ninguno, marcalo para eliminar o para mover a alternativas descartadas.
Ver pistas del paso 4
- Si aparece una cola de mensajes, buscá qué requisito de entrega asíncrona la justifica. Si no hay ninguno, la alternativa descartada es la respuesta.
- El despliegue se describe con la figura 10 y no con un diagrama nuevo que contradiga la topología del monolito modular.
- Las métricas tienen que responder una pregunta de negocio: lag del ERP sobre el umbral, intenciones fiscales envejeciendo, pedidos sin handoff.
Paso 5 · Plan de pruebas y plan incremental
Objetivo. Mostrar cómo sabremos que cada criterio se cumple, y en qué orden se construye. Cada criterio de aceptación tiene una prueba y un slice. Si no tiene prueba, aparece como pendiente.
Tiempo sugerido. 25 minutos.
Ejemplo parcial. La matriz de criterios cruza AC, prueba, slice y nivel. Cuando un AC no tiene un T propio, la tabla lo dice en lugar de inventarlo.
| Criterio | Prueba | Slice | Nivel |
|---|---|---|---|
| AC-01 happy path | T01 | 2 (cierre completo del pedido con reserva) | unit, integración y E2E |
| AC-02 borde exacto de crédito | T02 | 1 | unit |
| AC-03 un centavo sobre el límite | T03 | 1 | unit e integración |
| AC-04 precio calculado en el servidor | T01 (precio snapshot) y caso de unitPrice ignorado | 1 | integración |
| AC-05 SKU inválido sin efectos | T05 | 1 | integración |
| AC-06 última unidad concurrente | T06 | 2 | integración concurrente |
| AC-07 reintento idempotente | T07 y T08 | 2 | integración |
| AC-08 autorización de crédito | T04 | 3 | integración |
| AC-09 cantidad inválida o múltiplo | sin T propio: RN-08 con prueba unitaria | 1 | unit |
| AC-10 falla de persistencia | T09 | 2 | integración |
| AC-11 handoff a preparación | sin T propio: worker caído con outbox | 5 | integración |
| AC-12 proveedor externo caído | T12 | 6 | contrato contra fake |
Las pruebas T10 (actor sin permiso) y T11 (transición ilegal) no tienen AC propio. Se citan por NFR-03 y por las reglas de transición de Nexo, y deben aparecer en el plan aunque no estén en la matriz.
Después de la matriz, el plan incremental se escribe como bundle por slice. Este es el esqueleto del bundle del slice 1:
slice: 1
objetivo_observable: "El vendedor registra un pedido con SKU vigentes y ve precio y crédito calculados en el servidor"
autoridad:
- "RN-03: el precio se calcula en el servidor, nunca viene del cliente"
- "RN-01: crédito estándar. Igual al límite se permite y un centavo más bloquea"
pruebas:
- "AC-02, AC-03, AC-04, AC-05 y AC-09"
fuera_de_alcance:
- "Reserva de stock: entra en el slice 2"
- "Autorización de excepción: entra en el slice 3"
gates:
- "npm run typecheck"
- "npm run test:unit"
Armá la matriz y el bundle del primer slice
Armá la matriz de criterios para tu Sprint, con AC, prueba, slice y nivel. Marcá como pendiente cualquier AC sin prueba. Después completá el bundle del slice 1 con autoridad, pruebas, fuera de alcance y gates.
Ver pistas del paso 5
- Un AC sin prueba no se esconde: aparece como pendiente con el motivo. Eso es mejor que una prueba que no existe.
- Si un slice depende de un BLOCKED para cerrar, ese slice no está listo. Dividilo o cambiá su frontera.
- El bundle no pide "cuidado con la reserva": pide que el agente pregunte cuando falte una regla.
Paso 6 · Riesgos con señal de activación
Objetivo. Registrar cada riesgo con su incertidumbre, impacto, probabilidad cualitativa, mitigación, señal de activación y dueño. No se escriben riesgos genéricos ni se copia la tabla de la lección 8.1 sin revisar si aplica a tu Sprint.
Tiempo sugerido. 15 minutos.
Ejemplo parcial. Un riesgo completo se ve así. Fijate que la señal es algo que alguien puede medir.
- id: RSK-01
riesgo: "TTL de reserva sin validar (RN-07, BLOCKED)"
probabilidad: alta
impacto: alto
mitigacion: "parametrizar sin valor fijo y medir en la primera semana cuánto esperan los pedidos pendientes"
senal: "pedidos pendientes que superan el tiempo que tolera el depósito"
dueno: "depósito (Sergio) y responsable comercial"
Escribí tres riesgos de tu Sprint
Escribí tres riesgos que no estén en la tabla de la lección 8.1, o que sean específicos de tu versión del Sprint. Cada uno tiene las seis partes del ejemplo: riesgo, probabilidad, impacto, mitigación, señal y dueño.
Ver pistas del paso 6
- Si la señal es "que el proveedor falle", reescribila: qué medida, con qué umbral, en qué ventana.
- La probabilidad y el impacto pueden ser cualitativos (bajo, medio, alto). No hace falta un porcentaje, y un porcentaje sin datos es una cifra inventada.
- Un riesgo con dueño "el equipo" no tiene dueño. Asignalo a una persona o a un rol con nombre.
Defensa de diez minutos
Objetivo. Ensayar la conversación con el cliente antes de presentar. Un tercero hace de dueña y objeta alcance, costo, tecnología o una incógnita. Tu respuesta vuelve a evidencia o a una decisión registrada.
Tiempo sugerido. 15 minutos, incluido el ensayo.
Defensa de diez minutos
Estás presentando el Sprint de Nexo a Marta, la dueña. Te pregunta por la facturación antes de firmar. Tenés diez minutos y el equipo espera una respuesta que vuelva a evidencia.
Marta (dueña)
Antes de firmar: ¿por qué el primer release no incluye la facturación? Si no sale el comprobante, no puedo cerrar el mes.
¿Qué respondés?
Repetí la simulación con los otros tres objetivos que el cliente va a cuestionar: el costo del OUT, la elección de un monolito y una incógnita abierta. Cada respuesta debe volver a una decisión registrada.
Criterio de revisión. El Sprint está listo cuando puede guiar una cotización, un plan de implementación y una conversación con el cliente sin que ninguno necesite inventar piezas críticas.
Revisión del Sprint con la dueña: el orden de construcción
Antes de cerrar este taller, un detalle de contexto. El primer borrador de tu Sprint probablemente ordena el trabajo como lo pensó ingeniería: modelo de dominio, persistencia, integración con el ERP, crédito, reservas, fiscal y frontend. Esa lista describe componentes, pero no cuenta una estrategia de entrega.
La pregunta que cambia el orden es simple: "¿En qué momento voy a poder ver que esto reduce el problema de mis vendedores?". Responderla obliga a cortar el trabajo en slices demostrables. La lección 8.2 muestra ese corte con los seis slices de Nexo. Si tu versión tiene más de siete, probablemente describe funcionalidades y no incrementos. Si tiene menos de cuatro, probablemente esconde un bloque grande.
La conversación también cambia la estimación. La investigación no se esconde dentro de un número cerrado: se separa como spike, con dueño, duración máxima y criterio de salida. La API fiscal necesita una prueba de idempotencia real, y el ERP necesita medir latencia y comportamiento ante datos que desaparecen. Si esas incógnitas no se resuelven, el plan comercial tiene que cambiar.
Cuaderno de campo 08 · Revisión ejecutiva y técnica
Entregable. Dos recorridos del mismo Sprint: uno de 10 minutos para el cliente y otro de 25 minutos para ingeniería.
- Seleccioná cinco páginas o secciones para el recorrido ejecutivo y explicá por qué.
- Seleccioná los artefactos técnicos que el equipo necesita para empezar el primer slice sin reunión adicional.
- Marcá las dependencias del cliente con fecha o responsable. Un BLOCKED sin dueño tiende a quedar olvidado.
- Simulá el cambio de una RN crítica y anotá qué secciones del Sprint deben actualizarse. Esto prueba la trazabilidad.
- Revisá el plan incremental: si un slice no puede demostrarse, volvé a cortarlo.
Revisión. El Sprint debe reducir reuniones de aclaración, no crearlas por su propia complejidad.
Hoja de entrega 8 · completá antes de pasar el gate
Este bloque no se completa de memoria. Volvé a tus artefactos, evidencia y resultados. El objetivo es obligarte a hacer explícito qué vas a defender frente a un mentor o un cliente.
- Artefacto que entrego y versión:
- Tres evidencias que sostienen mis decisiones:
- Decisiones que tomé yo y que un agente no podía tomar:
- Desconocidos o riesgos que siguen abiertos:
- Feedback o propuesta de IA que rechacé, y por qué:
- Qué tendría que ocurrir para que yo mismo cambie esta conclusión:
- Revisión de calidad: qué corregí antes de enviar o presentar:
- Firma del mentor o reviewer, o referencia del feedback:
Errores frecuentes
Síntoma: la arquitectura incluye una cola de mensajes y nadie sabe por qué. Causa: se copió la lista de componentes sin decidir si aplica. Corrección: en el paso 4, buscar el requisito de entrega asíncrona que la justifica, o moverla a alternativas descartadas con su motivo.
Síntoma: el gate tiene todos los criterios marcados y la defensa se cae en la primera pregunta. Causa: el checklist se marcó por inercia. Corrección: marcar solo con evidencia revisada y dejar visibles los pendientes.
Síntoma: la matriz tiene criterios sin prueba y la tabla no lo dice. Causa: se copió el catálogo sin mapear cada criterio. Corrección: marcar cada criterio sin prueba como pendiente, con el motivo.
Síntoma: la narrativa abre con "Nexo necesita una plataforma moderna". Causa: se escribió la solución antes que el problema. Corrección: rehacer el paso 1 con la evidencia y una consecuencia que el dueño reconozca.
Síntoma: el bundle del slice 1 no tiene sección de fuera de alcance. Causa: se supone que lo que no se escribe no existe para el agente. Corrección: listar lo que no debe tocar y lo que debe preguntar, con los ID.
Síntoma: el riesgo dice "el proveedor puede fallar" y nadie lo revisa. Causa: falta la señal observable y el dueño. Corrección: reescribir la fila con las seis partes y asignarla a una persona o rol con nombre.
Qué puede hacer el agente. Auditar el Sprint contra los criterios del gate: encontrar tecnologías sin origen, criterios sin prueba, riesgos sin señal y bundles sin fuera de alcance. También puede proponer la defensa de diez minutos con las objeciones más probables.
Qué no debe decidir. Si el Sprint está aprobado, qué queda como BLOCKED, qué valor tiene un TTL o una tolerancia, ni qué criterio se marca como cumplido. El gate lo firma una persona que pueda defender el documento.
Contexto mínimo. El Sprint completo en secciones, los criterios del gate, la lista de ADR citados y la matriz de criterios. Con eso alcanza para una auditoría útil.
Prompt de ejemplo:
Auditá el Sprint de Nexo que te paso contra los cinco criterios del gate 8.
No lo apruebes ni lo reescribas. Para cada criterio devolvé:
- evidencia encontrada, con sección y línea o ID
- lo que falta para cumplirlo
- si el problema es de contenido o de redacción
Además, marcá:
- tecnologías sin ASR, RN o riesgo de origen
- AC sin prueba asignada
- riesgos sin señal observable o sin dueño con nombre
- bundles sin sección de fuera de alcance
No propongas valores para TTL, tolerancia de crédito ni umbrales de latencia.
Cómo revisar la salida. Verificá cada cita contra el documento. Si el agente afirma que un criterio se cumple sin citar evidencia, la revisión no sirve. Y cuidado con el tono: un agente que dice "el Sprint está listo" está fuera de su rol. Lo que sí sirve es la lista de faltantes, porque cada faltante se convierte en una tarea concreta.
Para llevarte
- Cada sección del Sprint responde a una decisión y cita su origen. Si no hay origen, se elimina o se marca.
- La frontera IN, OUT y BLOCKED se defiende con motivo, evidencia y una condición o un dueño.
- Seleccioná los casos de uso y reglas que cambian una decisión del primer horizonte. Lo demás va al anexo por ID.
- Todo criterio de aceptación tiene una prueba o está marcado como pendiente. La tabla no esconde huecos.
- Los riesgos sirven cuando tienen una señal observable y un dueño con nombre.
- La defensa de diez minutos vuelve a evidencia o a una decisión registrada. Si la respuesta no tiene ninguna de las dos, todavía no está lista.
Gate 8 · el Sprint de Arquitectura se puede defender
Un gate no es una formalidad. Si una condición crítica no se cumple, el trabajo correcto es hacer visible la incertidumbre y volver a buscar evidencia.
Criterios de revisión
Revisá tus artefactos antes de marcar cada criterio. El checklist registra tu autoevaluación; la aprobación requiere revisar la evidencia.
Guardá tu entrega
Completá la entrega 08, adjuntá evidencia y registrá los criterios del gate que todavía no podés demostrar.
Cuando termines tu entrega, compará tu razonamiento con la solución comentada E08. No hay una única respuesta correcta: la comparación busca fuentes, decisiones y evidencia.
¿Cómo valoras el contenido técnico de esta lección?
Tu feedback nos ayuda a mejorar los laboratorios prácticos de Eje Z.