8.2 Revisión, estimación y backlog de slices

Al terminar esta lección

• Presentar el Sprint como una conversación de decisiones, con origen, alternativa descartada y consecuencia para cada una.
• Cortar un backlog en slices verticales ordenados por riesgo, y explicar qué dependencia obliga a cada orden.
• Separar construcción de spikes con dueño y criterio de salida, y explicar qué incertidumbre afecta la estimación.
• Defender frente al cliente un OUT con condición de reapertura, un BLOCKED con dueño y una decisión de secuencia.

Escena 1 · La revisión empieza al revés

El martes el Sprint de Nexo estaba terminado en la versión de documento: contexto, objetivos, arquitectura, riesgos, plan de pruebas y bundle. El jueves por la mañana, antes de presentarlo, el Responsable del Desarrollo cambió el método de revisión. En lugar de leerlo de arriba hacia abajo, tomó cada decisión técnica y preguntó qué ASR, regla de negocio o riesgo la había originado.

La lectura inversa es el primer filtro, y casi siempre encuentra algo. Si una decisión no tiene origen, probablemente es una preferencia del equipo. Si tiene origen pero nadie recuerda la alternativa descartada, todavía no se puede defender. La tabla siguiente es el resultado de esa revisión sobre seis decisiones que aparecían en el borrador.

Esa tabla muestra algo que un diagrama de cajas no muestra: tres de las seis filas no son decisiones de arquitectura. Son fronteras, datos pendientes o descartes. Un Sprint que las mezcla con decisiones se vuelve difícil de defender, porque el cliente no puede distinguir qué ya está resuelto y qué todavía no.

La revisión termina con un hábito que conviene copiar: para cada decisión importante hay cuatro frases escritas. Qué problema o riesgo existe. Qué opciones se consideraron. Por qué se eligió una. Qué costo o condición podría hacer revisarla. Si solo podés nombrar la tecnología, la decisión no está lista.

Escena 2 · La respuesta que se pierde

La segunda revisión es de fallos. El Responsable del Desarrollo eligió tres puntos donde algo externo o concurrente puede salir mal y recorrió el sistema completo en cada uno: qué commit ocurrió, qué estado ve el usuario, qué se reintenta, qué se audita y cómo se recupera. El punto más revelador fue el worker que emite comprobantes. El código de la primera versión, escrito por otro desarrollador y revisado por nadie, tenía dos defectos que ninguna prueba unitaria detectaba.

Antes de leer la respuesta, tomate un minuto para buscar los defectos. Hay exactamente dos líneas problemáticas.

El Responsable del Desarrollo no reescribió el código en la reunión. Lo que hizo fue convertir cada defecto en una pregunta del contrato de fallo: ¿qué clave se envía?, ¿qué se consulta si no hay respuesta?, ¿qué estado ve el vendedor mientras tanto? Las respuestas quedaron en la tabla de contratos de la lección 8.1, y el worker se reescribió después con esas respuestas como criterio de aceptación.

Esa es la diferencia entre una revisión de código y una revisión de Sprint. El código dice cómo falla hoy. El contrato dice cómo debe fallar, y permite que cualquier versión futura se compare contra él.

Escena 3 · "¿Entonces no son microservicios?"

La reunión de revisión con el cliente empezó con contexto y objetivos, no con arquitectura. Marta, la dueña, escuchó el problema del pedido 48172 y después preguntó lo que todos esperaban: por qué no se partía el sistema en servicios desde el principio, si iba a crecer.

La respuesta es una decisión de consecuencias, y se puede practicar. Elegí una opción y mirá la consecuencia. La conversación sigue según lo que contestes.

Después de la conversación, el equipo volvió a escribir la respuesta en el formato que sirve para cualquier decisión: problema, alternativa descartada, razón y condición de revisión. Ese texto quedó como DEC-08-02 más abajo.

Escena 4 · Una lista de decisiones, no de deseos

Antes de cerrar el backlog, el equipo hizo una última pasada: tomó cada ítem del borrador y lo clasificó. La pregunta no era si el ítem era bueno. Era qué estado tenía en el Sprint: decisión tomada, OUT con motivo, BLOCKED con dueño o ruido sin origen.

Un detalle del caso importa mucho: el portal no desapareció del proyecto. Pasó de ser la base del primer release a ser una frontera posterior, que se construye sobre la reserva y el pedido ya verificados. La decisión es de secuencia, no de rechazo.

Escena 5 · De cuatro cajas a seis slices

El backlog de Nexo tuvo tres versiones, y las tres son útiles para entender por qué la última es la correcta.

La primera versión estaba organizada por componentes: dominio, persistencia, integración con el ERP, crédito, reservas, fiscal y frontend. Era ordenada, pero ninguna de esas piezas podía demostrarse sola. El equipo habría terminado la persistencia varias semanas antes de conocer el precio real de un pedido.

La segunda versión estaba organizada por pantallas: portal de clientes, pedidos, depósito y facturación. Cuando se presentó, la responsable de operaciones preguntó lo que nadie había querido preguntar: "¿Cómo vamos a probar el portal si todavía no confiamos en precios ni reservas?". La pregunta reveló que el orden seguía el mapa de la aplicación y no el riesgo.

La tercera versión se ordenó por valor y riesgo. Cada slice tiene un actor, un resultado observable, las reglas que gobierna y el riesgo que baja. Y la reserva, que es la decisión más cara, entra temprano.

Las dependencias explican el orden. El slice 2 no puede esperar al 1, porque reservar un pedido sin precio ni crédito verificados sería reservar sobre supuestos. El slice 3 necesita una reserva blanda que ya exista. El 5 necesita el outbox y la reserva confirmada. El 6 necesita el outbox del 5, porque la intención fiscal se escribe ahí.

Hay cuatro decisiones de corte que conviene justificar en voz alta, porque el cliente las va a cuestionar:

• La reserva entra antes que la autorización porque es la decisión más cara de revertir. Si la reserva concurrente resulta más difícil de lo previsto, el riesgo aparece temprano y no contamina el resto.
• El portal no está en la lista de slices. Se construye como boundary sobre las capacidades del slice 2 y 3, cuando ya sabemos qué precio y qué stock muestra.
• La facturación real queda fuera. El slice 6 deja el contrato de fallo y la intención durable, pero no promete un comprobante con CAE en el primer valor.
• Ningún slice es una capa. Cada uno tiene un actor que puede verificar el resultado, aunque sea un operador interno.

Escena 6 · Estimar sin inventar

Cuando el dueño pidió una estimación, la respuesta inicial fue "backend de pedidos: cinco días". Esa cifra mezcla demasiadas incógnitas en un número solo: la reserva concurrente, la integración con el ERP, la política de crédito y la prueba fiscal. Cuando una de ellas se complica, el número deja de servir.

Una estimación defendible explicita supuestos y separa lo conocido de lo que todavía es investigación. El artefacto siguiente es la estimación del slice 2, escrita para que la revisen el Responsable del Desarrollo, Marta y el equipo técnico.

1slice: 2
2nombre: "Reserva e idempotencia (SLICE-C-RESERVA)"
3alcance_incluye:
4  - "Reserva condicional por depósito y SKU, dentro de la transacción del pedido"
5  - "Idempotencia por requestId con fingerprint"
6alcance_excluye:
7  - "TTL de reserva (RN-07, BLOCKED)"
8  - "Sustitución automática de productos"
9supuestos:
10  - "PostgreSQL con transacciones locales disponible en el ambiente de prueba"
11  - "Los depósitos CBA y CEN se modelan con warehouse_id"
12incertidumbre:
13  - "Comportamiento del ERP al sincronizar stock (SPK-02, dueño: líder técnico)"
14spike_previo: "SPK-02 con duración máxima acordada antes de empezar el slice"
15estimacion: "rango publicado solo después de cerrar SPK-02; sin número antes de medir"
16condicion_de_revision: "si la prueba concurrente falla dos veces por la misma causa, se reabre el diseño de la reserva"

Esta estimación tiene un rasgo que conviene notar: no tiene número hasta el spike. Eso no es falta de compromiso. Es honestidad sobre lo que todavía no se sabe, y el cliente lo entiende mejor cuando se le muestra el costo de la incertidumbre en lugar de esconderlo.

Escena 7 · El bundle del slice 2

De la arquitectura no se deriva un documento que se pega entero en cada conversación con un agente. Se deriva un bundle por slice. El bundle del slice 2 es el que el módulo 9 usa como ejemplo, bajo el nombre histórico SLICE-C-RESERVA.

El bundle declara qué condiciona el slice y qué queda explícitamente afuera. Una parte importante es la lista de fuera de alcance: si el agente necesita una política que no está escrita, tiene que preguntar, no inventarla.

1# Alias histórico: SLICE-C-RESERVA
2slice: 2
3objetivo_observable: "Dos pedidos compiten por la última unidad. Uno confirma y el otro recibe un rechazo sin efectos. Un reintento devuelve el mismo pedido."
4autoridad:
5  - "RN-05: disponible = onHand - reserved, nunca menor que cero, por depósito y SKU"
6  - "ADR-002: PostgreSQL es la fuente transaccional de la reserva"
7  - "ADR-005: idempotencia por requestId en la misma transacción que pedido y reserva"
8  - "ADR-006: fingerprint sobre cliente, depósito preferido y líneas normalizadas por SKU y cantidad"
9contratos_focales:
10  - "StockPort.reserve(orderId, depotId, sku, qty) devuelve Reserved o InsufficientStock"
11  - "CreateOrderResult devuelve confirmed, conflict o rejected"
12invariantes:
13  - "disponible >= 0 para cada depósito y SKU"
14  - "mismo requestId y mismo fingerprint: mismo resultado, sin efecto nuevo"
15  - "mismo requestId y fingerprint distinto: conflict, sin efecto"
16pruebas:
17  - "AC-06 con base real, repetida (checkpoint C)"
18  - "AC-07 y el caso de conflicto de T08"
19  - "AC-10: falla antes del commit con rollback completo (T09)"
20archivos_relevantes:
21  - "src/application/create-order.ts"
22  - "src/ports/stock.ts"
23  - "src/adapters/postgres-stock.ts"
24  - "tests/integration/stock-reservation.test.ts"
25fuera_de_alcance:
26  - "UI y cambio de nombres públicos"
27  - "Redis o dependencias nuevas"
28  - "TTL de reserva (RN-07, BLOCKED): si el agente lo necesita, debe preguntar y no inventar un valor"
29gates:
30  - "npm run typecheck"
31  - "npm run test:unit"
32  - "npm run test:integration -- stock-reservation"

Un detalle de numeración vale la pena nombrarlo. En algunos borradores viejos aparece "ADR-003 PostgreSQL es fuente transaccional de la reserva". Es un error de identificador: ADR-002 es PostgreSQL y ADR-003 es el worker. Si un bundle cita el ID equivocado, el agente va a cambiar código según un registro que no existe. La corrección no es una decisión de diseño: es mantener un único registro de ADR y revisar los IDs antes de entregar.

Escena 8 · La revisión con el cliente

La reunión con el cliente se preparó como una presentación de consecuencias, no de patrones. La regla que siguió el equipo fue simple: cada decisión técnica se presenta con el problema que evita, en el lenguaje de quien tiene que aprobarla.

El equipo empezó por el contexto y los objetivos. Explicó que el cuello de botella no es solamente la carga inicial del pedido: el pedido atraviesa identificación, precio, crédito, reserva y preparación, con datos dispersos. El objetivo del release es reducir las cargas dobles y hacer explícitas las decisiones de confirmación.

Después vinieron las decisiones con consecuencias:

Una operación transaccional evita reservas huérfanas. La idempotencia evita pedidos duplicados cuando la red reintenta. Un outbox evita perder la notificación a preparación después del commit. El cliente no necesita aprender esos nombres para entender el riesgo.

Marta preguntó por la facturación. El equipo respondió con una decisión de secuencia y no con un no:

El primer valor que queremos probar termina cuando existe un pedido comercialmente confirmado y listo para preparación. Facturación es importante, pero introducirla ahora agrega normativa e integración fiscal sin ser necesaria para validar el núcleo. Diseñamos una frontera para integrarla después.

Esa respuesta funciona porque tiene motivo, frontera y condición. Lo que no funciona es decir "la facturación no entra" sin nada más: el cliente lo escucha como una negativa, aunque sea una decisión correcta.

Más tarde apareció el TTL de reserva. Marta propuso poner 24 horas. El equipo mostró dos episodios reales: pedidos que se preparan en menos de una hora y pedidos grandes que esperan autorización hasta el día siguiente. Con esos dos casos, la discusión se movió. Elegir 24 horas sin política podía congelar stock o liberar mercadería reservada. Se acordó medir los tiempos de espera durante la primera semana y definir antes quién tiene autoridad para fijar el valor. Ese acuerdo quedó registrado como RN-07 BLOCKED con dueño.

Laura, de administración y crédito, pidió lo que más le importaba: que la autorización de excepciones no dependiera de un audio. El equipo le mostró el slice 3 y el requisito NFR-02: quién autoriza, cuándo, con qué motivo y para qué pedido. Ella aceptó que la decisión de autorizar siga siendo humana, siempre que quede constancia.

Sergio, de depósito, quería que el sistema sugiriera sustitutos automáticamente. La respuesta fue BLOCKED con motivo: no existe una matriz de marca, compatibilidad y preferencia. Sin ella, cualquier sustitución automática sería una suposición con el nombre de una función.

Escena 9 · Decisiones que se pueden discutir

Las conversaciones de la revisión terminan en registros cortos, no en recuerdos. Estos son los dos que el equipo escribió. Tienen motivo, alternativa, condición de reapertura o revisión y un responsable.

1## DEC-08-01 · Facturación electrónica queda fuera del primer valor
2​
3- Estado: OUT del primer release. Integración posterior.
4- Lo que sí entra: el pedido confirmado queda marcado como pendiente de facturación, y la intención fiscal se escribe en el outbox (slice 6).
5- Motivo: el valor a probar es un pedido comercialmente confirmado y listo para preparación. La emisión agrega normativa e integración externa que no son necesarias para validar el núcleo.
6- Condición de reapertura: contrato fiscal probado contra fake (T12) y SPK-01 cerrado con la API real del proveedor.
7- Responsable: Marta (dueña), con administración (Laura).

1## DEC-08-02 · Pedido y reserva se confirman en la misma base
2​
3- Estado: decidido.
4- Problema: confirmar un pedido sin su reserva rompe RN-05, y reservar sin pedido deja stock huérfano.
5- Alternativas descartadas: servicio de stock separado (coordinación distribuida sin beneficio medido) y cola externa para reservar (más difícil de probar en concurrencia).
6- Condición de revisión: el stock necesita escalar o aislarse por operación, con un ASR que lo justifique.
7- Referencias: ADR-001, ADR-002, AC-06.
8- Responsable: el Responsable del Desarrollo (validado con Marta).

Un registro así permite algo que una conversación no permite: que alguien lo lea dentro de seis meses, cuando cambie la política, y sepa qué debe reabrirse y quién lo decide.

Cuándo el Sprint creció demasiado

Un Sprint se infla de dos maneras. La primera es cuando intenta resolver procesos que no comparten objetivo: el pedido, el portal y la contabilidad conviven en el mismo documento sin una pregunta común. La segunda es cuando describe módulos que no aparecen en ningún caso de uso prioritario, o decisiones sobre un futuro lejano sin ASR actual.

El criterio práctico es preguntar qué riesgo del próximo horizonte de construcción reduce cada sección. Arquitectura no significa predecir el producto completo. Significa reducir riesgos importantes del próximo tramo de trabajo, y dejar explícitamente afuera el resto.

Del Sprint al contrato comercial

Un Sprint bien construido permite convertir incertidumbre en condiciones comerciales claras. La propuesta separa tres cosas: lo que se confirma, lo que es opcional y lo que está bloqueado por evidencia pendiente. También define qué cambios posteriores cuentan como cambio de alcance: los que alteran una regla o una frontera aprobada.

Esto protege a ambas partes. El cliente entiende qué compra. El equipo no esconde riesgo dentro de horas genéricas. Y si durante la construcción aparece evidencia que contradice una regla aprobada, no se culpa al documento: se registra el cambio, se evalúa el impacto y se decide.

Un ejemplo de lo que una propuesta no debe hacer: prometer que el sistema "automatiza el crédito con IA". Eso convierte una decisión de autorización humana en una promesa que el sistema no puede cumplir, y que el cliente reclamará cuando la primera excepción no se resuelva sola.

Qué debería poder responder cada página del Sprint

La sección de contexto explica por qué existe el proyecto. La de alcance dice qué construimos ahora. Los casos y las reglas dicen qué comportamiento prometemos. La arquitectura muestra cómo protegemos las propiedades importantes. Los riesgos muestran dónde podemos equivocarnos. El plan incremental muestra cómo obtendremos evidencia temprana. Las pruebas muestran cómo vamos a saber que cumplimos.

Si una sección no responde una pregunta útil, probablemente se puede reducir. Ese es el criterio de corte final, y se aplica también a esta lección: cada escena responde una pregunta que el Sprint tuvo que contestar en la reunión.

Errores frecuentes

Síntoma: el cliente aprueba el Sprint y dos semanas después pide "cuenta corriente, que estaba implícito". Causa: el OUT no tenía motivo, condición de reapertura ni responsable. Corrección: registrar el OUT como DEC-xx con las tres cosas, y mostrarlo al cliente antes de la firma.

Síntoma: "backend de pedidos: cinco días" se aprueba y en la segunda semana el plan ya no cierra. Causa: la estimación mezcla construcción con investigación y no tiene supuestos explícitos. Corrección: separar los spikes con criterio de salida y estimar solo el trabajo que ya se conoce.

Síntoma: el bundle cita ADR-003 como PostgreSQL y el agente cambia el código según ese ID. Causa: los IDs de decisión no se revisaron entre documentos. Corrección: un solo registro de ADR (ADR-002 PostgreSQL, ADR-003 worker) y una revisión de IDs antes de entregar cualquier bundle.

Síntoma: el primer entregable es visible solo para clientes externos, y el depósito no ve nada útil. Causa: el corte siguió las pantallas y no el riesgo. Corrección: empezar por un slice con actor interno que pueda observar la decisión, como el slice 1 y el 2.

Síntoma: el agente propone un TTL "razonable" para cerrar el slice de reserva. Causa: el bundle no declara el TTL como fuera de alcance con la instrucción de preguntar. Corrección: listar RN-07 como BLOCKED en "fuera de alcance" y agregar la instrucción explícita de no inventar valores.

Síntoma: el cliente pide una reunión para "volver a discutir la arquitectura" sin nuevos datos. Causa: las decisiones no tienen condición de revisión. Corrección: mostrar la condición del registro y preguntar qué evidencia nueva existe. Si no hay, la decisión sigue vigente.

1Te paso la lista de IN, OUT y BLOCKED del primer release de Nexo y el catálogo AC-01 a AC-12.
2Proponé un corte en slices verticales que cumpla estas reglas:
3- Cada slice tiene un actor, un resultado observable y los AC que lo prueban.
4- Ningún slice depende de un BLOCKED para cerrar.
5- Cada dependencia entre slices se justifica con una regla o un riesgo.
6- Si un AC queda sin slice, decímelo. No inventes un AC-13.
7Devolvé una tabla con slice, valor observable, AC, dependencias y riesgo que baja.
8No propongas valores para TTL, tolerancia de crédito ni umbrales de latencia.

Para llevarte

• Revisá cada decisión con lectura inversa: origen, alternativa descartada y consecuencia. Si una de las tres falta, la decisión no está lista.
• Un backlog se corta por valor y riesgo. La reserva, que es la decisión más cara, va temprano.
• Un OUT necesita motivo, condición de reapertura y responsable. Sin esas tres cosas se renegocia cada semana.
• Una estimación defendible explicita supuestos e incertidumbre. Si no tiene número antes del spike, eso es honestidad y no falta de compromiso.
• El bundle de cada slice declara lo que queda fuera, y en especial lo que el agente no puede decidir.
• Antes de entregar un bundle, revisá que los IDs de ADR y AC coincidan con el registro. Un ID equivocado produce código equivocado.

Comprobá tu criterio