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 del producto 🎯
Principios 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
Valores 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
Ciclo de vida del desarrollo de funciones 🔄
Descubrimiento 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
Diseñ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
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 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.
Revisió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
Lanzamiento 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
Proceso de lanzamiento 📦
Control 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)
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 disruptivos
Lista de verificación de lanzamiento
- Todas las pruebas de CI superadas
- Documentación actualizada
- Registro de cambios actualizado
- Números de versión actualizados
- Lanzamiento en GitHub creado
- Paquete de PyPI publicado
- Anuncio preparado
Proceso 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
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 solicitudes de la comunidad)
Prioridad media
- Mejoras de calidad de vida
- Nuevos formatos de exportación
- Soporte de plataforma extendido
- Mejoras en la documentación
Prioridad baja
- Funciones interesantes pero no esenciales
- Optimizaciones menores
- Manejo de casos excepcionales
Sin prioridad
- Funciones para un solo usuario
- Implementaciones demasiado complejas
- Añadidos que requieren mucho mantenimiento
- Fuera del alcance 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/precisión
Criterios 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)
Comunicación 💬
Interna
- GitHub Issues: propuestas de funciones y errores
- Slack: debates rápidos y actualizaciones
- Team Meetings: sincronizaciones semanales sobre prioridades
Externa
- 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
Hoja de ruta del producto 🗺️
Enfoque actual
- Familia de modelos YOLO26
- Soporte de formato 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
- Soporte de plataforma extendido
Visió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
Mejores prácticas ✅
Desarrollo 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
Gestió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
Participació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
Recursos 📚
- 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