Glosario de equipos dedicados de desarrollo: 35 términos que debes conocer
El modelo de equipo dedicado externo tiene su propio vocabulario: términos de metodología ágil, modelos de colaboración, métricas de rendimiento y conceptos contractuales que todo cliente debe dominar antes de trabajar con un partner de desarrollo. Este glosario reúne los 35 términos más importantes, explicados en lenguaje directo con ejemplos prácticos.
Si estás evaluando contratar un equipo dedicado o comparando el outsourcing frente a equipo interno, este glosario es tu punto de partida.
A — Términos de metodología ágil
Marco de trabajo para desarrollo de software basado en iteraciones cortas, colaboración continua con el cliente y adaptación constante a cambios de requisitos. Se opone al modelo en cascada (waterfall), donde todo se planifica al inicio y el cliente ve el resultado al final. En Agile, el cliente ve entregas funcionales cada 1-2 semanas.
En la práctica: En 10Code trabajamos con sprints de 2 semanas. Cada sprint termina con una demo del software funcionando. El cliente puede cambiar prioridades entre sprints.
Período de tiempo fijo (normalmente 1-2 semanas) durante el cual el equipo desarrolla un conjunto de funcionalidades comprometidas en la planificación del sprint. Al final del sprint, el software debe estar en estado deployable: funcionando y probado, no a medias.
En la práctica: Sprint de 2 semanas → planificación del sprint (lunes) → desarrollo (lunes a viernes) → revisión y demo con el cliente (segundo viernes) → retrospectiva interna del equipo.
Framework ágil específico que organiza el desarrollo en sprints con roles definidos: Scrum Master (facilita el proceso y elimina impedimentos), Product Owner (representa los intereses del cliente y prioriza el backlog) y Development Team (desarrolla el software).
En la práctica: El Product Owner suele ser un rol del cliente (o un perfil de negocio en el equipo del partner). El Scrum Master suele ser del equipo de desarrollo.
Método de gestión visual del trabajo que organiza las tareas en columnas (Por hacer → En curso → En revisión → Hecho) y limita el trabajo en curso (WIP limit) para evitar cuellos de botella. Más flexible que Scrum al no tener iteraciones fijas.
En la práctica: Kanban es ideal para equipos de mantenimiento y soporte, donde las tareas llegan continuamente sin un roadmap de sprints definido.
B — Backlog y planificación
Lista priorizada de todas las funcionalidades, mejoras, correcciones y deuda técnica del producto. El Product Owner la mantiene y prioriza continuamente. El backlog nunca está "terminado": siempre hay más elementos que el equipo puede desarrollar.
En la práctica: Un backlog bien gestionado tiene los elementos del top 2-3 sprints completamente definidos y estimados. Los elementos más alejados pueden ser más vagos.
El subconjunto del product backlog que el equipo se compromete a completar durante el sprint actual. Se define en la Sprint Planning y el equipo no acepta nuevas tareas durante el sprint (salvo emergencias acordadas).
En la práctica: La clave es que el equipo selecciona cuánto puede hacer (basado en su velocity histórica), no el cliente. El cliente prioriza qué es más importante, el equipo decide cuánto cabe en el sprint.
Descripción de una funcionalidad desde la perspectiva del usuario: "Como [tipo de usuario], quiero [acción], para [beneficio]". Las historias de usuario reemplazan los documentos de requisitos técnicos extensos y son más fáciles de priorizar por valor de negocio.
Ejemplo: "Como comprador, quiero guardar mi dirección de envío favorita, para no tener que introducirla en cada pedido."
Agrupación de historias de usuario relacionadas que representan una funcionalidad mayor o iniciativa de producto. Demasiado grande para caber en un sprint; se descompone en historias más pequeñas.
Ejemplo: "Sistema de pagos" es una épica que incluye historias de: añadir tarjeta, procesar pago, generar factura, gestionar devoluciones, etc.
C — Modelos de colaboración y contratación
Modelo de colaboración en el que un grupo de desarrolladores externos trabaja exclusivamente para un cliente. A diferencia del proyecto cerrado (donde el equipo puede trabajar para varios clientes a la vez), el equipo dedicado conoce profundamente el producto del cliente y funciona como una extensión natural de su equipo.
Ideal para: Productos digitales en evolución continua, startups en crecimiento, empresas con roadmap de desarrollo permanente.
Desarrolladores externos que se integran en el equipo interno del cliente, trabajando bajo la gestión directa de este pero contratados y gestionados administrativamente por el partner externo. El cliente gestiona las prioridades y el día a día; el partner gestiona la nómina, la seguridad social y los aspectos laborales.
Ideal para: Empresas con equipo técnico propio que necesitan refuerzo temporal o habilidades específicas sin asumir contrataciones permanentes.
Modelo de contratación en el que el cliente paga por el tiempo real empleado (horas o días de equipo) y los materiales (infraestructura, licencias). No hay un precio total cerrado. El cliente tiene flexibilidad total para cambiar prioridades. Es el modelo habitual en equipos dedicados y Agile.
Vs precio cerrado: T&M es más flexible y habitual cuando los requisitos evolucionan. Precio cerrado es adecuado cuando el alcance está perfectamente definido y no variará.
El proveedor se compromete a entregar un alcance definido a un precio total fijo. Cualquier cambio en el alcance puede generar extras. Requiere una definición de requisitos muy detallada antes de empezar. El riesgo del alcance lo asume el proveedor.
Cuándo usarlo: Proyectos con alcance muy bien definido y estable (migraciones de datos, integraciones concretas, landing pages). No recomendable para productos nuevos donde los requisitos evolucionarán.
Outsourcing de desarrollo con un equipo ubicado en un país cercano geográfica y culturalmente, con huso horario compatible (máximo 2-3 horas de diferencia). En el contexto europeo: equipo español trabajando para cliente alemán, o equipo rumano para cliente francés.
Ventajas vs offshore: Comunicación más fluida, reuniones en horario laboral compartido, menor riesgo cultural, mayor facilidad para viajes de trabajo. El coste es mayor que offshore pero inferior al equipo local en países de alto coste.
Outsourcing con un equipo ubicado en un país lejano (India, Ucrania, Polonia, Filipinas) con costes laborales significativamente menores. Las tarifas offshore son un 40-60% más baratas que el equipo local, pero el coste real de comunicación, retrabajo y gestión reduce frecuentemente el ahorro aparente.
Cuándo tiene sentido: Proyectos con especificaciones muy detalladas y estables, poca necesidad de comunicación frecuente, y con un product manager interno que gestione la relación.
D — Métricas y rendimiento del equipo
Promedio de story points que el equipo completa por sprint. Es la métrica principal para predecir cuánto trabajo puede entregar el equipo en el futuro. Un equipo nuevo tiene velocity variable; estabiliza a las 3-5 sprints.
Cómo usarla: Si el equipo tiene velocity de 40 story points/sprint y el backlog tiene 200 story points, el roadmap necesita aproximadamente 5 sprints (10 semanas con sprints de 2 semanas).
Unidad relativa de medida del esfuerzo para completar una historia de usuario. No representan horas concretas; representan complejidad relativa. Se usan valores de la secuencia de Fibonacci (1, 2, 3, 5, 8, 13) o similares. La estimación la hace el equipo en Planning Poker.
Por qué no horas: Las horas varía por desarrollador y día. Los story points capturan complejidad relativa de forma más estable y permiten estimaciones de equipo más precisas.
Gráfico que muestra el trabajo restante (story points o tareas) a lo largo del sprint. Una línea ideal desciende linealmente de 100% a 0% al final del sprint. Si la línea real está por encima de la ideal, el equipo va con retraso.
Cuándo alarmar: Si a mitad del sprint el burndown muestra más del 60% del trabajo pendiente, hay un problema que debe abordarse en el standup inmediatamente.
Trabajo adicional que se acumula cuando el equipo elige soluciones rápidas pero incompletas para cumplir plazos. Como la deuda financiera, genera "intereses": cada nueva funcionalidad sobre código con deuda técnica es más lenta y cara de desarrollar.
Gestión sana: Dedicar entre el 15% y el 20% de cada sprint a reducir deuda técnica. Equipos que no hacen esto ven cómo su velocity cae progresivamente.
Tiempo total desde que se crea una tarea (historia de usuario, bug) hasta que está en producción accesible para los usuarios. Incluye tiempo de espera en backlog, desarrollo, code review, QA y despliegue. Métrica clave en equipos de alto rendimiento.
Lista de criterios acordados por el equipo que debe cumplir una historia de usuario para considerarse "hecha". Típicamente incluye: desarrollada, tests unitarios y de integración pasando, code review aprobado, QA funcional completado, desplegada en entorno de staging, documentación actualizada.
Por qué es crítica: Sin DoD, "hecho" significa cosas diferentes para cada persona del equipo. La DoD es el contrato de calidad interno del equipo.
E — Roles del equipo de desarrollo
Responsable de maximizar el valor del producto. Gestiona y prioriza el product backlog, define los criterios de aceptación de las historias de usuario, toma decisiones de negocio durante el desarrollo y acepta o rechaza el trabajo completado. Suele ser un perfil del cliente.
Desarrollador senior que lidera las decisiones técnicas del equipo: elige la arquitectura, define los estándares de código, revisa pull requests, mentoriza a desarrolladores junior y es el punto de escalada para problemas técnicos complejos. No es gerente, no gestiona personas.
Facilitador del proceso Scrum. No es el jefe del equipo: elimina impedimentos que frenan al equipo, protege al equipo de interrupciones externas, facilita las ceremonias Scrum y ayuda a mejorar el proceso. Un buen Scrum Master es casi invisible cuando el equipo funciona bien.
Ingeniero de calidad (Quality Assurance) responsable de asegurar que el software desarrollado cumple los requisitos y no introduce regresiones. Diseña y ejecuta pruebas funcionales, de rendimiento y de regresión. Automatiza tests para reducir el tiempo de validación en cada sprint.
Especialista en infraestructura cloud, CI/CD (integración y despliegue continuos), automatización de pipelines, monitorización y seguridad de sistemas. Asegura que el código desarrollado llega a producción de forma rápida, confiable y automatizada.
Desarrollador que trabaja tanto en el frontend (interfaz de usuario: React, Vue, Angular) como en el backend (servidor, base de datos, APIs: Node.js, Laravel, Python). Los equipos dedicados pequeños (2-3 personas) suelen tener full-stacks que aportan más flexibilidad.
F — Procesos y ceremonias del equipo
Reunión diaria de exactamente 15 minutos donde cada miembro responde: ¿qué hice ayer? ¿qué haré hoy? ¿tengo algún impedimento? No es una reunión de status para el jefe; es una sincronización del equipo para detectar bloqueos lo antes posible.
Reunión al final del sprint donde el equipo demuestra al cliente el software funcionando y recoge feedback. No es una presentación de PowerPoints; es una demo real del software. El cliente acepta o rechaza el trabajo e identifica ajustes para el próximo sprint.
Reunión interna del equipo (sin el cliente) al final del sprint para reflexionar: ¿qué fue bien? ¿qué fue mal? ¿qué mejoraremos en el próximo sprint? Es la herramienta de mejora continua del equipo. Un equipo que no hace retrospectivas repite los mismos errores sprint tras sprint.
Sesión periódica (normalmente 1-2 veces por sprint) en la que el equipo y el Product Owner detallan, dividen y estiman las historias del backlog para que estén listas para ser planificadas en futuros sprints. El resultado es un backlog siempre "listo para planificar".
G — Arquitectura y calidad de código
Proceso en el que al menos otro desarrollador revisa el código antes de integrarlo en la rama principal. Detecta bugs, problemas de seguridad, código difícil de mantener y desviaciones de los estándares del equipo. En equipos de calidad, ningún código va a producción sin code review.
CI (Continuous Integration): cada cambio de código se integra y valida automáticamente (tests unitarios, linting, análisis de seguridad). CD (Continuous Delivery/Deployment): el código validado se despliega automáticamente en entornos de staging y/o producción. Permite despliegues múltiples al día con riesgo mínimo.
Solicitud de un desarrollador para integrar su rama de código en la rama principal del repositorio. Desencadena el proceso de code review y la ejecución automática de tests en CI. Solo se aprueba si pasa todos los controles de calidad definidos por el equipo.
Porcentaje del código fuente cubierto por tests automatizados (unitarios, integración, end-to-end). Un nivel de cobertura del 70-80% es el mínimo recomendable para proyectos en producción. Sin tests, cada cambio puede romper funcionalidades existentes sin que nadie lo detecte hasta que el usuario lo reporta.
H — Términos contractuales y de relación
Acuerdo de nivel de servicio que define los tiempos garantizados de respuesta y resolución ante incidencias. Ejemplo: "Incidencias críticas (sistema caído): tiempo de respuesta máximo 1 hora, resolución en 4 horas." Un contrato de equipo dedicado debe incluir SLAs claros para soporte post-lanzamiento.
Proceso de incorporación del equipo externo al contexto del producto del cliente: arquitectura técnica, lógica de negocio, herramientas y procesos. Un onboarding bien planificado dura 1-2 semanas. Uno mal planificado genera meses de malentendidos y trabajo mal orientado.
Transferencia de conocimiento técnico y de negocio, especialmente al cambiar de proveedor o escalar el equipo. Incluye: documentación de arquitectura, decisiones técnicas documentadas (ADRs), comentarios en el código, sesiones de pair programming y grabación de demos. Sin KT, el conocimiento queda atrapado en personas específicas.
Cláusula contractual esencial que establece que el código fuente desarrollado pertenece al cliente desde el primer día, no al proveedor. Debe especificar: propiedad del repositorio Git, documentación técnica, credenciales de sistemas, y derechos de propiedad intelectual sobre el código. Sin esto, el cliente queda cautivo del proveedor.
Recursos relacionados
Descubre cómo funciona nuestro modelo de equipos dedicados en la práctica: cómo los formamos, cómo los gestionamos y qué resultados generan para nuestros clientes.
¿No sabes si es mejor un equipo dedicado o contratar internamente? Analizamos costes, ventajas y cuándo tiene sentido cada opción con datos reales del mercado español.
Para términos generales de desarrollo de software más allá del modelo de equipos dedicados, consulta nuestro glosario completo de términos de software.
Ahora que conoces la terminología, solicita una consultoría gratuita para evaluar si el modelo de equipo dedicado encaja con tu proyecto.