YOLO Vision 2026:

Flujo 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.

Filosofía de producto 🎯#

Principios básicos#

  1. Lanza rápido, aprende más rápido: ciclos de iteración de 2 semanas, enfoque centrado en el MVP
  2. Centrado en el usuario: construye las funciones que los usuarios más solicitan y valídalas con datos
  3. Código abierto primero: desarrollo público, los comentarios de la comunidad guían la hoja de ruta
  4. El rendimiento es una función: tiempos de inferencia inferiores a un milisegundo y huella de memoria mínima
  5. Diseño centrado en la API: API simples e intuitivas que encantan a los desarrolladores

Valores de desarrollo#

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

Ciclo de vida de desarrollo de funciones 🔄#

1. Descubrimiento y planificación (Semana 1)#

Identifica necesidades a través de:

  • Comentarios de los usuarios: incidencias de GitHub (votos), encuestas de Discord y encuestas de la comunidad
  • Analítica de uso: tasas de adopción de funciones, métricas de puntos finales de la API y registros de errores
  • Datos de rendimiento: resultados de pruebas comparativas, tiempos de inferencia y uso de memoria
  • Análisis competitivo: seguimiento de lanzamientos de la competencia y tendencias del mercado
  • Consumo interno: usa tus propias herramientas e 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: ¿impulsa el liderazgo en YOLO? ¿Soporta verticales clave?
  • Disponibilidad de recursos: ¿capacidad del equipo? ¿Prioridades contrapuestas? ¿Cronograma?
  • Urgencia competitiva: ¿la competencia lanzará primero? ¿Riesgo de dependencia del proveedor?

Resultado: cartera de funciones priorizada con estimaciones de esfuerzo y puntuaciones de impacto en el usuario

2. Diseño y especificación (Días 1-3)#

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

  • Documento de diseño: planteamiento del problema, solución propuesta, alternativas consideradas y métricas de éxito
  • Especificación técnica: diseño de la API, diagramas de arquitectura, modelos de datos y casos límite
  • 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 y 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):

  • Incidencia de GitHub: descripción clara del problema, enfoque propuesto y criterios de aceptación
  • Discusión rápida: sincronización de 15 minutos con los ingenieros pertinentes
  • Aprobación: autorización del gerente para continuar

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

3. Implementación (ejecución de sprints)#

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 capacidad: ten en cuenta las reuniones, las revisiones de PR y el soporte
  • Dependencias: identifica bloqueadores y coordínate con otros equipos

Ejecución diaria:

  • Reunión matutina (15 min): progreso de ayer, plan de hoy y bloqueadores
  • Tiempo de concentración: 4-6 horas de trabajo profundo, minimiza las reuniones
  • Revisiones de PR: revisa los PR de tus compañeros en menos de 4 horas
  • Actualizaciones de final del día: actualización de progreso en Slack y movimiento de tickets

Buenas prácticas de desarrollo:

  • Indicadores de características: despliega de forma oculta y habilítalos gradualmente
  • Cobertura de pruebas: escribe pruebas antes de enviar a producción (objetivo de cobertura >80%)
  • Documentación: actualiza la documentación en el mismo PR que el código
  • Rendimiento: realiza pruebas comparativas antes y después, sin regresiones
  • Seguridad: ejecuta análisis de seguridad y soluciona los problemas críticos inmediatamente

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

4. Revisión y control de calidad (en paralelo con la implementación)#

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

  • Tiempo de respuesta inferior a 24 horas: los ingenieros sénior priorizan las revisiones
  • Comprobaciones de calidad: corrección del código, cobertura de pruebas e impacto en el rendimiento
  • Revisión de seguridad: análisis automatizados y revisión manual para código sensible
  • Documentación: verifica que la documentación esté actualizada y que los ejemplos funcionen
  • Aprobación obligatoria: se requiere la aprobación de al menos un ingeniero sénior antes de fusionar

Proceso de control de calidad:

  • Pruebas automatizadas: pruebas unitarias, de integración y de extremo a extremo (E2E) que se ejecutan en cada confirmación
  • Pruebas manuales: un ingeniero de control de calidad valida los flujos de usuario clave
  • Pruebas de rendimiento: realiza pruebas comparativas con respecto a la línea base y señala las regresiones
  • Multiplataforma: prueba en CPU, GPU y dispositivos periféricos
  • Aceptación del usuario: prueba beta con usuarios seleccionados para funciones importantes

Ciclo de iteración:

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

5. Lanzamiento y despliegue#

Lista de comprobación previa al lanzamiento:

  • Todas las pruebas se han superado (unitarias, de integración y E2E)
  • Las pruebas comparativas de rendimiento cumplen los objetivos
  • La documentación está completa y es precisa
  • El registro de cambios se ha actualizado con los cambios visibles para el usuario
  • Guía de migración (si hay cambios que rompen la compatibilidad)
  • Plan de reversión documentado
  • Supervisión y alertas configuradas

Proceso de lanzamiento:

  1. Fusionar en main: los PR aprobados se fusionan automáticamente
  2. Incremento de versión: versionado semántico (mayor.menor.parche)
  3. Etiquetar lanzamiento: crea un lanzamiento en GitHub con el registro de cambios
  4. Publicación en PyPI: despliegue automatizado en Python Package Index
  5. Actualización de Docker: construye y envía nuevas imágenes de contenedores
  6. Despliegue de documentación: el sitio de documentación se actualiza automáticamente

Comunicación de lanzamiento:

  • Entrada de blog: análisis técnico detallado para funciones importantes
  • Redes sociales: anuncios en X, LinkedIn y Discord
  • Boletín informativo por correo electrónico: notifica a más de 50.000 suscriptores
  • Vídeo de lanzamiento: tutorial de YouTube para funciones complejas
  • Participación de la comunidad: supervisa Discord y GitHub, responde a los comentarios

Supervisión posterior al lanzamiento (primeras 48 horas):

  • Observa tasas de errores, latencia y métricas de adopción
  • Responde a errores críticos en menos de 4 horas
  • Proceso de hotfix para problemas graves (tiempo de resolución inferior a 24 horas)
  • Recopila comentarios de usuarios y prioriza 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 características
  • Rendimiento: velocidad de inferencia, uso de memoria
  • Comentarios de usuarios: reacciones en GitHub, encuestas en Discord
  • Informes de errores: relación entre problemas críticos y menores

Proceso de lanzamiento 📦#

Versionado#

Versionado semántico: MAJOR.MINOR.PATCH

  • MAJOR: Cambios importantes que rompen la compatibilidad
  • MINOR: Nuevas características, compatibles con versiones anteriores
  • PATCH: Corrección de errores

Ejemplo: 11.0.0 → 11.1.0 (nueva característica) → 11.1.1 (corrección de errores)

Calendario de lanzamientos#

  • Lanzamientos menores: Cada 2-4 semanas
  • Lanzamientos de parches: Según sea necesario para correcciones críticas
  • Lanzamientos mayores: Al introducir cambios que rompen la compatibilidad

Lista de verificación de lanzamiento#

  • Todas las pruebas de CI pasan correctamente
  • Documentación actualizada
  • Registro de cambios actualizado
  • Números de versión incrementados
  • Lanzamiento de GitHub creado
  • Paquete de PyPI publicado
  • Anuncio preparado

Proceso de hotfix#

Para errores críticos:

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

Priorización de características 📊#

Prioridad alta#

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

Prioridad media#

  • Mejoras de comodidad y usabilidad
  • Nuevos formatos de exportación
  • Soporte de plataforma extendido
  • Mejoras en la documentación

Prioridad baja#

  • Características secundarias o accesorias
  • Optimización menor
  • Gestión de casos límite

Despriorizado#

  • Características para un solo usuario
  • Implementaciones demasiado complejas
  • Adiciones que requieren mucho mantenimiento
  • Fuera del ámbito de la misión principal

Métricas y éxito 📈#

Mé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 y precisión

Criterios de éxito de las características#

Define antes de desarrollar:

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

Comunicación 💬#

Interna#

  • GitHub Issues: Propuestas de características y errores
  • Slack: Debates rápidos y actualizaciones
  • Team Meetings: Sincronizaciones semanales sobre prioridades

Externa#

  • GitHub Discussions: Comentarios de la comunidad
  • Discord: Soporte e interacción con usuarios
  • Blog Posts: Anuncios de características principales
  • Documentation: Notas de lanzamiento y guías

Hoja de ruta del producto 🗺️#

Enfoque actual#

Próximas áreas#

Visión a largo plazo#

  • La mejor detección de objetos de código abierto del mundo
  • Despliegue fluido en todas las plataformas
  • Kit de herramientas de visión por computador completo
  • Innovación impulsada por la comunidad

Buenas prácticas ✅#

Desarrollo de características#

  • Start small: MVP primero, expande después
  • User testing: Obtén comentarios pronto
  • Performance first: Optimiza desde el principio
  • Documenta bien: Escribe documentación mientras construyes

Gestión de lanzamientos#

  • Prueba a fondo: CI + pruebas manuales
  • Registro de cambios claro: Qué ha cambiado y por qué importa
  • Actualizaciones fluidas: Compatibilidad hacia atrás cuando sea posible
  • Correcciones rápidas: No dejes que los errores persistan

Participación de la comunidad#

  • Respuesta rápida: Responde a las incidencias en menos de 24 horas
  • Transparente: Comparte la hoja de ruta y las decisiones
  • Agradecido: Da las gracias a los colaboradores
  • Inclusivo: Da la bienvenida a todos los niveles de habilidad

Recursos 📚#

Colaboradores
GLglenn-jocher6