Puntas, Pruebas de Concepto y Adopción de Nuevas Herramientas
Las nuevas herramientas de Python (orquestadores, bases de datos vectoriales, frameworks) requieren puntas y pruebas de concepto disciplinadas antes de su adopción a nivel de flota. Los límites de tiempo, los criterios escritos y los resultados de las ADR evitan el desarrollo impulsado por el currículum y las sorpresas en producción.
Receta
Tarjeta de receta de referencia rápida, lista para copiar y pegar.
# Carta de Puntas
**Pregunta:** ¿Puede Polars reducir el tiempo de ETL en un 50% en el mart de pedidos?
**Límite de tiempo:** 3 días (finaliza el viernes al final del día)
**Propietario:** @data-eng
**Éxito:** tiempo de ejecución del trabajo de staging < 12 min (línea base 25 min)
**No objetivos:** cambio a producción, refactorización completa
**Salida:** README en `spikes/2026-07-polars/` + borrador de ADR de recomendaciónCuándo usar esto:
- Pregunta abierta en RFC
- La demostración del proveedor parece increíble
- El equipo quiere reemplazar Celery/Airflow/xyz
- Estimación bloqueada por lo desconocido
Ejemplo de Trabajo
# spikes/2026-07-polars/README.md
## Resultado: Adoptar para nuevos marts; no reescribir el legado todavía
| Criterio | ¿Cumplido? |
| Mejora del 50% en el tiempo de ejecución | sí (22→10 min) |
| El equipo puede mantener | sí (2 ingenieros capacitados) |
| Costo operativo aceptable | sí (mismo tamaño de trabajo K8s) |
| Modos de fallo entendidos | parcial - documentar pico de memoria en uniones amplias |
## Próximos pasos
- ADR-021 adoptar Polars para nuevas canalizaciones
- Ticket: añadir Polars a la cookiecutter de la plataforma de datos
- Pruebas de concepto de endurecimiento NO realizadas - la producción necesita ticket de observabilidad# spikes/2026-07-polars/benchmark.py - script de evidencia mínimo
import time
import polars as pl
start = time.perf_counter()
df = pl.scan_parquet("sample.parquet").group_by("tenant_id").len().collect()
print(f"rows={df.height} elapsed={time.perf_counter() - start:.2f}s")Lo que esto demuestra:
- La pregunta de la carta es falsable
- La salida de la punta es un README corto con recomendación de decisión
- La prueba de concepto explícitamente no está lista para producción
- La ADR sigue para adoptar/rechazar a nivel de flota
Profundización
Cómo Funciona
- Punta (Spike) - Aprendizaje; el código desechable está bien en la carpeta
spikes/. - Prueba de Concepto (PoC) - Demuestra valor a los interesados; todavía no tiene SLO de producción.
- Piloto - Un servicio en producción con indicadores y manual de operaciones - puente hacia la adopción.
- Adopción - Cookiecutter, CI, capacitación, manual de operaciones actualizado.
- Rechazo - La ADR documenta por qué no se eligió - evita debates repetidos mensualmente.
Dimensiones de Evaluación
| Dimensión | Pregunta |
|---|---|
| Operabilidad | ¿Guardia a las 3am? |
| Seguridad | Historial de CVE, cadena de suministro |
| Contratación | ¿Podemos reclutar la habilidad? |
| Costo de salida | Severidad del bloqueo |
| Ajuste | Compatibilidad con Python 3.14 |
Notas de Python
La carpeta spikes/ está ignorada por git para datos grandes; solo confirma README + scriptsTrampas
- La punta se convierte en producción - Sin pruebas ni manual de operaciones. Solución: Lista de verificación de endurecimiento como puerta de entrada al piloto.
- Sin límite de tiempo - Investigación interminable. Solución: Fin de calendario; presenta lo que hayas aprendido.
- Criterios de éxito después de los resultados - Sesgo. Solución: Criterios en la carta antes del código.
- Adoptar porque la demostración es brillante - Se ignora la carga operativa. Solución: Aprobación del operador en la tabla de evaluación.
- Rechazar sin ADR - Volver a debatir trimestralmente. Solución: ADR corta "rechazado Polars 2024; sustituido por ADR-021".
Alternativas
| Alternativa | Usar Cuando | No Usar Cuando |
|---|---|---|
| Comprar SaaS | Capacidad de producto básico | Diferenciador principal |
| No hacer nada ADR | La punta muestra una ganancia insuficiente | Reemplazo de emergencia de CVE |
| Soporte de PoC del proveedor | Gran acuerdo | Pequeño experimento |
| Herramienta interna siempre en punta | Nunca - decidir adoptar/rechazar |
Preguntas Frecuentes
¿Punta vs. Prueba de Concepto?
La punta responde a una pregunta técnica; la prueba de concepto demuestra el valor del producto, puede ser más larga pero aún así con límite de tiempo.
¿Quién aprueba la adopción?
Líder técnico + plataforma + seguridad para herramientas de infraestructura; EM para impacto en el cronograma.
¿Puntas de herramientas LLM?
Incluir conjunto de evaluación, modelo de costos y residencia de datos antes del piloto.
¿Valor de punta fallida?
Alto - documentar por qué no; ahorra tiempo futuro.
¿Múltiples puntas en paralelo?
Limitar el trabajo en curso por escuadrón; las puntas cuentan para la planificación de capacidad.
¿Salud del código abierto?
Verificar el factor autobús, la cadencia de lanzamiento, la respuesta a CVE en la tabla de evaluación.
¿Reemplazar uv?
Requeriría evidencia extraordinaria; la punta compara el tiempo de CI y la compatibilidad de bloqueo.
¿Prueba de concepto en producción?
Solo piloto con indicador, monitorización de SLO y reversión - no sombra silenciosa para siempre.
¿Código de punta fusionado?
Solo se fusionan patrones/pruebas; los scripts desechables permanecen en spikes/ o se eliminan.
¿Enlace a la estimación?
Estimación y Riesgo utiliza los resultados de las puntas.
Relacionados
- Registros de Decisiones de Arquitectura (ADRs) - registro de adopción/rechazo
- Toma de Decisiones Técnicas - opciones clasificadas
- Ejecución de Revisiones de Diseño - resultados de puntas en RFC
- Gobernanza de Dependencias y Cadena de Suministro - aprobación de nuevas dependencias
- Priorización de Plataforma y Deuda Técnica - capacidad para puntas
Versiones de Stack: Esta página fue escrita para Python 3.14.0 (estable 3.14, mantenimiento 3.13), FastAPI 0.115+, Django 5.2, Flask 3.1, Pydantic 2, PyTorch 2.6+, pandas 2.2+, Polars 1.x, ruff 0.9+, y uv 0.6+.