Glosario: 50 términos de tu primer trabajo dev

Llegas a tu primer trabajo como developer y la primera reunión está llena de términos que nadie te explicó en el bootcamp o la universidad. “Vamos a hacer una retro al final del sprint”, “el MR tiene conflictos”, “el CI está en rojo”, “tenemos que refinar el backlog para la planning”. Asientes, sonríes, y buscas en Google en cuanto sales de la reunión.

Este glosario va de eso. 50 términos que vas a escuchar en tu primer trabajo y que las explicaciones de internet hacen sonar más complicados de lo que son. Aquí están como te los explicaría un amigo: definición clara + ejemplo real + por qué importa.

Organizados por categoría para que puedas saltar a lo que necesites. Marca esta página, vas a volver.

Metodologías ágiles#

1. Sprint#

Un periodo de tiempo fijo (normalmente 2 semanas) durante el cual el equipo trabaja en un conjunto definido de tareas. Al final del sprint, se entrega algo funcionando.

Ejemplo: “En este sprint vamos a terminar el módulo de pagos. Empieza el lunes, acaba el viernes 14”.

Por qué importa: tu trabajo se organiza en sprints. Lo que se mete en un sprint debe acabarse en ese sprint, no en el siguiente. Sí o sí.

2. Stand-up / Daily#

Reunión diaria de 15 minutos máximo donde cada miembro del equipo dice: qué hizo ayer, qué hará hoy, si tiene bloqueos.

Ejemplo: “Ayer terminé el endpoint de login, hoy empiezo el de signup, sin bloqueos”.

Por qué importa: es la reunión más frecuente. Hazla breve: nadie quiere oír un monólogo a primera hora.

3. Refinamiento / Grooming#

Reunión donde el equipo revisa el backlog (lista de tareas pendientes), discute requisitos y estima esfuerzo.

Ejemplo: “El viernes hacemos refinamiento de las features del próximo sprint”.

Por qué importa: si no entiendes una tarea, este es el momento de preguntar. Si dices “sí, entendido” sin entender, te explotará en la cara durante el sprint.

4. Planning / Planificación#

Reunión al inicio del sprint donde se decide qué tareas se meten en el sprint según capacidad del equipo.

Por qué importa: aquí te comprometes a entregar X cosas. No te comprometas a más de lo que realmente puedes hacer.

5. Retrospectiva / Retro#

Reunión al final del sprint donde el equipo discute qué fue bien, qué fue mal y qué cambiar.

Ejemplo: “En la retro vimos que las PRs tardan mucho en revisarse, vamos a poner un tiempo máximo”.

Por qué importa: es el momento de plantear mejoras de proceso. Si algo te frustra del equipo, dilo aquí, no en privado.

6. Demo / Review#

Presentación al final del sprint donde se muestra lo que se construyó al equipo y a stakeholders.

Por qué importa: si tu trabajo no se ve en la demo, “no existe” para el resto de la empresa.

7. Backlog#

Lista priorizada de tareas pendientes del producto. Lo gestiona normalmente el Product Owner o Product Manager.

Estructura típica: cada item es una “historia de usuario” o “ticket” en una herramienta como Jira, Linear o GitHub Projects.

8. Historia de usuario / User story#

Formato típico para describir una funcionalidad desde el punto de vista del usuario.

Formato estándar: “Como [tipo de usuario] quiero [acción] para [beneficio]”.

Ejemplo: “Como usuario registrado quiero exportar mis datos en CSV para poder analizarlos en Excel”.

9. Story points / Puntos de historia#

Unidad para estimar el esfuerzo de una tarea. NO son horas, son una medida relativa de complejidad.

Escala típica: 1, 2, 3, 5, 8, 13 (secuencia Fibonacci).

Por qué importa: si una tarea es 8 puntos, vale para todo el sprint. Si es 1, son pocas horas.

10. Definition of Done (DoD)#

Criterios que una tarea debe cumplir para considerarse terminada.

Típicamente incluye: código escrito, tests pasando, code review aprobado, deployado a staging, documentación actualizada.

Por qué importa: “está terminado” puede significar 10 cosas distintas. La DoD lo aclara.

Roles y posiciones#

11. Product Owner (PO) / Product Manager (PM)#

La persona que decide qué se construye y en qué orden. Comunica con stakeholders y clientes.

Diferencia sutil: PO es más operativo (gestiona el backlog), PM más estratégico (define producto). En muchas empresas se solapan.

12. Scrum Master#

Persona que facilita las ceremonias ágiles (stand-ups, retros, etc.) y elimina bloqueos del equipo.

Importante: NO es jefe del equipo, es facilitador. No te da órdenes, te ayuda a desbloquear.

13. Tech Lead#

Developer senior que lidera técnicamente un equipo o proyecto. Toma decisiones de arquitectura, hace mentoría, asegura calidad.

No es manager (no gestiona personas formalmente), pero influye mucho.

14. Engineering Manager (EM)#

Manager formal del equipo de developers. Gestiona personas, revisiones de rendimiento, contratación.

Diferencia con Tech Lead: el EM se ocupa de personas, el Tech Lead de tecnología. Aunque a veces se solapan.

15. Junior / Mid / Senior / Staff / Principal#

Niveles típicos de seniority en una empresa tech:

Junior (0-2 años): aprende, ejecuta tareas claras, supervisión cercana.
Mid (2-5 años): autónomo en tareas medianas, contribuye a decisiones técnicas.
Senior (5+ años): autónomo en sistemas complejos, mentoriza juniors, define arquitectura.
Staff (8+ años): lidera proyectos cross-equipo, alto impacto técnico.
Principal (10+ años): decisiones a nivel de empresa, autoridad técnica máxima.

Cada escalón tiene su propia horquilla salarial: la desglosamos en el análisis del stack tech que piden las empresas españolas y lo que pagan por cada perfil.

Control de versiones (Git)#

Git es donde más horas de terminal vas a acumular, así que vale la pena interiorizar cuanto antes los atajos y alias de Git que usan los developers profesionales.

16. Branch / Rama#

Versión paralela del código donde puedes trabajar sin afectar a la versión principal.

Convenciones típicas: main o master para producción, develop para desarrollo, feature/nombre-feature para nuevas funcionalidades.

17. Pull Request (PR) / Merge Request (MR)#

Solicitud para incorporar tu rama al código principal. Se revisa por otros developers antes de fusionarse.

Diferencia: GitHub usa “Pull Request”, GitLab usa “Merge Request”. Mismo concepto.

18. Code review#

Proceso donde otro developer revisa tu código antes de mergearlo. Comenta cambios, sugerencias o problemas.

Por qué importa: tu primer trabajo va a tener muchas code reviews. Aprende a recibir feedback constructivamente y a dar feedback constructivo.

19. Merge / Fusión#

Combinar cambios de una rama en otra. “Mergear” en spanglish.

Ejemplo: “Mergea tu PR cuando dos personas la aprueben”.

20. Rebase#

Reescribir el historial de tu rama para que parezca que tus cambios se hicieron sobre la última versión de main.

Cuándo usarlo: para mantener historial limpio antes de mergear. Es polémico, hay equipos que prefieren merges normales.

21. Conflicto / Merge conflict#

Cuando Git no sabe cómo combinar dos cambios porque modifican las mismas líneas.

Solución: resolver manualmente eligiendo qué cambio mantener.

22. Cherry-pick#

Coger un commit específico de una rama y aplicarlo a otra.

Cuándo usarlo: cuando quieres llevar un fix concreto a otra rama sin merge completo.

23. Rollback / Revertir#

Deshacer cambios que se desplegaron. Volver a un estado anterior.

Ejemplo: “El deploy de ayer rompió producción, vamos a hacer rollback”.

DevOps y deployment#

Esta es la categoría que más crece en cuanto pisas una empresa mediana. Si te quedas corto con los siete términos que siguen, tenemos un glosario de DevOps con 80 términos esenciales que entra en contenedores, observabilidad y cloud.

24. CI / Continuous Integration#

Proceso automático que ejecuta tests, linting y otras validaciones cada vez que haces push.

Herramientas típicas: GitHub Actions, GitLab CI, CircleCI, Jenkins.

Por qué importa: si el CI está rojo, no puedes mergear. Aprende a leer los logs.

25. CD / Continuous Deployment (o Delivery)#

Proceso automático que despliega tu código a producción (o a un entorno intermedio) cuando los cambios se mergean.

Diferencia: Deployment = automático a producción. Delivery = automático hasta staging, despliegue manual a producción.

26. Pipeline#

Secuencia de pasos que ejecuta el CI/CD: build, test, deploy, etc.

Ejemplo: “El pipeline tarda 15 minutos porque los tests E2E son lentos”.

27. Build#

Proceso de compilar/empaquetar tu código para producción.

Ejemplo: “El build falló porque hay un error de TypeScript”.

28. Deploy / Despliegue#

Subir el código a un servidor donde lo pueden usar usuarios reales.

Tipos: deploy a staging (pre-producción), deploy a producción.

29. Staging / Pre-producción#

Entorno casi idéntico a producción donde se prueban cambios antes de ir a usuarios reales.

Por qué importa: si algo falla en staging, no afecta a usuarios. Si falla en prod, sí.

30. Hotfix#

Fix urgente que se despliega rápido (sin esperar al siguiente sprint) porque hay un bug crítico en producción.

Ejemplo: “Hotfix: el botón de pago ha dejado de funcionar”.

Métodos y patrones#

31. MVP / Minimum Viable Product#

Versión más pequeña posible del producto que ya aporta valor a usuarios.

Ejemplo: “El MVP del e-commerce: listar productos, carrito, checkout con Stripe. Sin filtros, sin cuenta de usuario”.

Por qué importa: lanza algo pequeño y itera, no construyas 6 meses sin enseñar nada.

32. POC / Proof of Concept#

Demo técnica para probar si algo es viable. NO es código de producción, es para validar una idea.

Diferencia con MVP: POC valida tecnología, MVP valida producto.

33. Spike#

Investigación corta (1-2 días típicamente) sobre un tema técnico antes de implementarlo.

Ejemplo: “Hagamos un spike sobre si Stripe vs Adyen para nuestra integración de pagos”.

34. Refactor / Refactorización#

Cambiar código sin cambiar comportamiento. Mejorar legibilidad, performance o estructura.

Importante: refactor + cambio de funcionalidad = mala práctica. Hazlo por separado.

35. Tech debt / Deuda técnica#

Decisiones técnicas subóptimas que se hacen por velocidad ahora y se “pagan” después con más trabajo.

Ejemplo: “Metimos lógica de negocio en el componente porque íbamos justos. Eso es tech debt que arreglar el próximo sprint”.

36. Boilerplate#

Código repetitivo que necesitas escribir aunque no aporta lógica única.

Ejemplo: “El boilerplate para crear un nuevo endpoint en este framework es brutal”.

37. DRY / Don’t Repeat Yourself#

Principio: no repitas el mismo código en varios sitios. Si lo haces, extrae a una función o componente reutilizable.

38. KISS / Keep It Simple, Stupid#

Principio: la solución más simple suele ser la mejor. No sobreingeniería.

39. YAGNI / You Aren’t Gonna Need It#

Principio: no añadas funcionalidad “por si acaso la necesitamos”. Construye lo que necesitas ahora.

40. SOLID#

Cinco principios de diseño orientado a objetos. No te los vas a aprender de memoria pero los verás citados:

S: Single Responsibility (una clase, una responsabilidad)
O: Open/Closed (abierto a extensión, cerrado a modificación)
L: Liskov Substitution (las subclases deben ser sustituibles por sus padres)
I: Interface Segregation (interfaces específicas mejor que generales)
D: Dependency Inversion (depende de abstracciones, no de implementaciones)

Testing#

41. Unit test / Test unitario#

Test que prueba una función o componente aislado.

Ejemplo: testear que sumar(2, 3) === 5.

42. Integration test / Test de integración#

Test que prueba varias partes funcionando juntas.

Ejemplo: testear que el endpoint /api/users/create realmente crea un usuario en la base de datos.

43. E2E / End-to-end test#

Test que prueba un flujo completo simulando un usuario real.

Ejemplo: testear que un usuario puede registrarse, hacer login, comprar un producto y recibir email de confirmación.

44. TDD / Test-Driven Development#

Metodología: escribir el test primero, ver que falla, luego escribir el código que lo hace pasar.

Ciclo: Red (test falla) → Green (test pasa) → Refactor (mejoras código).

45. Coverage / Cobertura#

Porcentaje de tu código que está cubierto por tests.

Objetivo típico: 70-80%. 100% suele ser excesivo (no aporta valor proporcional al esfuerzo).

Términos varios#

46. SLA / Service Level Agreement#

Compromiso de nivel de servicio. Por ejemplo, “99,9% uptime” significa que el sistema puede estar caído máximo 8 horas y 45 minutos al año.

Por qué importa: define qué es “aceptable” para problemas en producción.

47. SLO / Service Level Objective#

Objetivo interno que el equipo se marca. Suele ser más estricto que el SLA.

48. Postmortem#

Documento que se escribe después de un incidente grave en producción. Analiza qué pasó, por qué y cómo evitar que vuelva a pasar.

Importante: el postmortem NO busca culpables. Es para aprender, no para señalar.

49. On-call / Guardia#

Turno donde un developer está disponible fuera del horario para responder a incidentes urgentes.

Compensación típica: extra de sueldo o días libres por las guardias.

50. WIP / Work In Progress#

Trabajo en curso. Verás “WIP” mucho en títulos de PRs para indicar que aún no está terminado.

Ejemplo: “WIP: añadir autenticación con Google OAuth” significa “esto no está listo todavía, no lo revisen formalmente”.

Conclusión#

Esta lista no es exhaustiva — hay 100 términos más que escucharás con el tiempo. Pero si dominas estos 50, vas a entender el 90% de las conversaciones en tu primer trabajo.

Mientras te haces con el vocabulario, un asistente de IA es un buen traductor de guardia: en la comparativa de Claude Code, Cursor y Copilot según tu perfil explicamos cuál tiene más sentido cuando estás empezando.

Y un consejo final: siempre pregunta cuando no entiendas algo. Es más profesional preguntar “¿qué significa CI rojo?” la primera vez que pasarte 6 meses asintiendo sin entender. Tus compañeros senior preferirán mil veces explicarte un término que descubrir 3 sprints después que llevas tiempo confuso.

Marca esta página, compártela con compañeros del bootcamp o de la universidad, y vuelve cuando necesites refrescar algo. La actualizamos cuando aparecen términos nuevos importantes.

Si crees que falta algún término importante o tienes alguna duda específica, escríbenos. Mantenemos este glosario actualizado con feedback de la comunidad.