4 min lectura • Guide 753 of 877
Especificaciones Técnicas para Desarrollo
Buenas especificaciones previenen retrabajos. GitScrum ayuda a equipos a crear y trackear specs técnicas que guían implementación efectivamente.
Cuándo Escribir Specs
¿NECESITAS UNA SPEC TÉCNICA?
┌─────────────────────────────────────────────────────────────┐
│ │
│ ¿Es este trabajo significativo? │
│ (> 1 semana de trabajo, múltiples componentes, riesgoso) │
│ │
│ SÍ NO │
│ ↓ ↓ │
│ ¿Se necesita coordinación ¿Está bien entendido? │
│ cross-team? │
│ SÍ → Descripción de tarea │
│ SÍ → SPEC COMPLETA NO → Mini-spec o RFC │
│ NO → ¿Es arquitecturalmente │
│ significativo? │
│ │
│ SÍ → DESIGN DOC / ADR │
│ NO → MINI-SPEC │
│ │
│ ═══════════════════════════════════════════════════════════ │
│ │
│ SPEC COMPLETA: Nuevas features, rediseños, integraciones │
│ MINI-SPEC: Cambios menores que necesitan claridad │
│ ADR: Decisiones de arquitectura │
│ DESC TAREA: Trabajo pequeño, bien entendido │
│ │
│ EN CASO DE DUDA: │
│ Si necesitarías explicarlo a alguien por > 5 minutos, │
│ escríbelo. │
└─────────────────────────────────────────────────────────────┘
Estructura de Spec
TEMPLATE DE ESPECIFICACIÓN TÉCNICA:
┌─────────────────────────────────────────────────────────────┐
│ SPEC: Feature de Export de Usuario │
├─────────────────────────────────────────────────────────────┤
│ │
│ Autor: @alex │
│ Estado: Draft → Review → Aprobado │
│ Fecha: 2024-01-15 │
│ Tarea Relacionada: PROJ-123 │
│ │
│ ═══════════════════════════════════════════════════════════ │
│ │
│ 1. OVERVIEW │
│ ─────────── │
│ Resumen breve de qué hace esta feature y por qué. │
│ │
│ 2. BACKGROUND │
│ ──────────── │
│ Contexto: ¿Por qué estamos construyendo esto? │
│ Estado actual: ¿Cómo funciona hoy? │
│ │
│ 3. REQUISITOS │
│ ───────────── │
│ Funcionales: Qué debe hacer │
│ No-funcionales: Performance, seguridad │
│ │
│ 4. DISEÑO TÉCNICO │
│ ──────────────── │
│ Approach propuesto │
│ API contracts │
│ Cambios de data model │
│ │
│ 5. EDGE CASES │
│ ───────────── │
│ ¿Qué pasa si...? │
│ Escenarios de error │
│ │
│ 6. ALTERNATIVAS CONSIDERADAS │
│ ──────────────────────────── │
│ Otras opciones y por qué no las elegimos │
│ │
└─────────────────────────────────────────────────────────────┘
Niveles de Detalle
NIVEL DE DETALLE POR AUDIENCIA
══════════════════════════════
PARA STAKEHOLDERS:
┌─────────────────────────────────────────────────────────────┐
│ • Overview de alto nivel │
│ • Impacto en negocio │
│ • Timeline y milestones │
│ • Riesgos y mitigaciones │
└─────────────────────────────────────────────────────────────┘
PARA DEVELOPERS:
┌─────────────────────────────────────────────────────────────┐
│ • Detalles de implementación │
│ • API contracts │
│ • Cambios de data model │
│ • Edge cases y manejo de errores │
│ • Testing approach │
└─────────────────────────────────────────────────────────────┘
PARA QA:
┌─────────────────────────────────────────────────────────────┐
│ • Criterios de aceptación │
│ • Escenarios de test │
│ • Requisitos de performance │
│ • Consideraciones de seguridad │
└─────────────────────────────────────────────────────────────┘