El método sobre las features de TicketFlow. Sin solutions.md hasta entregar.
Ejercicio 1 — La estimación honesta
- Toma la feature "asignación de asientos automática (el sistema elige los mejores libres)" y estímala con el método del §1: las 3 partes (conocido bien/medio/desconocido), el rango con confianza, y el gatillo de re-estimación.
- El multiplicador: revisa la última tarea que estimaste "2 h": ¿cuánto tardó REALMENTE? Anota el desvío y explica su causa (¿el alcance creció? ¿lo desconocido pesó?).
- El histórico: crea tu
docs/estimates/Q4.mdcon las 5 últimas tareas del curso (estimado vs real, el porqué del desvío). ¿Qué patrón ves (¿las de infra subestimadas? ¿las de datos ×2)?
Ejercicio 2 — El troceado vertical
- Parte la feature del ejercicio 1 en 4-6 trozos VERTICALES (cada uno: modelo+servicio+endpoint+test, demostrable). El happy path primero, los bordes después (el patrón de la tarjeta regalo del §3).
- El trozo 1 en detalle: ¿qué entrega el día 1 (¿el admin ve los asientos sugeridos con la pasarela fake?)? Si tu trozo 1 es "solo el modelo": reescríbelo vertical.
- El límite: ¿algún trozo supera 3 días? Divídelo con la pregunta "¿cuál es el happy path de este trozo?" y verifica que cada trozo tiene SU test demostrable.
Ejercicio 3 — El alcance explícito
- Para la feature completa: escribe el "sí, pero" del §4 con las 3 piezas (condiciones, alcance dentro/fuera, opciones al negocio). El scope-fuera debe ser EXPLÍCITO (el reembolso de asientos automáticos: ¿dentro o fuera? decide y comunícalo).
- El escenario del deadline imposible: el negocio pide la feature en 3 días (tu estimación: 7-10). Escribe las 3 opciones estructuradas (scope menor / desplazar otra cosa / recursos) con su costo real cada una. ¿Cuál recomiendas y por qué?
- La comunicación temprana: tu gatillo de re-estimación dispara el día 2 (el componente desconocido demora). Escribe el mensaje EXACTO que envías ese día 2 (al stakeholder, 5 líneas): ¿qué dices, qué pides, qué propones?
Ejercicio 4 — El plan visible
- Convierte los trozos en el plan del sprint: la tabla trozo/días/entregable/demo — con el día de demo para cada uno (el negocio ve el progreso, no el humo).
- El riesgo del plan: marca los 3 riesgos mayores con su mitigación (el sandbox del proveedor, la concurrencia de la asignación, el UX de la sugerencia) — la tabla riesgo/impacto/mitigación del plan.
- El post-sprint: cuando termines (o simules el cierre), rellena la columna real del histórico (§1): ¿qué trozo desvió y por qué? El ciclo de calibración cerrado.
Ejercicio 5 — La habilidad aplicada
- El problema GRANDE: "migrar el checkout del monolito al servicio de pagos separado (53)". Estímalo con el método (los 3 niveles) y pártelo en fases verticales (¿el strangle pattern? ¿qué fase entrega valor?). Rango total honesto.
- La comunicación del problema grande: escribe el "sí, pero" para el stakeholder: ¿qué opciones presents (¿fases? ¿no hacer? ¿comprar en vez de construir?) con su costo/riesgo?
- La regla personal: escribe TU regla de estimación en 3 líneas (la que el histórico te enseñó) y pégala en tu onboarding (48: el doc que el futuro-tú lee).
Entrega
Pega la estimación con gatillo, el troceado vertical con demos, el "sí, pero" del deadline y el plan visible. Después: Lección 50 — Revisión de código.