Flujo de trabajo de desarrollo de productos 🚀#

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

Filosofía del producto 🎯#

Principios fundamentales#

1. Entrega rápido, aprende aún más rápido: ciclos de iteración de 2 semanas, enfoque basado primero en el producto mínimo viable
2. Centrado en el usuario: desarrolla las funciones que más solicitan los usuarios y valídalas con datos
3. Primero, el código abierto: desarrollo público; los comentarios de la comunidad orientan la hoja de ruta
4. El rendimiento es una función: tiempos de inferencia inferiores a 1 ms y uso mínimo de memoria
5. Diseño con la API como prioridad: API sencillas e intuitivas que encantan a los desarrolladores

Valores de desarrollo#

• Prioriza la acción: crea prototipos en días y entrega en semanas, no en meses
• Decisiones basadas en datos: las estrellas de GitHub, las descargas de PyPI y las encuestas de Discord orientan las prioridades
• Producto mínimo viable: publica rápidamente una solución al 80 % 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 del desarrollo de funciones 🔄#

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

Identifica las necesidades mediante:

• Comentarios de los usuarios: incidencias de GitHub (votos), encuestas de Discord y sondeos a la comunidad
• Analítica de uso: tasas de adopción de funciones, métricas de los endpoints de la API y registros de errores
• Datos de rendimiento: resultados de las pruebas de rendimiento, tiempos de inferencia y uso de memoria
• Análisis de la competencia: sigue los lanzamientos de la competencia y las tendencias del mercado
• Uso interno de nuestros propios productos: usa nuestras propias herramientas e identifica los puntos problemáticos

Evalúa según estos criterios:

• Impacto en los usuarios: ¿A cuántos usuarios afecta? ¿Cuál es el nivel de dificultad (1-10)? ¿Qué impacto tiene en los ingresos?
• Viabilidad técnica: ¿Qué esfuerzo de ingeniería requiere (S/M/L/XL)? ¿Qué dependencias hay? ¿Qué riesgos?
• Alineación estratégica: ¿refuerza el liderazgo de YOLO? ¿Apoya los sectores verticales clave?
• Disponibilidad de recursos: ¿Qué capacidad tiene el equipo? ¿Qué prioridades compiten? ¿Cuál es el plazo?
• Urgencia competitiva: ¿Se adelantarán los competidores? ¿Existe riesgo de dependencia?

Resultado: lista de funciones pendientes priorizada, con estimaciones de esfuerzo y puntuaciones de impacto en los usuarios

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

Para funciones importantes (más de 2 semanas de trabajo de ingeniería):

• Documento de diseño: descripción 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 y adopción) y objetivos de comentarios 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 las partes interesadas clave

Para funciones pequeñas (menos de 1 semana de trabajo de ingeniería):

• Incidencia de GitHub: descripción clara del problema, enfoque propuesto y criterios de aceptación
• Debate rápido: reunión de 15 minutos con los ingenieros pertinentes
• Aprobación o rechazo: autorización del responsable para continuar

Resultado: especificación aprobada, con alcance, métricas de éxito y calendario claros

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

Ejecución diaria:

• Reunión diaria de seguimiento (15 min): avances de ayer, plan de hoy e impedimentos
• Tiempo de concentración: dedica entre 4 y 6 horas al trabajo profundo y reduce al mínimo las reuniones
• Revisiones de PR: revisa los PR de tus compañeros en un plazo de 4 horas
• Actualizaciones al final del día: publica una actualización de progreso en Slack y actualiza los tickets

Buenas prácticas de desarrollo:

• Indicadores de función: despliega de forma oculta y habilita gradualmente
• Cobertura de pruebas: escribe pruebas antes del lanzamiento (objetivo: más del 80 % de cobertura)
• Documentación: actualiza la documentación en el mismo PR que el código
• Rendimiento: compara los resultados antes y después; no debe haber regresiones
• Seguridad: ejecuta análisis de seguridad y corrige de inmediato los problemas críticos

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 dan prioridad a las revisiones
• Controles 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 del código sensible
• Documentación: comprueba que la documentación esté actualizada y que los ejemplos funcionen
• Aprobación obligatoria: se necesita la aprobación de al menos 1 ingeniero sénior antes de integrar los cambios

Proceso de control de calidad:

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

Ciclo de iteración:

• Resuelve los comentarios de inmediato; no acumules deuda técnica
• Vuelve a probar después de los cambios y comprueba que las correcciones no interrumpan otras funciones
• Actualiza los tickets con los avances y mantén informadas a las partes interesadas

5. Publicación y lanzamiento#

Lista de comprobación previa al lanzamiento:

• Todas las pruebas deben superarse (unitarias, de integración y E2E)
• Las pruebas de rendimiento deben cumplir los objetivos
• La documentación debe estar completa y ser precisa
• El registro de cambios debe incluir las modificaciones visibles para los usuarios
• Guía de migración (si hay cambios incompatibles)
• Plan de reversión documentado
• Supervisión y alertas configuradas

Proceso de publicación:

1. Integración en main: los PR aprobados se integran automáticamente
2. Actualización de versión: control de versiones semántico (major.minor.patch)
3. Etiquetado de la versión: crea una versión en GitHub con el registro de cambios
4. Publicación en PyPI: despliegue automatizado en Python Package Index
5. Actualización de Docker: crea y sube nuevas imágenes de contenedor
6. Despliegue de la documentación: el sitio de documentación se actualiza automáticamente

Comunicación del lanzamiento:

• Publicación en el blog: análisis técnico en profundidad para las funciones importantes
• Redes sociales: anuncios en X, LinkedIn y Discord
• Boletín por correo electrónico: informa a más de 50 000 suscriptores
• Vídeo de lanzamiento: tutorial de YouTube para las funciones complejas
• Participación de la comunidad: supervisa Discord/GitHub y responde a los comentarios

Supervisión tras el lanzamiento (primeras 48 horas):

• Vigila las tasas de errores, la latencia y las métricas de adopción
• Responde a los errores críticos en un plazo de 4 horas
• Proceso de corrección urgente para problemas que interrumpan el servicio (resolución en menos de 24 horas)
• Recopila opiniones de los usuarios y 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 e interacción con las funciones
• Rendimiento: velocidad de inferencia y uso de memoria
• Opiniones de los usuarios: reacciones en GitHub y encuestas en Discord
• Informes de errores: proporción entre problemas críticos y leves

Proceso de publicación 📦#

Control de versiones#

Versionado semántico: MAJOR.MINOR.PATCH

• MAJOR: Cambios incompatibles
• MINOR: Nuevas funciones compatibles con versiones anteriores
• PATCH: Correcciones de errores

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

Calendario de publicaciones#

• Versiones menores: cada 2-4 semanas
• Versiones de parche: cuando sea necesario para corregir problemas críticos
• Versiones mayores: al introducir cambios incompatibles

Lista de comprobación para la publicación#

• Todas las pruebas de CI se superan
• Documentación actualizada
• Registro de cambios actualizado
• Números de versión actualizados
• Publicación creada en GitHub
• Paquete publicado en PyPI
• Anuncio preparado

Proceso para correcciones urgentes#

Para errores críticos:

1. Crea la rama hotfix/ a partir de la etiqueta de la última versión publicada
2. Corrige el problema y añade una prueba
3. Acelera la revisión
4. Publica inmediatamente una versión de parche
5. Integra los cambios en main si es necesario

Priorización de funciones 📊#

Prioridad alta#

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

Prioridad media#

• Mejoras de usabilidad
• Nuevos formatos de exportación
• Compatibilidad ampliada con plataformas
• Mejoras en la documentación

Prioridad baja#

• Funciones deseables
• Optimizaciones menores
• Gestión de casos límite

Menor prioridad#

• Funciones para un único usuario
• Implementaciones excesivamente complejas
• Incorporaciones que exigen mucho mantenimiento
• Fuera del alcance de la misión principal

Métricas y éxito 📈#

Métricas clave#

• Estrellas en GitHub: interés de la comunidad
• Descargas de PyPI: tasa de adopción
• Tiempo de respuesta a incidencias: calidad del soporte
• Tiempo de fusión de las PR: velocidad de desarrollo
• Pruebas de rendimiento: mejoras de velocidad y precisión

Criterios de éxito de las funciones#

Defínelos antes de empezar a desarrollar:

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

Comunicación 💬#

Interna#

• Incidencias de GitHub: propuestas de funciones y errores
• Slack: conversaciones y actualizaciones rápidas
• Reuniones de equipo: reuniones semanales para coordinar prioridades

Externa#

• Debates de GitHub: opiniones de la comunidad
• Discord: asistencia e interacción con los usuarios
• Entradas de blog: anuncios de funciones importantes
• Documentación: notas de la versión y guías

Hoja de ruta del producto 🗺️#

Enfoque actual#

• Familia de modelos YOLO26
• Compatibilidad con formatos de exportación
• Optimización del rendimiento
• Calidad de la documentación

Próximas áreas#

• Nuevas variantes de arquitectura
• Funciones de entrenamiento mejoradas
• Velocidad de inferencia mejorada
• Compatibilidad con plataformas ampliada

Visión a largo plazo#

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

Buenas prácticas ✅#

Desarrollo de funciones#

• Empieza por lo pequeño: crea primero un producto mínimo viable (MVP) y amplíalo más adelante
• Pruebas con usuarios: recopila opiniones pronto
• Prioriza el rendimiento: optimiza desde el principio
• Documenta bien: redacta la documentación mientras desarrollas

Gestión de publicaciones#

• Prueba a fondo: CI y pruebas manuales
• Registro de cambios claro: qué ha cambiado y por qué es importante
• Actualizaciones sin problemas: compatibilidad con versiones anteriores siempre que sea posible
• Correcciones rápidas: no dejes que los errores se queden sin resolver

Participación de la comunidad#

• Ágiles: responde a las incidencias en un plazo de 24 horas
• Transparentes: comparte la hoja de ruta y las decisiones
• Agradecidos: da las gracias a quienes contribuyen
• Inclusivos: da la bienvenida a personas de todos los niveles

Recursos 📚#

• Flujo de trabajo de desarrollo - Proceso y normas para las PR
• CI/Pruebas - Pruebas y controles de calidad
• Documentación - Redacción y mantenimiento de la documentación
• Incidencias de GitHub - Solicitudes de funciones y errores