Flujo de trabajo de desarrollo de productos 🚀

Esta guía abarca la planificación de productos, los ciclos de desarrollo y los procesos de publicación para Ultralytics de Ultralytics.

Filosofía del producto 🎯

Principios básicos

Enviar rápido, aprender más rápido: ciclos de iteración de 2 semanas, enfoque MVP primero
Centrado en el usuario: crear las funciones más solicitadas por los usuarios y validarlas con datos.
El código abierto es lo primero: El desarrollo público y los comentarios de la comunidad impulsan la hoja de ruta
El rendimiento es una característica: Tiempos de inferencia inferiores a milisegundos, consumo mínimo de memoria
Diseño API-First: API sencillas e intuitivas que encantan a los desarrolladores

Valores de desarrollo

Pasar a la acción: Prototipos en días, envíos en semanas, no en meses
Decisiones basadas en datos: Las estrellas de GitHub, las descargas PyPI y las encuestas de Discord orientan las prioridades.
Producto mínimo viable: Lanzar rápidamente una solución al 80%, iterar hasta el 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 🔄

1. Descubrimiento y planificación (Semana 1)

Identificar las necesidades a través de:

Comentarios de los usuarios: Cuestiones de GitHub (votos), sondeos de Discord, encuestas a 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 pruebas comparativas, tiempos de inferencia, uso de memoria
Análisis de la competencia: Seguimiento de las publicaciones de la competencia y las tendencias del mercado
Dogfooding interno: Utilizar nuestras propias herramientas, identificar los puntos débiles

Evalúe en función de:

Impacto en los usuarios: ¿A cuántos usuarios afecta? ¿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 YOLO11 ? ¿Apoya a los sectores verticales clave?
Disponibilidad de recursos: ¿Capacidad del equipo? ¿Prioridades contrapuestas? ¿Calendario?
Urgencia competitiva: ¿Serán los competidores los primeros en lanzar? ¿Riesgo de bloqueo?

Resultado: Lista de características priorizadas con estimaciones de esfuerzo y puntuaciones del impacto en el usuario.

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

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

Documento de diseño: Planteamiento del problema, solución propuesta, alternativas consideradas, métricas de éxito
Especificaciones técnicas: 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 desmantelamiento
Revisión en 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
Debate rápido: sincronización de 15 minutos con los ingenieros pertinentes
Go/No-go: Aprobación del gestor para seguir adelante

Resultado: Especificación aprobada con un ámbito de aplicación, parámetros de éxito y calendario claros.

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

Planificación de sprints (cada 2 semanas):

Objetivo del sprint: un objetivo claro por sprint
Task breakdown: Split features into <1 day tasks
Planificación de capacidades: Contabilización de reuniones, revisiones de relaciones públicas, apoyo
Dependencias: Identificar bloqueos, coordinarse con otros equipos

Ejecución diaria:

Sesión matinal (15 minutos): Progreso de ayer, plan de hoy, bloqueadores
Tiempo de concentración: 4-6 horas de trabajo en profundidad, minimizar las reuniones
Revisiones de RP: Revisa los RP de tus compañeros de equipo en un plazo de 4 horas
Actualizaciones al final del día: Slack progress update, move tickets

Mejores prácticas de desarrollo:

Banderas de características: Despliegue oscuro, activación gradual
Cobertura de las pruebas: Escribir pruebas antes del envío (objetivo de cobertura >80%).
Documentación: Actualizar la documentación en el mismo PR que el código
Rendimiento: Comparación antes/después, sin regresiones
Seguridad: Ejecute análisis de seguridad y solucione inmediatamente los problemas críticos

Siga un flujo de trabajo de desarrollo detallado para el proceso de relaciones públicas y las normas de código.

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

Revisión del código (obligatoria para todos los RP):

<24 hour response time: Senior engineers prioritize reviews
Comprobaciones de calidad: Corrección del código, cobertura de las pruebas, impacto en el rendimiento
Revisión de seguridad: Escaneos automatizados + revisión manual de código sensible
Documentación: Verificar docs actualizados, los ejemplos funcionan
Aprobación necesaria: Aprobación de un ingeniero superior antes de la fusión

Proceso de control de calidad:

Pruebas automatizadas: Pruebas unitarias, de integración, E2E ejecutadas en cada commit.
Pruebas manuales: El ingeniero de control de calidad valida los flujos de usuarios clave
Pruebas de rendimiento: Comparación con la línea de base, detección de regresiones
Multiplataforma: Pruebas en CPU, GPU y dispositivos edge
Aceptación de los usuarios: Pruebas beta con usuarios seleccionados para las funciones principales

Ciclo de iteración:

Atienda inmediatamente a los comentarios, no acumule deuda técnica
Vuelva a probar los cambios y compruebe que las correcciones no afectan a otras funciones.
Actualizar los tickets con los progresos, mantener informadas a las partes interesadas

5. Lanzamiento

Lista de control previa al lanzamiento:

Aprobación de todas las pruebas (unitarias, de integración, E2E)
Los criterios de referencia cumplen los objetivos
Documentación completa y precisa
Registro de cambios actualizado con los cambios de cara al usuario
Guía de migración (si se producen cambios de última hora)
Plan de desmantelamiento documentado
Monitorización y alertas configuradas

Proceso de liberación:

Fusionar a principal: Los PR aprobados se fusionan automáticamente
Version bump: Versionado semántico (mayor.menor.parche)
Etiqueta release: Crear publicación GitHub con registro de cambios
PublicaciónPyPI : Despliegue automatizado en Python Package Index
Actualización de Docker: creación y distribución de nuevas imágenes de contenedores
Despliegue de la documentación: El sitio de documentación se actualiza automáticamente

Comunicación de lanzamiento:

Entrada en el blog: Profundización técnica en las principales características
Redes sociales: Anuncios en X, LinkedIn y Discord
Boletín electrónico: Notificar a más de 50.000 suscriptores
Vídeo de lanzamiento: Tutorial de YouTube sobre funciones complejas
Compromiso con la comunidad: Supervisar Discord/GitHub, responder a los comentarios

Seguimiento posterior al lanzamiento (primeras 48 horas):

Observar las tasas de error, la latencia y las métricas de adopción
Respuesta a errores críticos en un plazo de 4 horas
Hotfix process for breaking issues (<24 hour turnaround)
Recoger las opiniones de los usuarios, priorizar los logros rápidos

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

Tasa de adopción: % de usuarios que se actualizan
Métricas de uso: Llamadas a la API, participación en las funciones
Rendimiento: Velocidad de inferencia, uso de memoria
Reacciones de los usuarios: Reacciones en GitHub, encuestas en Discord
Informes de errores: Proporción de problemas críticos frente a problemas menores

Proceso de liberación 📦

Versionado

Versionado semántico: MAJOR.MINOR.PATCH

MAYOR: Cambios de última hora
MENOR: Nuevas funciones, compatible con versiones anteriores
PARCHE: Corrección de errores

Ejemplo: 11.0.0 → 11.1.0 (nueva característica) → 11.1.1 (corrección de errores)

Calendario de publicación

Lanzamientos menores: Cada 2-4 semanas
Publicación de parches: Según sea necesario para correcciones críticas
Lanzamientos importantes: Cuando se introducen cambios de última hora

Lista de control de la liberación

Proceso Hotfix

Para errores críticos:

Cree hotfix/ rama de la última etiqueta de versión
Solucionar problema, añadir prueba
Revisión track
Publique inmediatamente la versión del parche
Si es necesario, retrocede a la principal

Priorización de funciones 📊

Alta prioridad

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

Prioridad media

Mejoras en la calidad de vida
Nuevos formatos de exportación
Mayor compatibilidad con plataformas
Mejoras en la documentación

Prioridad baja

Funciones útiles
Optimizaciones menores
Tratamiento de casos extremos

Sin prioridades

Funciones para un solo usuario
Aplicaciones demasiado complejas
Adiciones que requieren mucho mantenimiento
Fuera del alcance de la misión principal

Métricas y éxito 📈

Métricas clave

Estrellas de GitHub: Interés de la comunidad
DescargasPyPI : Tasa de adopción
Tiempo de respuesta: calidad de la asistencia
PR Merge Time: Velocidad de desarrollo
Indicadores de rendimiento: Mejoras de velocidad y precisión

Criterios de éxito

Definir antes de construir:

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

Comunicación 💬

Interno

Cuestiones de GitHub: Propuestas de funciones y errores
Slack: Debates rápidos y actualizaciones
Reuniones de equipo: Sincronizaciones semanales sobre prioridades

Exterior

Debates en GitHub: Comentarios de la comunidad
Discordia: Apoyo y participación de los usuarios
Entradas en el blog: Principales novedades
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
Implantación sin fisuras en todas las plataformas
Completo conjunto de herramientas de visión por ordenador
Innovación impulsada por la comunidad

Buenas prácticas ✅

Desarrollo de funciones

Empezar poco a poco: MVP primero, expansión después
Pruebas de usuario: Obtenga opiniones desde el principio
El rendimiento ante todo: Optimizar desde el principio
Documente bien: Escribir documentos mientras se construye

Gestión de la publicación

Pruebas a fondo: CI + pruebas manuales
Lista de cambios: Qué ha cambiado y por qué es importante
Actualizaciones sin problemas: Compatibilidad con versiones anteriores siempre que sea posible
Soluciones rápidas: No dejes que los errores persistan

Participación comunitaria

Capacidad de respuesta: Respuesta a los problemas en 24 horas
Transparencia: compartir la hoja de ruta y las decisiones
Agradecimiento: Agradecer a los contribuyentes
Inclusivo: Todos los niveles son bienvenidos

Recursos 📚

Flujo de trabajo de desarrollo: proceso y normas de relaciones públicas
CI/Testing - Pruebas y controles de calidad
Documentación - Redacción y mantenimiento de documentos
GitHub Issues - Peticiones de funciones y errores

Creado hace 6 días ✏️ Actualizado hace 6 días