Lección 49 — Estimar y dividir problemas

Ejercicio 1 — La estimación honesta

1. La estimación de la asignación automática:

Conocido bien: el modelo de asientos + la query de libres (09/10) → 1-2 d (alta)
Conocido medio: el servicio de sugerencia (proximidad/precio, reglas del 08)
               + el endpoint + tests → 2-3 d (media)
Desconocido:   la política de "mejores asientos" con el negocio (¿qué es mejor?
               ¿fila central? ¿juntos? ¿el precio?) → 1-3 d (incertidumbre REAL)
Total: 4-8 días, confianza media. Gatillo: si la política no está definida el día 1,
       re-estimo y aviso (el §4: la política es del negocio, no mía).

1. El desvío típico: la "2 h" de "añadir el campo expires_in_seconds al DTO" (25) tomó medio día: el cálculo en el DTO necesitó el Clock inyectado (el alcance creció al hacer el cálculo testeable) — el desvío fue de ALCANCE, no de velocidad: la lección del histórico: el desvío se clasifica (¿alcance? ¿desconocido? ¿interrupciones?) antes de corregir el multiplicador.

1. El patrón del histórico: las tareas de infra (Celery, compose) subestimadas ×1.5-2 (el entorno muerde); las de datos (export RGPD) ×2 (la anonimización era el 70%); las de lógica pura con la lógica ya extraída (28) -30% (el refactor previo SE PAGA). La calibración: ×1.5 en infra, descomponer más las de datos.

Ejercicio 2 — El troceado vertical

1. El troceado (4 días):

1. (1 d)  Sugerencia con pasarela fake: endpoint /suggest asientos para N personas,
          con la política v1 simple (contiguos, menor precio) + tests + admin demo.
          El negocio VE sugerencias reales el día 1.
2. (1 d)  Reservar DESDE la sugerencia (el flujo completo con la sugerencia prefijada):
          el E2E del flujo existe.
3. (1 d)  Concurrency-safe (10): dos sugerencias simultáneas, el lock del asiento;
          el test de la disputa.
4. (1 d)  La política v2 con el negocio (los "mejores" según SU regla) + los bordes
          (evento casi lleno → sugerir alternativas) + smoke final.

1. El trozo 1 vertical: modelo + query + endpoint + tests + demo al admin — el "solo el modelo" del error clásico se reescribe: el día 1 entrega la decisión que el negocio debe confirmar (la política v1) ANTES de que el coste de cambiarla sea alto (el feedback temprano ES el propósito del vertical).

1. El trozo 3 podría crecer (la concurrencia es el terreno del 10): si supera 3 días, se divide: (3a) el lock básico de la disputa; (3b) el test de carga de la meseta (36). Cada mitad con su test.

Ejercicio 3 — El alcance explícito

1. El "sí, pero" (extracto): "La asignación automática sale el día 5 SI: (a) la política de 'mejores' está definida el día 1 (es decisión del negocio, no técnica); (b) el alcance v1 excluye reembolsos de asignaciones erróneas (la semana siguiente) y la sugerencia por accesibilidad (backlog). Opciones: (1) el scope (a) entra el día 5; (2) si el reembolso es bloqueante, desplazamos la preventa del 36 una semana; (3) nadie más toca el checkout estos días (el merge del 40)."

1. El deadline de 3 días: las opciones: (a) scope mínimo: el trozo 1-2 (sugerencia + flujo) en 3 días SIN la concurrencia blindada (riesgo: la disputa del asiento en preventa — NO recomendado para preventa); (b) la preventa del 36 se desplaza (costo: el negocio pierde la fecha); (c) recursos: nadie más toca el checkout (mitiga el merge, no el alcance). La recomendación: (b) — la asignación automática SIN concurrencia blindada en una preventa es el bug del año: mejor la fecha que el incidente (el 47 cuenta las consecuencias).

1. El mensaje del día 2: "El componente de política está demorando (el negocio define qué es 'mejor'): la feature sale en 5 días como el plan, no en 4. Pido: la definición de la política para el jueves. Alternativa si no llega: salgo el día 4 con la política v1 (contiguos + precio) y la v2 entra la semana siguiente. Propongo la alternativa B si el jueves no hay definición."

Ejercicio 4 — El plan visible

1. El plan del sprint:

1. Los riesgos: (sandbox/proveedores: n/a aquí) (a) la política no definida → el gatillo del día 1 + la alternativa B; (b) la concurrencia sorprende (el lock contiende más de lo esperado) → el test del 34 el día 3, no al final; (c) el UX de alternativas crece → scope-fuera explícito (el backlog).

Ejercicio 5 — La habilidad aplicada

1. La migración del checkout al servicio separado: estimación: conocido (el código a mover: la saga ya desacoplada del 32: 5-8 d), medio (el contrato entre servicios + red: 5-8 d), desconocido (la operativa dual, la migración de datos en caliente, el rollback: 5-10 d) → 15-26 días en fases: (1) el servicio nuevo DUPLICA el flujo (strangle: el monolito sigue siendo la verdad, 53); (2) el switch por feature flag al servicio para el 5% de tráfico (canary del 46); (3) el 100% + el monolito destrona el código; (4) la limpieza (el contract del 11). Cada fase entrega valor medible.

1. El "sí, pero" del problema grande: "La migración es 15-26 días en 4 fases; la alternativa: NO separar (el monolito modular del 53 aguanta ×10 el volumen actual con 0 días) o comprar la pasarela gestionada (5 d, +200 €/mes, lock del proveedor). Presento las tres con costo/riesgo: la decisión del scope-fuera es del negocio."

1. La regla personal (extracto): "Estimo en rangos con gatillo; los trozos son verticales con demo; lo desconocido se separa y se comunica el día que se conoce (no el deadline); el desvío se clasifica (alcance/desconocido/interrupción) antes de corregir el método."

Resumen del profesor

• Rango + descomposición + gatillo de re-estimación: la estimación honesta es un contrato con revisión; el histórico calibra y se clasifica el desvío antes de corregir.
• Trozos verticales con demo (el feedback temprano compra decisiones baratas); el alcance-fuera explícito vence al sí mudo.
• El trade-off lo presenta el técnico y lo decide el negocio: el problema comunicado a tiempo es un plan.