El Walking Skeleton
Nivel intermedio — una implementación mínima end-to-end que valida la arquitectura y habilita desarrollo en paralelo desde el día uno.
El problema
Los proyectos típicos empiezan diseñando durante semanas; luego el frontend trabaja con mocks mientras el backend trabaja aislado. Al integrar —semanas después— nada encaja.
Situación típica: mes 1, frontend crea UI con datos fake, backend crea APIs perfectas probadas con Postman. Mes 2, intentan conectar: el frontend esperaba {"userName": "John"}, el backend envía {"user_name": "John"}. CORS no configurado, el auth token no se propaga, el deploy a staging falla por variables de entorno faltantes. // una semana de "integración" que nadie planificó
Qué es un Walking Skeleton
Definición de Alistair Cockburn: una implementación mínima del sistema que ejecuta una función end-to-end pequeña — no necesita ser la arquitectura final, pero debe conectar los componentes arquitectónicos principales.
| NO es | SÍ es |
|---|---|
| Backend solo | Frontend + Backend + DB + Deploy |
| Frontend con mocks | Datos reales fluyendo |
| APIs sin consumir | UI que consume APIs reales |
| Local-only | Desplegable en ambiente real |
| Sin tests | Al menos 1 test e2e pasando |
Componentes mínimos
Frontend
- 1 página funcional
- 1 llamada real al backend
- Manejo básico de loading/error
Backend
- 1 endpoint funcional
- Conexión real a BD
- Health check endpoint
Database
- 1 tabla con schema
- Migraciones funcionando
- Seed data básico
Deployment
- Docker Compose local
- CI pipeline básico
- Desplegable a staging
Testing
- 1 test e2e pasando
- 1 test unitario ejemplo
- Tests corren en CI
Cuándo aplicarlo
| Crea Walking Skeleton si... | Puede omitirse si... |
|---|---|
| Arquitectura no probada antes | Usando boilerplate probado del equipo |
| Equipo distribuido trabajará en paralelo | Un desarrollador hace todo secuencialmente |
| Hay incertidumbre en integraciones | Stack muy familiar para todo el equipo |
El error común es leer "mínimo" como "descuidado". El Walking Skeleton es trivial en alcance (una sola página, un solo endpoint) pero riguroso en integración real: datos reales, deploy real, test e2e real. Si algo del skeleton usa mocks o corre solo en local, no está cumpliendo su propósito — solo aplaza el mismo problema de integración a más tarde.
Practica: Todo App end-to-end
Stack: React (Vite) + Node.js (Express) + PostgreSQL + Docker Compose.
Construye un Walking Skeleton completo para una aplicación de gestión de tareas: 1 página que liste tareas desde una llamada real al backend, 1 endpoint conectado a PostgreSQL con al menos 1 tabla y migraciones, y despliegue local vía Docker Compose con al menos 1 test end-to-end pasando.