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 de producto mínimo viable primero
Centrado en el usuario: Crea las funciones que los usuarios más solicitan, valida con datos
Priorizar el código abierto: Desarrollo público, los comentarios de la comunidad impulsan la hoja de ruta
El rendimiento es una característica: Tiempos de inferencia inferiores a milisegundos, mínima huella de memoria
Diseño API-First: API sencillas e intuitivas que encantan a los desarrolladores

Valores de desarrollo

Predisposición a la acción: Prototipa en días, 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 una solución al 80% rápidamente, itera hasta el 100%
Despliegue continuo: La rama principal siempre está lista para producción
Transparencia radical: Hoja de ruta pública, métricas abiertas, aportes de la comunidad

Ciclo de Vida del Desarrollo de Funciones 🔄

1. Descubrimiento y planificación (Semana 1)

Identificar las necesidades a través de:

Comentarios de los usuarios: Problemas en GitHub (votos), encuestas de Discord, encuestas de la comunidad
Análisis de uso: Tasas de adopción de funciones, métricas de puntos finales de la API, registros de errores
Datos de rendimiento: Resultados de referencia, tiempos de inferencia, uso de memoria
Análisis de la competencia: Seguimiento de los lanzamientos de la competencia, tendencias del mercado
Dogfooding interno: Usar nuestras propias herramientas, identificar los puntos débiles

Evaluar contra:

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 YOLO11? ¿Apoya a los sectores verticales clave?
Disponibilidad de recursos: ¿Capacidad del equipo? ¿Prioridades contrapuestas? ¿Cronograma?
Urgencia competitiva: ¿Los competidores enviarán primero? ¿Riesgo de bloqueo?

Salida: Lista de características priorizadas con estimaciones de esfuerzo y puntajes de impacto en el usuario

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

Para características principales (>2 semanas de tiempo de ingeniería):

Documento de diseño: Declaración del problema, solución propuesta, alternativas consideradas, métricas de éxito
Especificación técnica: Diseño de la 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 del usuario
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

For small features (<1 week engineering time):

Problema en GitHub: Descripción clara del problema, enfoque propuesto, criterios de aceptación
Discusión rápida: Sincronización de 15 minutos con los ingenieros relevantes
Aprobación/No aprobación: Aprobación del gerente para proceder

Resultado: Especificación aprobada con alcance claro, métricas de éxito y cronograma

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

Planificación del sprint (cada 2 semanas):

Objetivo del sprint: Un objetivo claro por sprint
Task breakdown: Split features into <1 day tasks
Planificación de la capacidad: Tener en cuenta las reuniones, las revisiones de PR y el soporte
Dependencias: Identificar los bloqueadores, coordinar con otros equipos

Ejecución diaria:

Standup matutino (15 min): Progreso de ayer, plan de hoy, bloqueadores
Tiempo de concentración: 4-6 horas de trabajo profundo, minimizar las reuniones
Revisiones de PR: Revisar los PR de los compañeros de equipo en un plazo de 4 horas
Actualizaciones de fin de día: Actualización del progreso en Slack, mover tickets

Mejores prácticas de desarrollo:

Feature flags: Desplegar en modo oscuro, habilitar gradualmente
Cobertura de pruebas: Escribir pruebas antes de la entrega (>80% de cobertura objetivo)
Documentación: Actualizar la documentación en el mismo PR que el código
Rendimiento: Realizar pruebas de referencia antes/después, sin regresiones
Seguridad: Ejecutar análisis de seguridad, solucionar los problemas críticos inmediatamente

Siga 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 (Paralelo a la implementación)

Revisión de código (obligatoria para todos los PR):

<24 hour response time: Senior engineers prioritize reviews
Comprobaciones de calidad: Corrección del código, cobertura de pruebas, impacto en el rendimiento
Revisión de seguridad: Análisis automatizados + revisión manual para código sensible
Documentación: Verificar que la documentación esté actualizada y que los ejemplos funcionen
Aprobación requerida: 1+ aprobación de ingeniero senior antes de la fusión

Proceso de control de calidad (QA):

Pruebas automatizadas: Pruebas unitarias, de integración y E2E que se ejecutan en cada commit
Pruebas manuales: El ingeniero de control de calidad (QA) valida los flujos de usuario clave
Pruebas de rendimiento: Comparar con la línea base, señalar regresiones
Multiplataforma: Probar en CPU, GPU, dispositivos edge
Aceptación del usuario: Prueba beta con usuarios selectos para funciones principales

Ciclo de iteración:

Abordar los comentarios de inmediato, no acumular deuda técnica
Volver a probar después de los cambios, verificar que las correcciones no rompan otras funciones
Actualizar los tickets con el progreso, mantener informados a los interesados

5. Lanzamiento y puesta en marcha

Lista de verificación previa al lanzamiento:

[ ] Todas las pruebas pasan (unitarias, de integración, E2E)
[ ] Los puntos de referencia de rendimiento cumplen los objetivos
[ ] Documentación completa y precisa
[ ] Registro de cambios actualizado con los 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:

Fusionar con main: Las PR aprobadas se fusionan automáticamente
Aumento de versión: Versionado semántico (major.minor.patch)
Etiquetar lanzamiento: Crear lanzamiento de GitHub con registro de cambios
Publicación en PyPI: Despliegue automatizado al índice de paquetes de python
Actualización de Docker: Construir y enviar nuevas imágenes de contenedor
Despliegue de documentos: El sitio de documentación se actualiza automáticamente

Comunicación de lanzamiento:

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

Supervisión posterior al lanzamiento (primeras 48 horas):

Vigilar las tasas de error, la latencia y las métricas de adopción
Responder a los errores críticos en un plazo de 4 horas
Hotfix process for breaking issues (<24 hour turnaround)
Recopilar comentarios de los usuarios, priorizar 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, participación en las funciones
Rendimiento: Velocidad de inferencia, uso de memoria
Comentarios de los usuarios: Reacciones en GitHub, encuestas en Discord
Informes de errores: Relación entre problemas críticos y menores

Proceso de Lanzamiento 📦

Control de Versiones

Versionado semántico: MAJOR.MINOR.PATCH

MAJOR: Cambios importantes que rompen la compatibilidad
MINOR: Nuevas funcionalidades, compatibles con versiones anteriores
PATCH: Corrección de errores

Ejemplo: 11.0.0 → 11.1.0 (nueva funcionalidad) → 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 importantes que rompen la compatibilidad

Lista de Verificación de Lanzamiento

[ ] Todas las pruebas de CI pasan
[ ] Documentación actualizada
[ ] Registro de cambios actualizado
[ ] Números de versión incrementados
[ ] Lanzamiento de GitHub creado
[ ] Paquete PyPI publicado
[ ] Anuncio preparado

Proceso de Hotfix

Para errores críticos:

Crear hotfix/ rama desde la última etiqueta de lanzamiento
Corregir el problema, añadir prueba
Revisión rápida
Lanzar la versión del parche inmediatamente
Si es necesario, hacer un backport a la rama principal

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 en la calidad de vida
Nuevos formatos de exportación
Soporte extendido de plataforma
Mejoras en la documentación

Prioridad Baja

Funciones interesantes
Optimizaciones menores
Manejo de casos límite

Sin Prioridad

Funciones para un solo usuario
Implementaciones demasiado complejas
Adiciones con alta 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 los problemas: Calidad del soporte
Tiempo de fusión de PR: Velocidad de desarrollo
Benchmarks de rendimiento: Mejoras en velocidad/precisión

Criterios de Éxito de las Funciones

Definir antes de construir:

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

Comunicación 💬

Interna

Problemas de GitHub: Propuestas de funciones y errores
Slack: Discusiones rápidas y actualizaciones
Reuniones de equipo: Sincronizaciones semanales sobre prioridades

Externa

Discusiones en GitHub: Comentarios de la comunidad
Discord: Soporte y participación del usuario
Publicaciones del blog: Anuncios de funciones principales
Documentación: Notas de la versión y guías

Hoja de ruta del producto 🗺️

Enfoque Actual

Áreas Próximas

Visión a largo plazo

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

Mejores prácticas ✅

Desarrollo de funciones

Empieza poco a poco: Primero el MVP, luego expande
Pruebas de usuario: Obtén comentarios pronto
Rendimiento primero: Optimiza desde el principio
Documenta bien: Escribe la documentación mientras construyes

Gestión de lanzamientos

Prueba a fondo: CI + pruebas manuales
Registro de cambios claro: Qué cambió, por qué es importante
Actualizaciones fluidas: Compatibilidad con versiones anteriores cuando sea posible
Soluciones rápidas: No dejes que los errores persistan

Participación de la comunidad

Responsivo: Responde a los problemas en 24 horas
Transparente: Compartir la hoja de ruta y las decisiones
Agradecido: Agradecer a los colaboradores
Inclusivo: Dar la bienvenida a todos los niveles de habilidad

Recursos 📚

Flujo de trabajo de desarrollo - Proceso y estándares de las PR
CI/Testing - Pruebas y controles de calidad
Documentación - Redacción y mantenimiento de la documentación
Problemas de GitHub - Solicitudes de funciones y errores

📅 Creado hace 1 mes ✏️ Actualizado hace 9 días