Link to this sectionFlujo de trabajo de desarrollo de productos 🚀#

Esta guía cubre la planificación de productos, los ciclos de desarrollo y los procesos de lanzamiento para los productos de Ultralytics.

Link to this sectionFilosofía del producto 🎯#

Link to this sectionPrincipios fundamentales#

Lanza rápido, aprende más rápido: ciclos de iteración de 2 semanas, enfoque basado primero en el MVP
Centrado en el usuario: desarrolla las funciones que los usuarios solicitan más, valida con datos
Código abierto primero: desarrollo público, los comentarios de la comunidad impulsan la hoja de ruta
El rendimiento es una característica: tiempos de inferencia inferiores al ms, huella de memoria mínima
Diseño que prioriza la API: APIs simples e intuitivas que encantan a los desarrolladores

Link to this sectionValores de desarrollo#

Predisposición a la acción: prototipa en días, lanza en semanas, no meses
Decisiones basadas en datos: las estrellas de GitHub, las descargas de PyPI y las encuestas en Discord guían las prioridades
Producto mínimo viable: lanza una solución al 80% rápidamente, itera hasta llegar al 100%
Despliegue continuo: la rama principal siempre está lista para producción
Transparencia radical: hoja de ruta pública, métricas abiertas, aportaciones de la comunidad

Link to this sectionCiclo de vida del desarrollo de funciones 🔄#

Link to this sectionDescubrimiento y planificación (semana 1)#

Identifica necesidades mediante:

Comentarios de los usuarios: issues de GitHub (votos), encuestas en Discord, encuestas a la comunidad
Análisis de uso: tasas de adopción de funciones, métricas de endpoints de la API, registros de errores
Datos de rendimiento: resultados de benchmarks, tiempos de inferencia, uso de memoria
Análisis competitivo: sigue los lanzamientos de la competencia, tendencias del mercado
Dogfooding interno: usa nuestras propias herramientas, identifica puntos débiles

Evalúa según:

Impacto en el usuario: ¿cuántos usuarios se ven afectados? ¿Nivel de dolor (1-10)? ¿Impacto en los ingresos?
Viabilidad técnica: ¿esfuerzo de ingeniería (S/M/L/XL)? ¿Dependencias? ¿Riesgos?
Alineación estratégica: ¿avanza el liderazgo de YOLO? ¿Soporta verticales clave?
Disponibilidad de recursos: ¿capacidad del equipo? ¿Prioridades competitivas? ¿Cronograma?
Urgencia competitiva: ¿lanzará la competencia primero? ¿Riesgo de bloqueo?

Resultado: backlog de funciones priorizado con estimaciones de esfuerzo y puntuaciones de impacto en el usuario

Link to this sectionDiseño y especificación (días 1-3)#

Para funciones principales (>2 semanas de tiempo de ingeniería):

Documento de diseño: planteamiento del problema, solución propuesta, alternativas consideradas, métricas de éxito
Especificación técnica: diseño de API, diagramas de arquitectura, modelos de datos, casos extremos
Criterios de éxito: métricas cuantitativas (velocidad, precisión, adopción) y objetivos de retroalimentación de los usuarios
Evaluación de riesgos: riesgos técnicos, dependencias, plan de reversión
Revisión del equipo: comentarios de ingeniería, producto y partes interesadas clave

Para funciones pequeñas (<1 semana de tiempo de ingeniería):

Issue de GitHub: descripción clara del problema, enfoque propuesto, criterios de aceptación
Discusión rápida: sincronización de 15 minutos con ingenieros relevantes
Go/No-go: aprobación del gestor para proceder

Resultado: especificación aprobada con alcance claro, métricas de éxito y cronograma

Link to this sectionImplementación (ejecución del sprint)#

Planificación del sprint (cada 2 semanas):

Objetivo del sprint: un objetivo claro por sprint
Desglose de tareas: divide las funciones en tareas de menos de 1 día
Planificación de la capacidad: ten en cuenta las reuniones, las revisiones de PR, el soporte
Dependencias: identifica bloqueadores, coordínate con otros equipos

Ejecución diaria:

Standup matutino (15 min): progreso de ayer, plan de hoy, bloqueadores
Tiempo de enfoque: 4-6 horas de trabajo profundo, minimiza las reuniones
Revisiones de PR: revisa los PR de tus compañeros en un plazo de 4 horas
Actualizaciones al final del día: actualización de progreso en Slack, mueve tickets

Mejores prácticas de desarrollo:

Feature flags: despliega en oscuro, habilita gradualmente
Cobertura de pruebas: escribe pruebas antes de lanzar (objetivo de cobertura >80%)
Documentación: actualiza la documentación en el mismo PR que el código
Rendimiento: haz benchmarks antes/después, sin regresiones
Seguridad: ejecuta escaneos de seguridad, corrige problemas críticos de inmediato

Sigue el flujo de trabajo de desarrollo detallado para el proceso de PR y los estándares de código.

Link to this sectionRevisión y QA (paralelo a la implementación)#

Revisión de código (obligatoria para todos los PR):

Tiempo de respuesta <24 horas: los ingenieros sénior priorizan las revisiones
Controles de calidad: corrección del código, cobertura de pruebas, impacto en el rendimiento
Revisión de seguridad: escaneos automatizados + revisión manual para código sensible
Documentación: verifica que la documentación esté actualizada y los ejemplos funcionen
Aprobación necesaria: 1+ aprobación de un ingeniero sénior antes de fusionar

Proceso de QA:

Pruebas automatizadas: pruebas unitarias, de integración y E2E ejecutadas en cada commit
Pruebas manuales: el ingeniero de QA valida los flujos de usuario clave
Pruebas de rendimiento: realiza un benchmark frente a la línea base, marca las regresiones
Multiplataforma: prueba en CPU, GPU, dispositivos edge
Aceptación del usuario: beta testing con usuarios seleccionados para funciones importantes

Ciclo de iteración:

Aborda los comentarios de inmediato, no acumules deuda técnica
Vuelve a probar después de los cambios, verifica que las correcciones no rompan otras funciones
Actualiza los tickets con el progreso, mantén informadas a las partes interesadas

Link to this sectionLanzamiento y puesta en marcha#

Lista de verificación previa al lanzamiento:

Todas las pruebas superadas (unitarias, de integración, E2E)
Los benchmarks de rendimiento cumplen los objetivos
Documentación completa y precisa
Registro de cambios (changelog) actualizado con cambios orientados al usuario
Guía de migración (si hay cambios importantes)
Plan de reversión documentado
Monitoreo y alertas configurados

Proceso de lanzamiento:

Fusión a la rama main: los PR aprobados se fusionan automáticamente
Aumento de versión: versionado semántico (mayor.minor.patch)
Etiqueta de lanzamiento: crea un lanzamiento en GitHub con el registro de cambios
Publicación en PyPI: despliegue automatizado en Python Package Index
Actualización de Docker: crea y envía nuevas imágenes de contenedor
Despliegue de docs: el sitio de documentación se actualiza automáticamente

Comunicación del lanzamiento:

Publicación en el blog: análisis técnico profundo de las funciones principales
Redes sociales: anuncios en X, LinkedIn, Discord
Newsletter por correo: notifica a más de 50.000 suscriptores
Vídeo de lanzamiento: tutorial en YouTube para funciones complejas
Participación de la comunidad: monitorea Discord/GitHub, responde a los comentarios

Monitoreo posterior al lanzamiento (primeras 48 horas):

Observa las tasas de error, la latencia y las métricas de adopción
Responde a los errores críticos en un plazo de 4 horas
Proceso de hotfix para problemas graves (tiempo de resolución <24 horas)
Recopila comentarios de los usuarios, prioriza las mejoras rápidas

Medición del éxito (primeras 2 semanas):

Tasa de adopción: % de usuarios que actualizan
Métricas de uso: llamadas a la API, interacción con funciones
Rendimiento: velocidad de inferencia, uso de memoria
Comentarios de los usuarios: reacciones en GitHub, encuestas en Discord
Informes de errores: proporción de problemas críticos frente a menores

Link to this sectionProceso de lanzamiento 📦#

Link to this sectionControl de versiones#

Control de versiones semántico: MAJOR.MINOR.PATCH

MAJOR: cambios disruptivos
MINOR: nuevas funciones, compatibilidad con versiones anteriores
PATCH: corrección de errores

Ejemplo: 11.0.0 → 11.1.0 (nueva función) → 11.1.1 (corrección de errores)

Link to this sectionCalendario de lanzamientos#

Lanzamientos menores: cada 2-4 semanas
Lanzamientos de parches: según sea necesario para correcciones críticas
Lanzamientos mayores: al introducir cambios disruptivos

Link to this sectionLista de verificación de lanzamiento#

Link to this sectionProceso de hotfix#

Para errores críticos:

Crea una rama hotfix/ a partir de la última etiqueta de lanzamiento
Corrige el problema, añade una prueba
Revisión acelerada
Publica la versión de parche inmediatamente
Aplica el backport a main si es necesario

Link to this sectionPriorización de funciones 📊#

Link to this sectionPrioridad alta#

Errores críticos que afectan a los usuarios
Mejoras de rendimiento
Problemas de seguridad
Funciones muy solicitadas (más de 10 solicitudes de la comunidad)

Link to this sectionPrioridad media#

Mejoras de calidad de vida
Nuevos formatos de exportación
Soporte de plataforma extendido
Mejoras en la documentación

Link to this sectionPrioridad baja#

Funciones interesantes pero no esenciales
Optimizaciones menores
Manejo de casos excepcionales

Link to this sectionSin prioridad#

Funciones para un solo usuario
Implementaciones demasiado complejas
Añadidos que requieren mucho mantenimiento
Fuera del alcance de la misión principal

Link to this sectionMétricas y éxito 📈#

Link to this sectionMétricas clave#

GitHub Stars: interés de la comunidad
PyPI Downloads: tasa de adopción
Issue Response Time: calidad del soporte
PR Merge Time: velocidad de desarrollo
Performance Benchmarks: mejoras de velocidad/precisión

Link to this sectionCriterios de éxito de las funciones#

Define antes de construir:

Métricas de uso (descargas, llamadas a la API)
Objetivos de rendimiento (velocidad, precisión)
Comentarios de usuarios (reacciones en GitHub, comentarios)
Tasa de adopción (porcentaje que utiliza la función)

Link to this sectionComunicación 💬#

Link to this sectionInterna#

GitHub Issues: propuestas de funciones y errores
Slack: debates rápidos y actualizaciones
Team Meetings: sincronizaciones semanales sobre prioridades

Link to this sectionExterna#

GitHub Discussions: comentarios de la comunidad
Discord: soporte al usuario e interacción
Blog Posts: anuncios de funciones importantes
Documentation: notas de lanzamiento y guías

Link to this sectionHoja de ruta del producto 🗺️#

Link to this sectionEnfoque actual#

Link to this sectionPróximas áreas#

Link to this sectionVisión a largo plazo#

La mejor detección de objetos de código abierto del mundo
Implementación fluida en todas las plataformas
Kit de herramientas integral de visión artificial
Innovación impulsada por la comunidad

Link to this sectionMejores prácticas ✅#

Link to this sectionDesarrollo de funciones#

Empieza poco a poco: primero el MVP, luego amplía
Pruebas de usuario: obtén comentarios pronto
El rendimiento es lo primero: optimiza desde el principio
Documenta bien: escribe documentación mientras desarrollas

Link to this sectionGestión de lanzamientos#

Prueba a fondo: CI + pruebas manuales
Registro de cambios claro: qué ha cambiado y por qué es importante
Actualizaciones fluidas: compatibilidad con versiones anteriores siempre que sea posible
Arreglos rápidos: no dejes que los errores persistan

Link to this sectionParticipación comunitaria#

Capacidad de respuesta: responde a los problemas en un plazo de 24 horas
Transparencia: comparte la hoja de ruta y las decisiones
Agradecimiento: da las gracias a los colaboradores
Inclusividad: da la bienvenida a todos los niveles de habilidad

Link to this sectionRecursos 📚#

Flujo de trabajo de desarrollo - proceso de PR y estándares
CI/Pruebas - pruebas y controles de calidad
Documentación - redacción y mantenimiento de documentación
Problemas de GitHub - solicitudes de funciones y errores

Colaboradores

GLglenn-jocher⁶

Creado 27 ago 2025Actualizado el mes pasado