Flujo de desarrollo de productos 🚀#

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

Filosofía de producto 🎯#

Principios fundamentales#

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

Valores de desarrollo#

• Predisposición a la acción: crea prototipos en días y 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 rápidamente una solución al 80 % e 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 y aportaciones de la comunidad

Ciclo de vida del desarrollo de funcionalidades 🔄#

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

Identifica las necesidades mediante:

• Comentarios de los usuarios: incidencias de GitHub (votos), encuestas de Discord y encuestas a la comunidad
• Analítica de uso: tasas de adopción de funcionalidades, métricas de endpoints de la API y registros de errores
• Datos de rendimiento: resultados de pruebas comparativas, 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 nuestras propias herramientas: utiliza nuestras propias herramientas e identifica los puntos problemáticos

Evalúa según:

• 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: ¿cuánto esfuerzo de ingeniería requiere (S/M/L/XL)? ¿Qué dependencias hay? ¿Qué riesgos existen?
• Alineación estratégica: ¿refuerza el liderazgo de YOLO? ¿Apoya sectores verticales clave?
• Disponibilidad de recursos: ¿qué capacidad tiene el equipo? ¿Qué prioridades compiten entre sí? ¿Cuál es el calendario?
• Urgencia competitiva: ¿lanzará antes la competencia? ¿Existe riesgo de dependencia?

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

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

Para funcionalidades importantes (más de 2 semanas de trabajo 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 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 del equipo de ingeniería, producto y las partes interesadas clave

Para funcionalidades 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 sincronización de 15 minutos con los ingenieros pertinentes
• Adelante/no adelante: aprobación del responsable para continuar

Resultado: especificación aprobada con un 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 funcionalidades en tareas de menos de 1 día
• Planificación de la capacidad: ten en cuenta las reuniones, las revisiones de PR y el soporte
• Dependencias: identifica los bloqueos y coordínate con otros equipos

Ejecución diaria:

• Reunión diaria (15 min): progreso de ayer, plan de hoy y bloqueos
• Tiempo de concentración: 4-6 horas de trabajo profundo y minimiza las reuniones
• Revisiones de PR: revisa las PR de tus compañeros en un plazo de 4 horas
• Actualizaciones al final del día: publica una actualización del progreso en Slack y mueve los tickets

Buenas prácticas de desarrollo:

• Indicadores de funcionalidades: despliega de forma oculta y habilita gradualmente
• Cobertura de pruebas: escribe las pruebas antes del lanzamiento (objetivo de cobertura superior al 80 %)
• Documentación: actualiza la documentación en la misma PR que el código
• Rendimiento: realiza pruebas comparativas antes y después, sin regresiones
• Seguridad: ejecuta análisis de seguridad y corrige inmediatamente los problemas críticos

Sigue el flujo 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 todas las PR):

• Tiempo de respuesta inferior a 24 horas: los ingenieros sénior dan prioridad a 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 del código sensible
• Documentación: verifica que la documentación esté actualizada y que los ejemplos funcionen
• Aprobación obligatoria: se necesita la aprobación de al menos un ingeniero sénior antes de fusionar

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: realiza pruebas comparativas con respecto a la referencia y marca las regresiones
• Multiplataforma: prueba en CPU, GPU y dispositivos periféricos
• Aceptación por parte de los usuarios: realiza pruebas beta con usuarios seleccionados para las funcionalidades 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 funcionalidades
• Actualiza los tickets con el progreso y mantén informadas a las partes interesadas

5. Lanzamiento y puesta en marcha#

Lista de comprobación previa al lanzamiento:

• Todas las pruebas superadas (unitarias, de integración y E2E)
• Las pruebas comparativas de rendimiento cumplen los objetivos
• Documentación completa y precisa
• Registro de cambios actualizado con los cambios 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 lanzamiento:

1. Fusión en main: las PR aprobadas se fusionan automáticamente
2. Incremento de versión: versionado semántico (major.minor.patch)
3. Etiquetado del lanzamiento: crea un lanzamiento de GitHub con el registro de cambios
4. Publicación en PyPI: despliegue automatizado en el índice de paquetes de Python
5. Actualización de Docker: crea y publica nuevas imágenes de contenedor
6. Despliegue de la documentación: el sitio de documentación se actualiza automáticamente

Comunicación del lanzamiento:

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

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

• Controla 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 corrección urgente para problemas graves (resolución en menos de 24 horas)
• Recopila los comentarios 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 funcionalidades
• Rendimiento: velocidad de inferencia y uso de memoria
• Comentarios 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 📦#

Versionado#

Versionado semántico: MAJOR.MINOR.PATCH

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

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

Calendario de publicaciones#

• Publicaciones menores: Cada 2-4 semanas
• Publicaciones de parche: Según sea necesario para correcciones críticas
• Publicaciones mayores: Al introducir cambios incompatibles

Lista de comprobación de la publicación#

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

Proceso de corrección urgente#

Para errores críticos:

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

Priorización de funcionalidades 📊#

Prioridad alta#

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

Prioridad media#

• Mejoras de calidad de vida
• Nuevos formatos de exportación
• Compatibilidad ampliada con plataformas
• Mejoras de la documentación

Prioridad baja#

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

Despriorizado#

• Funcionalidades para un solo usuario
• Implementaciones excesivamente complejas
• Adiciones con una elevada carga de mantenimiento
• Fuera del alcance de la misión principal

Métricas y éxito 📈#

Métricas clave#

• Estrellas de 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 PR: Velocidad de desarrollo
• Pruebas comparativas de rendimiento: Mejoras de velocidad y precisión

Criterios de éxito de las funcionalidades#

Defínelos antes de crear la funcionalidad:

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

Comunicación 💬#

Interna#

• Incidencias de GitHub: Propuestas de funcionalidades y errores
• Slack: Debates y actualizaciones rápidas
• Reuniones del equipo: Reuniones semanales de coordinación sobre prioridades

Externa#

• Debates de GitHub: Comentarios de la comunidad
• Discord: Soporte e interacción con los usuarios
• Publicaciones del blog: Anuncios de funcionalidades 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
• Funcionalidades 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 fluido en todas las plataformas
• Kit de herramientas integral de visión artificial
• Innovación impulsada por la comunidad

Buenas prácticas ✅#

Desarrollo de funcionalidades#

• Empieza por algo pequeño: Primero el MVP y amplíalo después
• Pruebas con usuarios: Recopila comentarios desde el principio
• El rendimiento es lo primero: Optimiza desde el inicio
• Documenta bien: Escribe la documentación mientras desarrollas

Gestión de versiones#

• Prueba a fondo: CI + pruebas manuales
• Registro de cambios claro: Qué ha cambiado y por qué es importante
• Actualizaciones fluidas: Compatibilidad con versiones anteriores cuando sea posible
• Correcciones rápidas: No dejes que los errores se prolonguen

Participación en la comunidad#

• Responde con rapidez: Responde a los problemas en un plazo de 24 horas
• Transparencia: Comparte la hoja de ruta y las decisiones
• Agradecimiento: Da las gracias a quienes contribuyen
• Inclusividad: Da la bienvenida a personas con cualquier nivel de conocimientos

Recursos 📚#

• Flujo de trabajo de desarrollo - Proceso y estándares de PR
• CI/Testing - Pruebas y controles de calidad
• Documentation - Redacción y mantenimiento de la documentación
• GitHub Issues - Solicitudes de funcionalidades y errores