Skip to main content
Editar en GitHub (EN)

Flujo de trabajo 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 Ultralytics.

Filosofía del producto 🎯

Principios fundamentales

  1. Entrega rápida, aprendizaje aún más rápido: Ciclos de iteración de dos semanas, enfoque basado en el MVP
  2. Centrado en el usuario: Desarrolla las funciones que más solicitan los usuarios y comprueba su eficacia con datos
  3. El código abierto es lo primero: El desarrollo público y las opiniones de la comunidad marcan el rumbo
  4. El rendimiento es una característica: Tiempos de inferencia inferiores a un milisegundo, consumo mínimo de memoria
  5. Diseño centrado en la API: API sencillas e intuitivas que encantan a los desarrolladores

Valores de desarrollo

  • Inclinarme por la acción: Prototipos en cuestión de días, envíos en semanas, no en meses
  • Decisiones basadas en datos: Las estrellas de GitHub, PyPI y las encuestas de Discord marcan las prioridades
  • Producto mínimo viable: Liberar rápidamente la solución al 80 %; repetir hasta alcanzar el 100 %
  • Implementación continua: La rama principal siempre está lista para la producción
  • Transparencia radical: Hoja de ruta pública, métricas abiertas, aportaciones de la comunidad

Ciclo de vida del desarrollo de funciones 🔄

1. Análisis y planificación (Semana 1)

Identificar las necesidades a través de:

  • Comentarios de los usuarios: Incidencias de GitHub (votos), encuestas de Discord, encuestas de la comunidad
  • Análisis de uso: Índices de adopción de funciones, métricas de puntos finales de API, registros de errores
  • Datos de rendimiento: Resultados de las pruebas de rendimiento, tiempos de inferencia, uso de memoria
  • Análisis de la competencia: Realizar un seguimiento de los lanzamientos de la competencia y de las tendencias del mercado
  • Prueba interna: Utiliza nuestras propias herramientas, identifica los puntos débiles

Comparar con:

  • Repercusión en los usuarios: ¿Cuántos usuarios se han visto afectados? ¿Nivel de gravedad (1-10)? ¿Repercusión en los ingresos?
  • Viabilidad técnica: ¿Esfuerzo de ingeniería (S/M/L/XL)? ¿Dependencias? ¿Riesgos?
  • Alineación estratégica: ¿Impulsa YOLO ? ¿Apoya a los sectores clave?
  • Disponibilidad de recursos: ¿Capacidad del equipo? ¿Prioridades contrapuestas? ¿Plazo?
  • Urgencia competitiva: ¿Serán los competidores los primeros en lanzar el producto? ¿Existe riesgo de dependencia?

Salida: Lista de tareas pendientes por orden de prioridad, con estimaciones de esfuerzo y puntuaciones de impacto para los usuarios

2. Diseño y especificaciones (días 1-3)

Para las principales funciones (más de dos semanas de trabajo de ingeniería):

  • Documento de diseño: Descripción del problema, solución propuesta, alternativas barajadas, indicadores de éxito
  • Especificaciones técnicas: Diseño de API, diagramas de arquitectura, modelos de datos, casos extremos
  • Criterios de éxito: Indicadores cuantitativos (velocidad, precisión, adopción) y objetivos de comentarios de los usuarios
  • Evaluación de riesgos: Riesgos técnicos, dependencias, plan de reversión
  • Análisis del equipo: Comentarios del departamento de ingeniería, del equipo de producto y de las principales partes interesadas

Para elementos pequeños (<1 week engineering time):

  • Incidencia de GitHub: Descripción clara del problema, enfoque propuesto, criterios de aceptación
  • Breve debate: Reunión de 15 minutos con los ingenieros pertinentes
  • Sí/No: Autorización del responsable para continuar

Salida: Especificaciones aprobadas con un alcance claro, indicadores de éxito y un calendario

3. Implementación (ejecución del sprint)

Planificación del sprint (cada dos semanas):

  • Objetivo de sprint: Un objetivo claro por sprint
  • Desglose de tareas: Split features into <1 day tasks
  • Planificación de la capacidad: Gestión de reuniones, revisiones de relaciones públicas, asistencia
  • Dependencias: Identificar los obstáculos y coordinarse con otros equipos

Ejecución diaria:

  • Reunión matutina (15 min): Avances de ayer, plan de hoy, obstáculos
  • Tiempo de concentración: 4-6 horas de trabajo concentrado, reducir al mínimo las reuniones
  • Reseñas de relaciones públicas: Revisar las solicitudes de incorporación de cambios de los compañeros de equipo en un plazo de 4 horas
  • Actualizaciones al final del día: Actualización sobre el progreso en Slack, trasladar tickets

Buenas prácticas de desarrollo:

  • Indicadores de funciones: Implementar en modo oscuro, activar gradualmente
  • Cobertura de pruebas: Escribe pruebas antes del lanzamiento (objetivo de cobertura >80 %)
  • Documentación: Actualizar la documentación en la misma solicitud de incorporación de cambios que el código
  • Rendimiento: Comparativa antes/después, sin regresiones
  • Seguridad: Realiza análisis de seguridad y soluciona los problemas críticos de inmediato

Sigue las instrucciones detalladas flujo de trabajo de desarrollo para el proceso de relaciones públicas y las normas de código.

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

Revisión del código (obligatorio para todas las solicitudes de incorporación de cambios):

  • <24 hour response time: Los ingenieros sénior dan prioridad a las revisiones
  • Controles de calidad: corrección del código, cobertura de pruebas, impacto en el rendimiento
  • Revisión de seguridad: Análisis automatizados + revisión manual del código sensible
  • Documentación: Comprobar que la documentación esté actualizada y que los ejemplos funcionen
  • Se requiere autorización: Se requiere la aprobación de al menos un ingeniero sénior antes de la fusión

Proceso de control de calidad:

  • Pruebas automatizadas: Pruebas unitarias, de integración y de extremo a extremo que se ejecutan con cada confirmación
  • Pruebas manuales: El ingeniero de control de calidad valida los flujos de usuario clave
  • Pruebas de rendimiento: Comparar con los valores de referencia y señalar los retrocesos
  • Multipropósito: Pruebas en CPU, GPU y dispositivos periféricos
  • Aceptación por parte de los usuarios: Prueba beta con usuarios seleccionados para las funciones principales

Ciclo de iteración:

  • Aborda los comentarios de inmediato; no acumules deuda técnica
  • Vuelve a realizar las pruebas tras los cambios y comprueba que las correcciones no afecten al funcionamiento de otras funciones
  • Actualiza los tickets con el progreso y mantén informadas a las partes interesadas

5. Lanzamiento

Lista de comprobación previa al lanzamiento:

  • Todas las pruebas han superado (unidades, integración, E2E)
  • Los indicadores de rendimiento cumplen los objetivos
  • Documentación completa y precisa
  • Registro de cambios actualizado con las modificaciones visibles para el usuario
  • Guía de migración (en caso de cambios que afecten a la compatibilidad)
  • Plan de reversión documentado
  • Supervisión y alertas configuradas

Proceso de lanzamiento:

  1. Fusionar con la rama principal: Las solicitudes de incorporación de cambios aprobadas se fusionan automáticamente
  2. Actualización de versión: Versiones semánticas (mayor.menor.corrección)
  3. Liberación de etiquetas: Crear una versión en GitHub con el registro de cambios
  4. PyPI: Publicación automática en Python Index
  5. Actualización de Docker: Compilar y publicar nuevas imágenes de contenedor
  6. Implementación de documentos: El sitio de documentación se actualiza automáticamente

Comunicado de lanzamiento:

  • Entrada de blog: Análisis técnico en profundidad de las principales funciones
  • Redes sociales: Anuncios en X, LinkedIn y Discord
  • Boletín informativo por correo electrónico: Notificar a más de 50 000 suscriptores
  • Vídeo de lanzamiento: Tutorial de YouTube sobre funciones complejas
  • Participación de la comunidad: Supervisar Discord/GitHub y responder a los comentarios

Seguimiento tras el lanzamiento (primeras 48 horas):

  • Supervisa las tasas de error, la latencia y los indicadores de adopción
  • Responder a los errores críticos en un plazo de 4 horas
  • Hotfix process for breaking issues (<24 hour turnaround)
  • Recopila las opiniones de los usuarios y da prioridad a las medidas que den resultados inmediatos

Medición del éxito (primeras dos semanas):

  • Índice de adopción: porcentaje de usuarios que actualizan
  • Métricas de uso: llamadas a la API, interacción con las funciones
  • Rendimiento: velocidad de inferencia, uso de memoria
  • Comentarios de los usuarios: reacciones de GitHub, encuestas de Discord
  • Informes de errores: proporción entre problemas críticos y problemas menores

Proceso de envío 📦

Control de versiones

Control de versiones semántico: MAJOR.MINOR.PATCH

  • PRINCIPAL: Cambios importantes
  • MENOR: Nuevas funciones, compatible con versiones anteriores
  • PARCHE: Corrección de errores

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

Calendario de lanzamientos

  • Versiones menores: Cada 2-4 semanas
  • Versiones de parches: Según sea necesario para correcciones críticas
  • Principales lanzamientos: Al introducir cambios que afectan a la compatibilidad

Lista de comprobación para el lanzamiento

  • Todas las pruebas de integración se han superado
  • Documentación actualizada
  • Actualización del registro de cambios
  • Se han actualizado los números de versión
  • Se ha creado una versión en GitHub
  • PyPI publicado en PyPI
  • Anuncio redactado

Proceso de corrección

En el caso de errores críticos:

  1. Crear hotfix/ rama a partir de la etiqueta de la última versión
  2. Solucionar el problema, añadir una prueba
  3. track
  4. Publicar inmediatamente la versión del parche
  5. Incorporar a la rama principal si es necesario

Priorización de funciones 📊

Alta prioridad

  • Errores graves que afectan a los usuarios
  • Mejoras en el rendimiento
  • Cuestiones de seguridad
  • Funcionalidades muy solicitadas (más de 10 peticiones de la comunidad)

Prioridad media

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

Baja prioridad

  • Funciones que sería bueno tener
  • Pequeñas mejoras
  • Gestión de casos extremos

Sin prioridad

  • Funcionalidades para un solo usuario
  • Implementaciones excesivamente complejas
  • Ampliaciones que requieren mucho mantenimiento
  • Fuera del ámbito de la misión principal

Métricas y resultados 📈

Indicadores clave

  • Estrellas de GitHub: Interés comunitario
  • PyPI: Tasa de adopción
  • Tiempo de respuesta a las incidencias: Calidad de la asistencia
  • Hora de la fusión de relaciones públicas: Velocidad de desarrollo
  • Métricas de rendimiento: Mejoras en la velocidad y la precisión

Criterios de éxito de la función

Definir antes de compilar:

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

Comunicación 💬

Interno

  • Incidencias de GitHub: Propuestas de funciones y errores
  • Slack: Breves debates y novedades
  • Reuniones de equipo: Reuniones semanales para coordinar las prioridades

Externo

  • Debates de GitHub: Comentarios de la comunidad
  • Discord: Asistencia al usuario y participación
  • Entradas del blog: Anuncios de novedades importantes
  • Documentación: Notas de la versión y guías

Hoja de ruta del producto 🗺️

Enfoque actual

Próximas zonas

Visión a largo plazo

  • La mejor detección de objetos de código abierto del mundo
  • Implementación fluida en todas las plataformas
  • Conjunto completo de herramientas de visión artificial
  • Innovación impulsada por la comunidad

Buenas prácticas ✅

Desarrollo de funciones

  • Empieza poco a poco: Primero lo esencial, luego ampliar
  • Pruebas con usuarios: Pide opiniones desde el principio
  • El rendimiento es lo primero: Optimiza desde el principio
  • Documenta bien: Redactar la documentación mientras se desarrolla

Gestión de versiones

  • Compruébalo a fondo: CI + pruebas manuales
  • Borrar el registro de cambios: ¿Qué ha cambiado? ¿Por qué es importante?
  • Actualizaciones sin problemas: Compatibilidad con versiones anteriores, siempre que sea posible
  • Soluciones rápidas: No dejes que los errores se acumulen

Participación ciudadana

  • Adaptativo: Responder a las incidencias en un plazo de 24 horas
  • Transparente: Compartir la hoja de ruta y las decisiones
  • Agradecido: Agradecimiento a los colaboradores
  • Inclusivo: Abierto a todos los niveles

Recursos 📚