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

  1. Lanza rápido, aprende más rápido: ciclos de iteración de 2 semanas, enfoque basado primero en el MVP
  2. Centrado en el usuario: desarrolla las funciones que los usuarios solicitan más, valida 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 característica: tiempos de inferencia inferiores al ms, huella de memoria mínima
  5. 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:

  1. Fusión a la rama main: los PR aprobados se fusionan automáticamente
  2. Aumento de versión: versionado semántico (mayor.minor.patch)
  3. Etiqueta de 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: crea y envía nuevas imágenes de contenedor
  6. 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.011.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:

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

Próximas áreas

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 📚